1. Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)

2. Agenda Architectural models OOA/OOD and distributed system diff. Layering Interface Partioning & Granularity Adapting patterns for distributed usage A few words of warning: Assumed students are knowledgeable about OOA/OOD We will only look at some aspects of distributed architecture Not much literature available on this subject No textbook solutions to this problem This lecture is just for inspiration – not a dictate

3. Architectural models Architectural model: Description of the components of a system and the relationship between them. Describe the components of systems and their interaction; describe mapping of components to computers. Define useful patterns for the distribution of data and workload. Define the functional roles of components and the patterns of communication between them.

4. Basic architectural models Client-server: WWW, OO middleware, distributed systems in general Others: service, peer-to-peer, proxy, mobile code, spontaneous network Read more in Colourius et al.

5. Designing Distributed Systems Use OOA/OOD (or other method) Same procedure as with stand-alone system design Use ”best-practices” aka ”design patterns” BUT: beware of the pit-falls of distributed design (Guerraoui & Fayad) Beware of “Gold Plating” Do not use excessive amount of time on design “Death By Interfacing/Layering”

6. Basic OO Design – Use Case Driven Use Case N Actor 1 Use Case spec. “Models” the domain e.g. an Account or Sensor. System/Actor Interaction Use Case impl. Links Model & Boundry «control» «boundary» «entity» Domain Model for Use Case N Logic Domain Model from the Analysis OOA

7. Bruce Eckel’s ROPES Model Architecture design Scope: nodes, packages (sub systems), components (e.g. a driver DLL), tasks Mechanistic design Scope: Group of collaboratingclasses Class Node Package Component Active object Detailed design Scope: Class Class name Attributes Operations Bd. s193

8. Use Sub-systems for Structuring At least use two sub-systems: a client a server More sub-systems may be introduced as needed

9. Getting Distributed Until now – stand-alone & single process Distributed Systems are much more complex We focus only on OO systems How to make an optimal design? What belongs on the client side – and what on the server side? At least three things to consider: Layering Granularity issues Adapting Design Patterns

10. Design with Layers Client Presentation tier Provides a user interface to the end-users. Thin/Rich. MVC. Server Side Presentation tier Building a response to the Client Presentation tier. Server Side Business Logic tier Use Case implementation. Control classes. Business logic. Server Side Domain Model tier Domain Model. Entity classes. Enterprise Integration tier Legacy system. Web services. Persistence tier / Resource layer Relational Database. File-system.

11. Interface Partitioning & Granularity OOA/OOD teaches us to map real world model to domain model Granularity has always been an issue In stand-alone / single process systems Should we have a fine-grained model – with one or more control classes pr use case and a detailed domain model? Should we have a coarse-grained model with only a few classes? In distributed systems, this gets worse

12. Three Aspects of a Distributed Object System Granularity of Model Interface Design System Partitioning Three important aspects when producing a Distributed object Model which has impact on each other Anti-pattern: Round tripping vs. partition of resources vs. desired level of interface design resolution (some might want to map system objects 1-1 with real world objects, accounts and transactions Producing a real world OO mapping is important Fine Grained = Natural Mapping = Easy to Understand Fine Grained = Slow Distributed performance Coarse Grained = Better Distributed performance = SOA Fine Grained = Easy to Partition = Good Scalability Coarse Grained = Harder to Partition = Poorer Scalability

13. Using Design Patterns Provides guidelines, not actual implementation Proven track record Reusable Help you communicate your design ideas to other designers Anti-pattern: Gold Plating – spending excessive amount of time on design

14. Design Patterns Examples ”Classic Design Patterns”: Singleton Observer Iterator Facade Proxy (you have already seen this) Factory Many others All may be used, but some should be adjusted Remember: patterns are only for inspiration NOT dictate Lets look at a few

15. Façade Pattern (also GoF) + DTO’s Used for encapsulation and decoupling – usually one pr sub-system - Session Façade pattern, Façade at the Distribution Boundary Used for encapsulation and decoupling – usually one pr sub-system - Session Façade pattern, Façade at the Distribution Boundary The entire Client sub-system is decoupled from the server sub-system and a Client Proxy hides the complex network detail of a distributed system By using Façade pattern, only a few objects needs to be made Remote The entire Client sub-system is decoupled from the server sub-system and a Client Proxy hides the complex network detail of a distributed system By using Façade pattern, only a few objects needs to be made Remote

16. Replicating Objects / Layering Client Presentation tier Provides a user interface to the end-users. Thin/Rich. MVC. Server Side Presentation tier Building a response to the Client Presentation tier. Server Side Business Logic tier Use Case implementation. Control classes. Business logic. Server Side Domain Model tier Domain Model. Entity classes. Enterprise Integration tier Legacy system. Web services. Persistence tier / Resource layer Relational Database. File-system. Using DTO’s + facades Replicating Objects / Data Transfer Object Pattern How to do it in CORBA? -NOT IDL Interfaces -IDL Structs -IDL Valuetypes

17. The Observer Pattern (GoF) Publisher Subscriber Generates a lot of network traffic even though the three subscribers resides in the same process space

18. Publish-Subscribe Channel (Distributed Observer) channel Subscriber Channel Publisher Only one notify message between the channel objects as opposed to the naive Observer pattern. channel Subscriber Channel Publisher Only one notify message between the channel objects

19. Iterator Pattern ClientIteratorCollection 1. Create iterator 2. Get next item 3. Get next item 4. ….. Generates a lot of network traffic

20. Distributed Iterator ClientIteratorCollec- tion 1. Create iterator 2. Query 3. Get next item 4. Get next item 5. ……. Result of 2. Only one call needed to transfer all objects. Design more than one “next” method to allow for different number of objects wanted

21. Factory Pattern How to create objects? Can not instantiate We need a staging point – a Factory object Distributed version: Object Factory For creating, finding & managing both DTO and remote objects Often seen in conjunction with façade, replicating objects & proxy

22. Remember You have been presented with some basic input for the design of distributed systems This is only for inspiration not a dictate Even though we have the ideals of transparency – one must remember the differences that does exist

23. Læringsmål Alignment Når kurset er færdigt forventes den studerende at kunne: Definere, beskrive og sammenligne forskellige typer af objektorienterede middleware frameworks til apparater og computere, med primær fokus på CORBA og sekundært.NET Remoting teknologierne, herunder fordele og ulemper forbundet med de forskellige teknologier Definere og beskrive principper omkring transparens og heterogenitet i relation til middlewareteknologier Definere og beskrive gængse teorier, metoder og retningslinier indenfor det objektorienterede middleware paradigme og anvende disse til at designe effektive distribuerede systemer Designe og konstruere et distribueret system der gør brug af CORBA og.NET Remoting teknologierne med tilhørende værktøjssupport Design Guidelines til at designe et effektivt distribueret OO system. I skal altså kunne redegøre for forskelle i forhold til stand-alone systemer, Samt beherske terminologi fra forelæsning og litteratur. Også vigtigt at kunne forholde sig kritisk Design Guidelines til at designe et effektivt distribueret OO system. I skal altså kunne redegøre for forskelle i forhold til stand-alone systemer, Samt beherske terminologi fra forelæsning og litteratur. Også vigtigt at kunne forholde sig kritisk MANGLER: hvordan I praktisk omsætter denne viden