1 / 24

Architectural Design of Distributed Systems, Part 4

Architectural Design of Distributed Systems, Part 4. ECEN5053 SW Eng of Distributed Systems University of Colorado, Boulder. Timeline of COMET Design Methodology – Pt 1. Per use case, dev collaboration diagram (or sequence) Analyze sequence Analyze information passed. Requirements

bary
Télécharger la présentation

Architectural Design of Distributed Systems, Part 4

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. Timeline of COMET Design Methodology – Pt. 2 Detailed software design Performance Analysis for real-time sys Subsystem Classes Design Define the concurrent task architecture for each subsystem • 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 Analyze the performance of the design for real-time tasks • Design the classes in each subsystem • Class interfaces • Inheritance hierarchies • If database needed • design db • dev wrapper classes • Dev. class interface spec for each class • Apply task structuring criteria • Define tasks and their interfaces • Dev. concurrent collaboration diagrams for each subsystem • Describe each task in task behavior spec Re-analyze performance in greater detail for each subsystem by iterating on these steps, if necessary. This applies to real-time application design. ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder

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

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

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

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

  8. 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? ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder

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

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

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

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

  13. Sequential server subsystem clientTransaction <<client subsystem>> ;BankClient bankResponse <<sequential server subsystem>> ;BankServer ; BankTransactionServer debit() credit() read() debit() credit() read() ; CheckingAccount ;SavingsAccount ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder

  14. 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? ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder

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

  16. Multiple readers & writers <<concurrent server subsystem>> mrwConcurrentServer clientRequest ;ServerCoordinator readRequest done aWriter anotherWriter aReader anotherReader serviceResponse read ;Data Repository ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder

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

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

  19. ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder

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

  21. 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? ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder

  22. Distributed Server ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder

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

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

More Related