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