Curs13

DistributedComputingPatterns

Distributedsystems

•  Wemaydefineadistributedsystemasoneinwhichhardwareorsoftwarecomponentslocatedatnetworkedcomputerscommunicateandcoordinatetheiractionsonlybypassingmessages.

•  Distributed-Computingistheprocessofsolvingaproblemusingadistributedsystem.

2

CharacteristicsConcurrency:-coordinationofconcurrentlyexecutingprogramsthatshareresourcesisalsoanimportantandrecurringtopic.Noglobalclock:-thereisnosingleglobalnotionofthecorrecttime.-Thisisadirectconsequenceofthefactthattheonlycommunicationisbysendingmessagesthroughanetwork.

Independentfailures:-  Allcomputersystemscanfail,anditistheresponsibilityofsystemdesignerstoplanforthe

consequencesofpossiblefailures.-  Faultsinthenetworkresultintheisolationofthecomputersthatareconnectedtoit,but

thatdoesn’tmeanthattheystoprunning.-  Infact,theprogramsonthemmaynotbeabletodetectwhetherthenetworkhasfailedor

hasbecomeunusuallyslow.-  Similarly,thefailureofacomputer,ortheunexpectedterminationofaprogramsomewhere

inthesystem(acrash),isnotimmediatelymadeknowntotheothercomponentswithwhichitcommunicates.

-  Eachcomponentofthesystemcanfailindependently,leavingtheothersstillrunning.

3

TrendsDistributedsystemsareundergoingaperiodofsignificantchangeandthiscanbetracedbacktoanumberofinfluentialtrends:•theemergenceofpervasivenetworkingtechnology;•theemergenceofubiquitouscomputingcoupledwiththedesiretosupportusermobilityindistributedsystems;•theincreasingdemandformultimediaservices;•theviewofdistributedsystemsasautility.

4

Client-Server

•  Aservercomponentprovidesservicestomultipleclientcomponents.

•  Aclientcomponentrequestsservicesfromtheservercomponent.

•  Serversarepermanentlyactive,listeningforclients.

5

StateintheClient-serverpatternClientsandserversareofteninvolvedin‘sessions’.–Withastatelessserver,thesessionstateismanagedbytheclient.Thisclientstateissentwitheachrequest.Inawebapplication,thesessionstatemaybestoredasURLparameters,inhiddenformfields,orbyusingcookies.ThisismandatoryfortheRESTarchitecturalstyleforwebapplications.–Withastatefulserver,thesessionstateismaintainedbytheserver,andisassociatedwithaclient-id.StateintheClient-serverpatterninfluencestransactions,faulthandlingandscalability.•  Transactionsshouldbeatomic,leaveaconsistentstate,beisolated(notaffectedbyother

requests)anddurable.Thesepropertiesarehardtoobtaininadistributedworld.•  Concerningfaulthandling,statemaintainedbytheclientmeansforinstancethateverything

willbelostwhentheclientfails.•  Client-maintainedstateposessecurityissuesaswell,becausesensitivedatamustbesentto

theserverwitheachrequest.•  Scalabilityissuesmayarisewhenyouhandletheserverstatein-memory:withmanyclients

usingtheserveratthesametime,manystateshavetobestoredinmemoryatthesametimeaswell.

6

Peer-to-peerpattern•  itcanbeseenasasymmetricClient-serverpattern:

–  peersmayfunctionbothasaclient,requestingservicesfromotherpeers,andasaserver,providingservicestootherpeers.

•  Apeermayactasaclientorasaserverorasboth,anditmaychangeitsroledynamically.

•  Bothclientsandserversinthepeer-to-peerpatternaretypicallymultithreaded.Theservicesmaybeimplicit(forinstancethroughtheuseofaconnectingstream)insteadofrequestedbyinvocation.

•  Peersactingasaservermayinformpeersactingasaclientofcertainevents.Multipleclientsmayhavetobeinformed,forinstanceusinganevent-bus.

7

Examples

