1. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder1 Architectural Design of Distributed Systems, Part 3 ECEN5053 SW Eng of Distributed Systems University of Colorado, Boulder

2. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder2 Overview of steps System decomposition into subsystems Use subsystem structuring criteria Define interfaces between subsystems Evaluate subsystem structure with component configuration criteria Subsystem decomposition into concurrent tasks and passive (information hiding) objects – other course System configuration – specific deployment Instances defined and configured Mapped onto hardware configuration of distributed physical nodes

3. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder3 Static Model -- Composite Classes

4. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder4 Subsystem Interfaces

5. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder5 Subsystem Interfaces - 2

6. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder6 Subsystem Interfaces - 3

7. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder7 Timeline of COMET Design Methodology – Pt 1  Use case diagrams  Use case narratives Domain model System context model Static model of entity classes Define classes in the class dictionary (classes & attributes) Class diagram  objects  classes  high-level subsystems  add new classes to class dictionary  Per use case, dev collaboration diagram (or sequence)  Analyze sequence  Analyze information passed Dev. statechart for each state- dependent object in a state- dependent collaboration. Synthesize statecharts Message sequence descriptions for each collaboration diagram Requirements Model Analysis Model Design Model Synthesize artifacts of analysis to make initial sw architecture Synthesize collaboration diagrams into collaboration model Synthesize class diagram  Design overall sw architecture: Subsystem structure  Subsystem interfaces  Collaboration diagram for each subsystem  Hi-level collaboration diagram for whole system  Design distributed component-based sw architecture  For dist. apps., define dist. component subsystems using dist. configuration criteria  Def. msg comm interfaces

8. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder8 Timeline of COMET Design Methodology – Pt. 2 Define the concurrent task architecture for each subsystem  Apply task structuring criteria  Define tasks and their interfaces  Dev. concurrent collaboration diagrams for each subsystem  Describe each task in task behavior spec Analyze the performance of the design for real-time tasks Design the classes in each subsystem  Class interfaces  Inheritance hierarchies  If database needed o design db o dev wrapper classes  Dev. class interface spec for each class Dev. detailed software design for each subsystem  Internals of composite tasks including nested passive objects  Details of task synchronizatio mechanisms for obj’s accessed by multiple tasks  Connector classes that encapsulate details of inter-task communication  Des., doc each task’s internal event sequencing logic Performance Analysis for real-time sys Subsystem Classes Design Detailed software design Re-analyze performance in greater detail for each subsystem by iterating on these steps, if necessary. This applies to real-time application design.

9. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder9 Deployment Diagram

10. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder10 One more pass Want to be sure the subsystems can be designed as distributed components, mapped to distributed nodes. Component Configuration criteria Providing a service specific to a site – each instance on a specific node Performance Specialized hardware or interfaces User interface Server component

11. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder11 Service specific to a site One component can be operational even if the other nodes are unavailable Proximity to the source of physical data – fast access for high access rates Localized autonomy Receives high level commands from elsewhere Provides low-level control, perhaps providing status information

12. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder12 Performance All related objects on the same node to perform a time-critical function May need to violate some other principle How critical is critical?

13. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder13 Specialized HW Component supports specialized hardware interfaces to special-purpose peripherals, sensors need to be nearby

14. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder14 User interface Located at the node where the user is Responses to simple requests can be rapid Responses to more complicated requests can be slower – psychologically acceptable

15. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder15 Server component Service for other components “Proximity to source of data” may overlap A data server might support remote access to a centralized database or file store – not always co-located with the data store

16. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder16 Subsystem Interfaces - asynchronous Message communication for distributed systems Loosely-coupled asynchronous message communication between subsystems wherever possible FIFO message queues Priority message queues Group communication (multicast) from one location to all members of a group

17. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder17 Subsystem Interfaces - Synchronous Tightly coupled – client sends a msg and waits (idle or suspended) for a response Single client/server Multiple-client/server Queue can build up at server end Server can delegate processing of client’s request to another server which then responds directly to the original client

18. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder18 ack/nack Msg communication in same or different subsystems is generally handled the same way but remote transmission has the possibility of failure en route MOM communicates with MOM Even in asynchronous comm, may want indication that msg has arrived Negative ack to source task from local MOM if ack not received within time spec Source task must decide what to do

19. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder19 Synchronous with reply Sends a msg and waits for a reply nack from local MOM indicating timeout If client and server are to dialog, establish a connection and send/receive msgs over the connection Synchronous without reply possible but... what’s the point? (there may be a point – what is it?)

20. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder20 Group msg comm or subscribe/notify One source, multiple destinations Broadcast communication unsolicited msg sent to all recipients; recipients decide whether to discard or process Multicast same msg sent to members of a group Subscribe/notify Publisher can send to group

21. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder21 Brokered Communication Clients and servers can be distributed objects Object broker is intermediary in interactions between them Client does not have to maintain info about where the service is provided or how to obtain it Provides location transparency – if server moves, only the broker needs to know Servers register services they provide and location Clients identify service required and send msg Broker receives request, finds location, forwards req.

22. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder22 Transaction Management In this section, sufficient to realize the need for transactions Flat – all or nothing Compound – might need only partial rollback We’ll spend a week specifically on transaction management

23. 9-27-2004 ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder23 Data distribution Distributed data divided into sections each section on a different subsystem Replicated data identical copies everywhere challenge is to keep them identical at the level required by the application We spend a week on this topic, also.