Objektorienteret netværkskommunikation Presentation: Architectures for Distributed Systems

Ingeniørhøjskolen i Århus Slide 2 af 29 Agenda System models Architectural models OOA/OOD and distributed system diff. Layering Interface Partioning & Granularity Adapting patterns for distributed usage

Ingeniørhøjskolen i Århus Slide 3 af 29 System models – what and why? System model: –Abstract, consistent description of a relevant aspect of a distributed system. –Description of the main entities of a system and their interaction, and individual and collective behaviour Aid for design, analysis, discussion, etc. –Make assumptions explicit. –Investigate what is possible or impossible.

Ingeniørhøjskolen i Århus Slide 4 af 29 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.

Ingeniørhøjskolen i Århus Slide 5 af 29 Basic architectural models – client- server

Ingeniørhøjskolen i Århus Slide 6 af 29 Basic architectural models – multiple servers Partition set of objects or replicate set of objects

Ingeniørhøjskolen i Århus Slide 7 af 29 Basic architectural models – proxy server and caching Cache: Store of recently used data objects closer than the objects themselves Proxy servers increase performance and availability

Ingeniørhøjskolen i Århus Slide 8 af 29 Basic architectural models – peer processes

Ingeniørhøjskolen i Århus Slide 9 af 29 Other architectural models – mobile code, web applets a) client requests results in the downloading of applet code Web server Client Web server Applet Applet code Client b) client interacts with the applet

Ingeniørhøjskolen i Århus Slide 10 af 29 Other architectural models – spontaneous networking Internet gateway PDA service Music service Discovery Alarm Camera Guests devices Laptop TV/PC Hotel wireless network Easy connection and integration; limited connectivity; problems with security and privacy; discovery service with registration and lookup.

Ingeniørhøjskolen i Århus Slide 11 af 29 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 Beware of “Gold Plating” –Do not use excessive amount of time on design –Assignment 2 does not require

Ingeniørhøjskolen i Århus Slide 12 af 29 Word 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

Ingeniørhøjskolen i Århus Slide 13 af 29 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 Interaktion Use Case impl. Links Model & Boundry «control» «boundary» «entity» Domain Model for Use Case N Logic Domain Model from the Analysis OOA

Ingeniørhøjskolen i Århus Slide 14 af 29 From Use Case to Domain Model Use Case N class «control» Actor 1 A1 class «boundary» A2 class «boundary» Actor 2 Use Case N Actor 2 Actor 1 D1 class «entity» D2 class «entity» D3 class «entity»

Ingeniørhøjskolen i Århus Slide 15 af 29 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

Ingeniørhøjskolen i Århus Slide 16 af 29 Use Sub-systems for Structuring At least you should have two sub- systems: –a client –a server More sub-systems may be introduced as needed Not really nessecary in the two assignments

Ingeniørhøjskolen i Århus Slide 17 af 29 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

Ingeniørhøjskolen i Århus Slide 18 af 29 Design by 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.

Ingeniørhøjskolen i Århus Slide 19 af 29 Interface Partioning & 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 corse-grained model with only a few classes? –In distributed systems, this gets worse

Ingeniørhøjskolen i Århus Slide 20 af 29 Three Aspects of a Distributed Object System Granularity of Model Interface Design System Partioning Three important aspects when producing a Distributed object Model which has impact on each other

Ingeniørhøjskolen i Århus Slide 21 af 29 Too Fine-grained Design is Dangerous TargetClient Target 220 msg/sec msg/sec About 90 times slower to access a remote object! (Depends on the environemnt)

Ingeniørhøjskolen i Århus Slide 22 af 29 Using Design Patterns Design patterns address specific programming tasks, rather than solving business problems. Design patterns provide guidelines, not actual implementation. Design patterns are reusable. Design patterns have a proven track record. Design patterns help you communicate your design ideas to other designers

Ingeniørhøjskolen i Århus Slide 23 af 29 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 must be adjusted Remember: patterns are only for inspiration –NOT dictate

Ingeniørhøjskolen i Århus Slide 24 af 29 The Observer Pattern (GoF) Publisher Subscriber Generates a lot of network traffic even though the three subscribers resides in the same process space

Ingeniørhøjskolen i Århus Slide 25 af 29 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

Ingeniørhøjskolen i Århus Slide 26 af 29 Iterator Pattern ClientIteratorCollection 1. Create iterator 2. Get next item 3. Get next item 4. ….. Generates a lot of network traffic

Ingeniørhøjskolen i Århus Slide 27 af 29 Distributed Iterator ClientIteratorCollec- tion 1. Create iterator 2. Query 3. Get next item 4. Get next item 5. ……. Result of 2.

Ingeniørhøjskolen i Århus Slide 28 af 29 Façade Pattern (also GoF) Used for encapsulation and decoupling – usually one pr sub-system 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

Ingeniørhøjskolen i Århus Slide 29 af 29 Factory Pattern How to create objects? Can not instantiate We need a staging point – a Factory object

Ingeniørhøjskolen i Århus Slide 30 af 29 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