•  thedistributedsearchengineSciencenet,•  multi-userapplicationslikeadrawingboard,•  peer-to-peerfile-sharinglikeGnutellaorBittorrent.

8

Characteristics•  Anadvantageofthepeer-to-peerpatternisthatnodesmayusethecapacityof

thewhole,whilebringinginonlytheirowncapacity.

–  Inotherwords,thereisalowcostofownership,throughsharing.•  Administrativeoverheadislow,becausepeer-to-peernetworksareself-

organizing.

•  ThePeer-to-peerpatternisscalable,andresilienttofailureofindividualpeers.

•  Theconfigurationofasystemmaychangedynamically:peersmaycomeandgowhilethesystemisrunning.

•  Adisadvantagemaybethatthereisnoguaranteeaboutqualityofservice,asnodescooperatevoluntarily.

–  Forthesamereason,securityisdifficulttoguarantee.

•  Performancegrowswhenthenumberofparticipatingnodesgrows,whichalsomeansthatitmaybelowwhentherearefewnodes.

9

ArchitecturalpatternsFrankBuschmann.KevlinHenney.DouglasC.Schmidt.Pattern-OrientedSoftwareArchitecture,Volume4:APatternLanguageforDistributed-Computing.Wiley&Sons,2007Anarchitecturalpatternisaconceptthatsolvesanddelineatessomeessentialcohesiveelementsofasoftwarearchitecture.•  DomainModel•  Layers•  Model-View-Controller•  Presentation-Abstraction-Control•  Microkernel•  Reflection•  PipesandFilters•  SharedRepository•  Blackboard•  DomainObject

10

ConnectiontotheDomainLayer

11

Pipe-FilterPattern

12

•  ThePipe-filterarchitecturalpatternprovidesastructureforsystemsthatproduceastreamofdata.

•  Eachprocessingstepisencapsulatedinafiltercomponent(circles).

•  Dataispassedthroughpipes(thearrowsbetweenadjacentfilters).•  Thepipesmaybeusedforbufferingorforsynchronization.

Example

13

•  UsethePipesandFiltersarchitecturalstyletodividealargerprocessingtaskintoasequenceofsmaller,independentprocessingsteps(Filters)thatareconnectedbychannels(Pipes).

•  Eachfilterexposesaverysimpleinterface:itreceivesmessagesontheinboundpipe,processesthemessage,andpublishestheresultstotheoutboundpipe.

•  Thepipeconnectsonefiltertothenext,sendingoutputmessagesfromonefiltertothenext.

•  Becauseallcomponentusethesameexternalinterfacetheycanbecomposedintodifferentsolutionsbyconnectingthecomponentstodifferentpipes.

•  Wecanaddnewfilters,omitexistingonesorrearrangethemintoanewsequence--allwithouthavingtochangethefiltersthemselves.

BlackboardPattern

14

•  TheBlackboardpatternisusefulforproblemsforwhichnodeterministicsolutionstrategiesareknown=>opportunisticproblemsolving.

•  Severalspecializedsubsystemsassembletheirknowledgetobuildapossiblypartialorapproximatesolution.

•  Allcomponentshaveaccesstoashareddatastore,theblackboard.•  Componentsmayproducenewdataobjectsthatareaddedtotheblackboard.•  Componentslookforparticularkindsofdataontheblackboard,andmayfind

thesebypatternmatching.

•  Class–  Blackboard

•  Responsibility–  Managescentraldata

•  Collaborators–  no

•  Class–  KnowledgeSource

•  Responsibility–  Evaluatesitsownapplicability

–  Computesaresult

–  UpdatesBlackboard

•  Collaborators–  Blackboard

15

•  Class–  Control

•  Responsibility–  MonitorsBlackboard

–  Schedulesknowledgesourceactivations

•  Collaborators–  Blackboard–  KnowledgeSource

Generaldescription

•  Blackboardallowsmultipleprocesses(oragents)tocommunicatebyreadingandwritingrequestsandinformationtoaglobaldatastore.

