1. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder1 Architectural Design of Distributed Systems, Part 4 ECEN5053 SW Eng of Distributed Systems University of Colorado, Boulder

2. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder2 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

3. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder3 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.

4. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder4 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

5. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder5 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.

6. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder6 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

7. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder7 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.

8. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder8 Design of Server Subsystems Provides a service for client subsystems file servers, database servers, printer servers, etc. Consider a standalone program that accesses a database A data structure is encapsulated in a data abstraction object – acts as a “server” Tasks (concurrent) invoke operations provided by the object in order to access its data How is a distributed system different?

9. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder9 Distributed data access Tasks on physically separate nodes cannot access a passive data abstraction object directly The passive data abstraction object encapsulates the data structure A server component encapsulates the passive data abstraction object An active object thread access the passive object Server active object responds to client requests to read/update the data maintained by passive obj.

10. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder10 Simple server subsystem Does not initiate any requests for services from other subsystems Sequential Concurrent

11. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder11 Sequential Server Services client requests sequentially The sequential server is a task (active object) Provides one or more services Responds to requests from client tasks to access the service When server task receives a message, it invokes the service actually provided by the passive data abstraction object to read or update its data

12. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder12 Auxiliary support Server task has a message queue of incoming service requests There is a message type for each service provided by the server Server coordinator unpacks the client’s msg, checks the msg type, invokes the appropriate operation provided by the server object. Msg parameters are operation parameters Server object services request, returns response to server coordinator that packs response into a msg and sends it to the client.

13. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder13 Sequential server subsystem clientTransaction > ;BankServer > ;BankClient bankResponse ; BankTransactionServer ; CheckingAccount ;Savings Account debit() credit() read() debit() credit() read()

14. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder14 Concurrent Server Subsystem High client demand can lead to bottleneck at the sequential server subsystem interface Transfer the potential bottleneck to the internal access to the data Concurrent server subsystem Instantiate a new task for each msg What are the assumptions?

15. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder15 Implications of concurrency Access to data must be synchronized by application dependent algorithm mutual exclusion? multiple readers and writers? If clients communicate with server asynchronously Server response can be handled as a callback Client sends an operation handle with its request Server uses the handle to remote call the client operation (the callback) when finished servicing

16. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder16 Multiple readers & writers > mrwConcurrentServer ;ServerCo ordinator clientRequest aReaderanother Reader aWriteranother Writer ;Data Repository readRequest done serviceRe sponse read

17. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder17 Another concurrent server Server maintains an event archive Server provides a subscription/notification service to its clients Monitor task monitors external events Subscription server maintains list of clients that wish to be notified of these events When external event occurs, the monitor updates an event archive & informs the event distributor (publisher) of the event arrival Distributor queries the subscription server to determine clients who have subscribed; notifies them.

18. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder18 :Server Coordinator :EventArchive Server :SubscriptionS erver :Event Distributor > aReal-Time EventMonitor aConcurrentServer S1: client Request S2: subscribe archive Query archiveData S3: server Response E2: update E4: subscription Query E5: event Subscribers E3: event Arrival E1: externalEvent E6: eventNotification

19. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder19

20. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder20 Data distribution In the server examples so far, they are single- server subsystems – single host Even concurrent server subsystem can become a bottleneck and a single point of failure Alternatives Distributed Replicated

21. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder21 Distributed Server Data collected at several locations is stored at those locations Each location has a local server Each local server responds to client requests for that location’s data Where is that used in the Factory Automation System? The homework election system?

22. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder22 Distributed Server

23. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder23 Replicated Server Same data is duplicated in more than one location – intent is to speed access to the data Must ensure that data does not get out of date more than is acceptable for the application Coulouris has entire chapter on replicated systems

24. 10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder24 System Configuration After designed, instances can be defined and configured to multiple geographically distributed physical nodes connected by a network Determine What component instances are required/desired How the component instances should be interconnected How the component instances should be allocated to nodes