Architectural Design of Distributed Systems, Part 4Timeline of COMET Design Methodology – Pt 1Timeline of COMET Design Methodology – Pt. 2Group msg comm or subscribe/notifyBrokered CommunicationTransaction ManagementData distributionDesign of Server SubsystemsDistributed data accessSimple server subsystemSequential ServerAuxiliary supportSequential server subsystemConcurrent Server SubsystemImplications of concurrencyMultiple readers & writersAnother concurrent serverPowerPoint PresentationSlide 19Slide 20Distributed ServerSlide 22Replicated ServerSystem Configuration10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder1Architectural Design of Distributed Systems, Part 4ECEN5053 SW Eng of Distributed SystemsUniversity of Colorado, Boulder10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder2Timeline of COMET Design Methodology – Pt 1Use case diagramsUse case narrativesDomain modelSystem context modelStatic model of entity classesDefine 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 passedDev. statechart for each state-dependent object in a state-dependent collaboration.Synthesize statechartsMessage sequence descriptions for each collaboration diagramRequirementsModelAnalysis ModelDesign ModelSynthesize artifacts of analysis to make initial sw architectureSynthesize collaboration diagrams into collaboration modelSynthesize 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 interfaces10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder3Timeline of COMET Design Methodology – Pt. 2Define 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 specAnalyze the performance of the design for real-time tasksDesign the classes in each subsystemClass interfacesInheritance hierarchiesIf database neededodesign dbodev wrapper classesDev. class interface spec for each classDev. 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 logicPerformanceAnalysis for real-time sysSubsystem Classes DesignDetailed software designRe-analyze performance in greater detail for each subsystem by iterating on these steps, if necessary. This applies to real-time application design.10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder4Group msg comm or subscribe/notifyOne source, multiple destinationsBroadcast communicationunsolicited msg sent to all recipients; recipients decide whether to discard or processMulticastsame msg sent to members of a groupSubscribe/notifyPublisher can send to group10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder5Brokered CommunicationClients and servers can be distributed objectsObject broker is intermediary in interactions between themClient does not have to maintain info about where the service is provided or how to obtain itProvides location transparency – if server moves, only the broker needs to knowServers register services they provide and locationClients identify service required and send msgBroker receives request, finds location, forwards req.10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder6Transaction ManagementIn this section, sufficient to realize the need for transactionsFlat – all or nothingCompound – might need only partial rollbackWe’ll spend a week specifically on transaction management10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder7Data distributionDistributed datadivided into sectionseach section on a different subsystemReplicated dataidentical copies everywherechallenge is to keep them identical at the level required by the applicationWe spend a week on this topic, also.10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder8Design of Server SubsystemsProvides a service for client subsystemsfile servers, database servers, printer servers, etc.Consider a standalone program that accesses a databaseA 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 dataHow is a distributed system different?10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder9Distributed data accessTasks on physically separate nodes cannot access a passive data abstraction object directlyThe passive data abstraction object encapsulates the data structureA server component encapsulates the passive data abstraction objectAn active object thread access the passive objectServer active object responds to client requests to read/update the data maintained by passive obj.10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder10Simple server subsystemDoes not initiate any requests for services from other subsystemsSequentialConcurrent10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder11Sequential ServerServices client requests sequentiallyThe sequential server is a task (active object)Provides one or more servicesResponds to requests from client tasks to access the serviceWhen server task receives a message, it invokes the service actually provided by the passive data abstraction object to read or update its data10-4-2006 ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder12Auxiliary supportServer task has a message queue of incoming service requestsThere is a message type for each service provided by the serverServer coordinator unpacks the client’s msg, checks the