presentation: architectural design for distributed systems objektorienteret middleware (oomi)
DESCRIPTION
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.TRANSCRIPT
![Page 1: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/1.jpg)
Presentation:Architectural Design for Distributed Systems
Objektorienteret Middleware (OOMI)
![Page 2: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/2.jpg)
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/OODWe will only look at some aspects of distributed architectureNot much literature available on this subjectNo textbook solutions to this problemThis lecture is just for inspiration – not a dictate
![Page 3: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/3.jpg)
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.
![Page 4: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/4.jpg)
Basic architectural models
Server
Client
Client
invocation
result
Serverinvocation
result
Process:Key:
Computer:
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.
![Page 5: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/5.jpg)
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”
![Page 6: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/6.jpg)
Basic OO Design – Use Case Driven
Use Case N
Actor 1
Use Casespec.
“Models” the domaine.g. an Account or
Sensor.
System/ActorInteraction
Use Case impl.Links Model & Boundry
«control»
«boundary»
«entity»
Domain Model for Use Case N
Logic DomainModel from the Analysis
OOA
![Page 7: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/7.jpg)
Bruce Eckel’s ROPES ModelArchitecture designScope: nodes, packages (sub systems), components (e.g. a driver DLL), tasks
Mechanistic designScope: Group of collaboratingclasses Class
Class
Class
Class
Node
Package
ComponentActive object
Detailed designScope: Class
Class name
Attributes
Operations
Bd. s193
![Page 8: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/8.jpg)
Use Sub-systems for Structuring• At least use two
sub-systems:• a client• a server
• More sub-systems may be introduced as needed
![Page 9: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/9.jpg)
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
![Page 10: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/10.jpg)
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.
![Page 11: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/11.jpg)
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
![Page 12: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/12.jpg)
Three Aspects of a Distributed Object System
Granularityof Model
Interface Design
SystemPartitioning
Three important aspects when producing a Distributed object Model which has impact on eachother
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
![Page 13: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/13.jpg)
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
![Page 14: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/14.jpg)
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
![Page 15: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/15.jpg)
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
The entire Client sub-system is decoupled from the server sub-systemand 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
![Page 16: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/16.jpg)
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 D
TO’s + facades
Replicating Objects /Data Transfer Object PatternHow to do it in CORBA?-NOT IDL Interfaces-IDL Structs-IDL Valuetypes
![Page 17: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/17.jpg)
The Observer Pattern (GoF)
Publisher
Subscriber
Subscriber
Subscriber
Generates a lot of network trafficeven though the three subscribersresides in the same process space
![Page 18: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/18.jpg)
Publish-Subscribe Channel (Distributed Observer)
channel
Subscriber
Subscriber
Subscriber Channel
Publisher
Only one notify message between thechannel objects as opposed to the naive Observer pattern.
channel
Subscriber
Subscriber
Subscriber Channel
Publisher
Only one notify message between thechannel objects
![Page 19: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/19.jpg)
Iterator Pattern
Client Iterator Collection
1. Create iterator
2. Get next item3. Get next item4. …..
Generates a lot of network traffic
![Page 20: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/20.jpg)
Distributed Iterator
Client Iterator Collec-tion
1. Create iterator
2. Query3. 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
![Page 21: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/21.jpg)
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
![Page 22: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/22.jpg)
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
![Page 23: Presentation: Architectural Design for Distributed Systems Objektorienteret Middleware (OOMI)](https://reader035.vdocuments.mx/reader035/viewer/2022062401/5a4d1b787f8b9ab0599b829b/html5/thumbnails/23.jpg)
Læringsmål AlignmentNå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 behersketerminologi fra
forelæsning og litteratur.Også vigtigt
at kunne forholde sig kritisk
MANGLER: hvordan I praktisk omsætter denne viden