•  Eachparticipantagenthasexpertiseinitsownfield,andhasakindofproblemsolvingknowledge(knowledgesource)thatisapplicabletoapartoftheproblem,i.e.,theproblemcannotbesolvedbyanindividualagentonly.

•  Agentscommunicatestrictlythroughacommonblackboardwhosecontentsisvisibletoallagents.

•  Whenapartialproblemistobesolved,candidateagentsthatcanpossiblyhandleitarelisted.

•  Acontrolunitisresponsibleforselectingamongthecandidateagentstoassignthetasktooneofthem.

16

Example:speechrecognition•  ThemainloopofControlstarted

–  ControlcallsnextSource()toselectthenextknowledgesource

–  nextSource()looksattheblackboardanddetermineswhichknowledgesourcestocall

–  Forexample,nextSource()determinethatSegmentation,SyllableCreationandWordCreationarecandidate

–  nextsource()invokesthecondition-partofeachcandidateknowledgesource

–  Thecondition-partsofcandidateknowledgesourceinspecttheblackboardtodetermineifandhowtheycancontributetothecurrentstateofthesolution

–  TheControlchoosesaknowledgesourcetoinvokeandasetofhypothesestobeworkedon(accordingtotheresultoftheconditionpartsand/orcontroldata)

–  Applytheaction-partoftheknowledgesourcetothehypothesis

–  Newcontentsareupdatedintheblackboard

17

Advantages&Disadvantages

•  Advantages–  Suitablewhentherearediversesourcesofinputdata–  Suitableforphysicallydistributedenvironments–  Suitableforschedulingandpostponementoftasksanddecisions

–  Suitableforteamproblem-solvingapproachesasitcanbeusedtopostproblemsubsomponentsandpartialresults

•  Disadvantages–  Expensive–  Difficulttodeterminepartitioningofknowledge–  Controlunitcanbeverycomplex

18

Robotexample

•  AnExperimentalrobotisequippedwithfouragents:–  SensorHandlerAgent,–  CollisionDetectorAgent,–  CorridorRecognizerAgentand–  DriveControllerAgent

(Includesthecontrolsoftware)•  Agentsandblackboardformthecontrolsystem.Agentcooperationisreachedby

meansoftheblackboard.Blackboardisusedasacentralrepositoryforallsharedinformation.

•  Onlytwoagentshaveanaccesstotheenvironment:SensorHandlerAgentandDriveControllerAgent.

•  Thereisnoglobalcontrollerforalloftheseagents,soeachofthemindependentlytriestomakeacontributiontothesystemduringthecourseofnavigation.

•  Basicallyeachofthefouragentsexecutesitstasksindependentlyusinginformationontheblackboardandpostsanyresultbacktotheblackboard.

19

….patternsrelatedtothecommunicationinfrastructure

•  Messaging–  DistributionInfrastructure

•  Publisher-Subscriber–  DistributionInfrastructure

•  Broker–  DistributionInfrastructure

•  ClientProxy–  DistributionInfrastructure

•  Reactor–  EventDemultiplexingandDispatching

•  Proactor–  EventDemultiplexingandDispatching

20

MessagingPattern•  Somedistributedsystemsarecomposedofservicesthatweredeveloped

independently.

•  However,toformacoherentsystem,theseservicesmustinteractreliably,butwithoutincurringoverlytightdependenciesononeanother.

•  Solution: Connect the services via a message bus that allows them totransferdatamessagesasynchronously.–  Encodethemessagessothatsendersandreceiverscancommunicate

reliably without having to know all the data type informationstatically.

21

Messaging(continued)•  Message-based communication supports loose coupling between services in a

distributedsystem.

•  Messages only contain the data to be exchanged between a set of clients and

services,sotheydonotknowwhoisinterestedinthem.–  Therefore, another way is to connect the collaborating clients and services

using amessage channel that allows them to exchangemessages, known as“MessageChannel”.

22

Publisher-SubscriberPattern

•  Components in some distributed applications are loosely coupled andoperatelargelyindependently.

•  ifsuchapplicationsneedtopropagateinformationtosomeoralloftheircomponents, a notification mechanism is needed to inform thecomponentsaboutstatechangesorotherinterestingevents.

