10-4-2006 ecen5053 sw eng of dist systems, arch des part 4, univ of colorado, boulder1 architectural...

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

1

Architectural Design of Distributed Systems, Part 4

ECEN5053 SW Eng of

Distributed Systems

University of Colorado, Boulder


2

Timeline of COMET Design Methodology – Pt 1

Use case diagramsUse case narratives

Domain model

System context model

Static model of entity classes

Define classes in the class dictionary (classes & attributes)

Class diagramobjectsclasseshigh-level subsystemsadd new classes to class dictionary

Per use case, dev collaboration diagram (or sequence)Analyze sequenceAnalyze information passed

Dev. statechart for each state-dependent object in a state-dependent collaboration.Synthesize statecharts

Message sequence descriptions for each collaboration diagram

RequirementsModel

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 structureSubsystem interfacesCollaboration diagram for each subsystemHi-level collaboration diagram for whole system

Design distributed component-based sw architectureFor dist. apps., define dist. component subsystems using dist. configuration criteriaDef. msg comm interfaces


3

Timeline of COMET Design Methodology – Pt. 2

Define the concurrent task architecture for each subsystem

Apply task structuring criteriaDefine tasks and their interfacesDev. concurrent collaboration diagrams for each subsystemDescribe each task in task behavior spec

Analyze the performance of the design for real-time tasks

Design the classes in each subsystemClass interfacesInheritance hierarchiesIf database neededodesign dbodev wrapper classesDev. class interface spec for each class

Dev. detailed software design for each subsystemInternals of composite tasks including nested passive objectsDetails of task synchronizatio mechanisms for obj’s accessed by multiple tasksConnector classes that encapsulate details of inter-task communicationDes., doc each task’s internal event sequencing logic

PerformanceAnalysis 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

Group msg comm or subscribe/notify

One source, multiple destinations

Broadcast communicationunsolicited msg sent to all recipients; recipients decide whether to discard or process

Multicastsame msg sent to members of a group

Subscribe/notify

Publisher can send to group


5

Brokered Communication

Clients and servers can be distributed objectsObject broker is intermediary in interactions between them

Client 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.


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


7

Data distribution

Distributed datadivided into sections

each section on a different subsystem

Replicated dataidentical copies everywhere

challenge is to keep them identical at the level required by the application

We spend a week on this topic, also.


8

Design of Server Subsystems

Provides a service for client subsystemsfile 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

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

Simple server subsystem

Does not initiate any requests for services from other subsystems

Sequential

Concurrent


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


12

Auxiliary support

Server 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 msg type, invokes the appropriate operation provided by the server object.Msg parameters are operation parametersServer object services request, returns response to server coordinator that packs response into a msg and sends it to the client.


13

Sequential server subsystem

clientTransaction

<<sequential server subsystem>>

;BankServer

<<client subsystem>>

;BankClient bankResponse

; BankTransactionServer

; CheckingAccount ;SavingsAccount

debit()

credit()

read()

debit()

credit()

read()


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?


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


16

Multiple readers & writers

<<concurrent server subsystem>>

mrwConcurrentServer ;ServerCoordinator

clientRequest

aReader anotherReader

aWriter anotherWriter

;Data

Repository

readRequest

done

serviceResponse read


17

Another concurrent server

Server maintains an event archiveServer provides a subscription/notification service to its clientsMonitor task monitors external eventsSubscription server maintains list of clients that wish to be notified of these eventsWhen external event occurs, the monitor updates an event archive & informs the event distributor (publisher) of the event arrivalDistributor queries the subscription server to determine clients who have subscribed; notifies them.


18

:Server Coordinator

:EventArchive Server

:SubscriptionServer

:Event Distributor

<<data collection>> aReal-Time

EventMonitor

aConcurrentServer

S1: client Request

S2: subscribearchive Query

archiveDataS3: server Response

E2: update

E4: subscription Query

E5: event Subscribers

E3: event Arrival

E1: externalEventE6: eventNotification


19


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

AlternativesDistributed

Replicated


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?


22

Distributed Server


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


24

System Configuration

After designed, instances can be defined and configured to multiple geographically distributed physical nodes connected by a network

DetermineWhat component instances are required/desired

How the component instances should be interconnected

How the component instances should be allocated to nodes

10-4-2006 ecen5053 sw eng of dist systems, arch des part 4, univ of colorado, boulder1 architectural...

Documents