•  Solution: Define a change propagation infrastructure that allowspublishers inadistributedapplicationtodisseminateeventsthatconveyinformationthatmaybeofinteresttoothers.–  Notify subscribers interested in those events whenever such

informationispublished.

23

Publisher-Subscriber(continued)

•  Publishersregisterwiththechangepropagationinfrastructureto informitaboutwhattypesofeventstheycanpublish.

•  Similarly, subscribers registerwith the infrastructure to inform it aboutwhattypesofeventstheywanttoreceive.

•  Theinfrastructureusesthisregistrationinformationtorouteeventsfromtheirpublishersthroughthenetworktointerestedsubscribers.

24

Event-BusPattern

25

•  Eventsourcespublishmessagestoparticularchannelsonaneventbus.•  Eventlistenerssubscribetoparticularchannels.•  Listenersarenotifiedofmessagesthatarepublishedtoachanneltowhichtheyhave

subscribed.•  Generationandnotificationofmessagesisasynchronous:aneventsourcejust

generatesamessageandmaygoondoingsomethingelse;itdoesnotwaituntilalleventlistenershavereceivedthemessage.

BrokerPattern•  Distributed systems face many challenges that do not arise in single-process

systems.–  However, application code should not need to address these challenges

directly.

•  Moreover, applications should be simplified by using amodular programmingmodelthatshieldsthemfromthedetailsofnetworkingandlocation.

•  Solution:Useafederationofbrokerstoseparateandencapsulatethedetailsofthe communication infrastructure in a distributed system from its applicationfunctionality.

•  Define a component-based programming model so that clients can invokemethodsonremoteservicesasiftheywerelocal.

26

Broker(continued)

•  Ingeneralamessaginginfrastructureconsistsoftwocomponents:

–  A“Requestor”forwardsrequestmessagesfromaclienttothelocalbrokeroftheinvokedremotecomponent;

–  While an “Invoker” encapsulates the functionality for receiving requestmessages sentbya client-sidebrokeranddispatching these requests to theaddressedremotecomponents.

27

Client-ProxyPattern•  When constructing a client-side BROKER infrastructure for a remote

componentwemustprovideanabstraction thatallowsclients toaccessremotecomponentsusingremotemethodinvocation.

•  A “ClientProxy /RemoteProxy” represents a remote-component in theclient’saddressspace.

•  The proxy offers an identical interface that maps specific methodinvocations on the component onto the broker’s message-orientedcommunicationfunctionality.

•  Proxiesallowclientstoaccessremotecomponentfunctionalityasiftheywerecollocated.

28

EventDemultiplexing&Dispatching

•  At itsheart,distributedcomputing isallabouthandlingandrespondingtoeventsreceivedfromthenetwork.

•  There are patterns that describe different approaches forinitiating, receiving, demultiplexing, dispatching, andprocessingeventsindistributedandnetworkedsystems.

•  …twoofthesepatterns:Reactor;Proactor;

29

ReactorPattern•  Event-drivensoftwareoften

–  receivesservicerequesteventsfrommultipleeventsources,whichitdemultiplexesanddispatchestoeventhandlersthatperformfurtherserviceprocessing.

•  Eventscanalsoarrivesimultaneouslyattheevent-drivenapplication.–  To simplify software development, events should be processed

sequentially|synchronously.

30

Reactor(continued)•  Solution:Provideaneventhandlinginfrastructurethatwaitsonmultipleevent

sources simultaneously for service request events to occur, but onlydemultiplexes and dispatchesone event at a time to a corresponding eventhandlerthatperformstheservice.

•  Itdefinesaneventloopthatusesanoperatingsystemeventdemultiplexertowaitsynchronouslyforservicerequestevents.

•  By delegating the demultiplexing of events to the operating system, thereactorcanwaitformultipleeventsourcessimultaneouslywithoutaneedtomulti-threadtheapplicationcode.

31

ProactorPattern•  To achieve the required performance and throughput, event-driven applications

mustoftenbeabletoprocessmultipleeventssimultaneously.

•  However, resolvingthisproblemviamulti-threading,maybeundesirable,duetotheoverheadofsynchronization,contextswitchinganddatamovement.

•  Solution:–  Splitanapplication’sfunctionalityinto

•  asynchronousoperationsthatperformactivitiesoneventsourcesand•  completionhandlersthatusetheresultsofasynchronousoperationstoimplementapplicationservicelogic.

–  Lettheoperatingsystemexecutetheasynchronousoperations,but–  executethecompletionhandlersintheapplication’sthreadofcontrol.

32

Proactor(continued)•  Aproactorcomponentcoordinatesthecollaborationbetweencompletionhandlers

andtheoperatingsystem.–  Itdefinesaneventloopthatusesanoperatingsystemeventdemultiplexerto

wait synchronously for events that indicate the completionof asynchronousoperationstooccur.

•  Initiallyall completionhandlers ‘proactively’ call anasynchronousoperation towait for service request events to arrive, and then run the event loop on theproactor.

33

Proactor(continued)

•  When such an event arrives, the proactor dispatches the result of thecompleted asynchronous operation to the corresponding completionhandler.

•  This handler then continues its execution, which may invoke anotherasynchronousoperation. 34

Reactorvs.Proactor•  Althoughbothpatternsresolveessentiallythesameprobleminasimilarcontext,

and also use similar patterns to implement their solutions, the concrete event-handlinginfrastructurestheysuggestaredistinct,duetotheorthogonalforcestowhicheachpatternisexposed.

•  REACTORfocusesonsimplifyingtheprogrammingofevent-drivensoftware.–  Itimplementsapassiveeventdemultiplexinganddispatchingmodelinwhich

services wait until request events arrive and then react by processing theeventssynchronouslywithoutinterruption.

–  Whilethismodelscaleswellforservicesinwhichthedurationoftheresponsetoarequestisshort,itcanintroduceperformancepenaltiesforlong-durationservices, since executing these services synchronously can unduly delay theservicingofotherrequests.

35

Reactorvs.Proactor(cont.)•  PROACTORisdesignedtomaximizeevent-drivensoftwareperformance.

–  It implements amoreactiveevent demultiplexing and dispatchingmodel inwhichservicesdividetheirprocessingintomultipleself-containedpartsand

–  proactivelyinitiateasynchronousexecutionoftheseparts.–  This design allows multiple services to execute concurrently, which can

increasequalityofserviceandthroughput.

•  REACTORandPROACTORarenotreallyequallyweightedalternatives,butratherare complementary patterns that trade-off programming simplicity andperformance.–  Relatively simple event-driven software can benefit from a REACTOR-based

design,whereas–  PROACTOR offers a more efficient and scalable event demultiplexing and

dispatchingmodel.

36

37

Middleware

•  In computer science, a middleware is a software layer that residesbetweentheapplicationlayerandtheoperatingsystem.

•  Itsprimaryroleistobridgethegapbetweenapplicationprogramsandthelower-level hardware and software infrastructure, to coordinate howpartsofapplicationsareconnectedandhowtheyinter-operate.

•  Middleware also enables and simplifies the integration of componentsdevelopedbydifferenttechnologysuppliers.

38

Middleware(continued)

•  An Example of amiddleware for distributed object-orientedenterprisesystemsisCORBA.

•  Despite their detailed differences, middleware technologiestypicallyfollowoneormoreofthreedifferentcommunicationstyles:–  Messaging–  Publish/Subscribe–  RemoteMethodInvocation

39

Referinte•  FrankBuschmann.KevlinHenney.DouglasC.Schmidt.Pattern-Oriented

SoftwareArchitecture,Volume4:APatternLanguageforDistributed-Computing.Wiley&Sons,2007

•  GeorgeCoulouris.JeanDollimore.TimKindberg.GordonBlair.DISTRIBUTEDSYSTEMS:ConceptsandDesign.FifthEdition.Addison-Wesley.

40