1 pattern: data ﬂo w architecture · c 1998dragosa.manolescu 3 scalability in several dimensions...

Copyright c�

1998DragosA. Manolescu 2

1 Pattern: Data flow architecture

Context

Sometimesthe solutionsfor differentproblemsshareseveral identicalsteps,yeteachproblemrequiresits own solution.

Considerfor examplemultimediaapplicationsthatprocessJPEGstill imagesandMPEGvideos.A JPEGviewer appliesfive transformationsandeachof themis performedin a separatestep: JPEGsyntaxdecoder, dequantizer, inverseDCTtransformer, framedecoderandcolor conversion.Likewise,anMPEGplayerap-plies four transformations:MPEG syntaxdecoder(for simplicity, this alsodealswith temporaland spatialprediction), inverseDCT transformer, frame decoderandcolor conversion. For both applications,the transformationsareappliedse-quentially, in thesameorder.

The inverseDCT transformerandcolor conversionare identicalandoperateon the samedatatypes—imagesrepresentedwith oneluminancecomponent(Y)and two chrominancecomponents(Cb and Cr). The interactionwith the othertransformationsis limited. Controlflow is staticandthesuccessionof stepsrarelychanges—usually, only for exceptionalcircumstances.Eachtime theinverseDCTtransformeris presentedasetof coefficients,it computesthecorrespondingspatialrepresentation.Next this is passedto theframedecoder.

Problem

Processingwithin yourdomainis performedby applyingasequenceof operationson similar dataelements,in thesameorder. You wanta reusabletoolkit thatcanbeusedto build softwaresolutionsfor a wide rangeof applicationswithin thedo-main.Yourapplicationsarealsorequiredto dynamicallychangetheirfunctionalityand/oradaptto changingenvironments,withoutcompromisingperformance.Whatarchitecturecanaccommodatetheserequirements?

Forces� A high-performancetoolkit that is applicablefor a wide rangeof problems

from aspecificdomainis required;

� The application’s behavior needsto be modified dynamicallyor adapttochangingenvironmentsat runtime;

� Theloosecouplingassociatedwith theblack-boxparadigmhasperformancepenalties;

Copyright c�


� Scalabilityin severaldimensionsis required.

Solution

A dataflow architectureorganizesapplicationsasa network of processingmod-ules1 that apply a seriesof transformationsto oneor several datastreams.Eachmoduletakesits input from someupstreammodules,performsa simple,generictransformationand passesthe resultsto someother downstreammodules. En-forcing strict, simple inter-module interfacesyields a large numberof possiblecombinationsthatprovidesolutionsto many problemswithin aparticulardomain.Therefore,in dataflow architectures,processingmodulesare the computationalunits, while thenetwork representstheoperational unit.

Consequently, thefunctionality(transferfunction)is determinedby the:

� typesof processingmoduleswithin thenetwork; and

� interconnectionsbetweenthem.

Figure 1 shows a dataflow JPEGdecoder. The decoderreadsa JPEGfile andshows its contentson a display. Decodersfor otherformatsareimplementedbyconnectingdifferentmodules.

Filereader

Syntax decoder+dequantizer

Framedecoder

Colorconversion

��

IDCT

Static Dynamic CompositionComposition

Display

� � ��

Figure1: A dataflow JPEGdecoder.

Thisarchitectureis applicableonly for data-drivenapplications,wheretheout-put is obtainedby performingvarioussequentialtransformationsto the input. Itallowsapplicationsto scalewith thenumberof datastreams.Thetransferfunctionis determinedby a combinationof the individual transferfunctionsof eachpro-cessingmodule.Controlflow is distributedacrosstheparticipatingentitiesandisnotexplicitly representedat thearchitecturallevel.

Modulesplay a key role in dataflow architectures.Applicationsthat followthis patternmanifestanincreaseddegreeof modularity. Thismakesit easyto dis-tributethedevelopmenteffort amongdifferentgroups.For example,visualization

1In thiscontext, “module” is any processingunit within theapplicationdomain.

Copyright c�


modulesaredevelopedby thevisualizationgroup,while MPEGmodulesarebuiltby themultimediagroup,etc. Therefore,theknowledgeof domainexpertsis en-capsulatedwithin processingmodulesthatarereusablein many differentcontexts.

Thefollowing designguidelinesareessentialfor genericandreusableprocess-ing modules:

� The transferfunctionshouldnot modelthedomain,dependon a particularsolutionor have sideeffects.

� Eachmoduleshouldbedevelopedindependentlyof its use.

� Processingmodulesshouldcooperateonly by using the outputof one(orseveral)astheinput to another.

Decouplingthe algorithmic propertiesof processingmodulesfrom a particularproblemallows applicationsto usethemasblack-boxes. However, theblack-boxapproachdoesnot take into accountcontext-specificfactorsandthereforehasper-formancepenalties.Goodfiltersbalancethesetwo conflictingforces.

Thefine granularitydecompositioninto simpletransformationsis an incarna-tion of the“divideandconquer”principle: insteadof attemptingto solveacomplexproblemall atonce,split it intosub-partsanddealwith eachseparately. Thisallowsapplicationsto scalewith thenumberof transformationsandprocessors—eachpro-cessingmodulecanrun on a separateprocessor. However, becauseof thereducedcommunicationoverhead,specializedprocessingmodulesaremoreefficient thanimplementingtheir functionality with several genericfilters. But specializationalsolimits the numberof possibleconfigurationsthat a filter canbe part of. Forexample,asinglespecializedJPEGdecodermoduleoffersbetterperformancethanthedecoderfrom Figure1. However, in thelattercasefilters arereusableandcanbeemployedfor otherapplications(e.g.,anMPEGdecoder).Filter designershaveto determinetheright balancebetweengranularityandperformance.

Thefine granularitydecompositionhassomeotheradvantages.Considerhowelectricalengineersanalyzeor testacircuit. They useanoscilloscopeto checkthesignalsat differentkey points. This requiresaccessto each component, andthefirst stepis to remove thecoversthatenclosethecircuit. Becauseof its modularstructure,thedata flow architecture provideseasyaccessto its computationalunits,theprocessingmodules.Like for theelectricalcircuit, this enablessoftwareengi-neersto analyzeandtesttheapplication.For example,thedecoderfrom Figure1providesdirectaccessto theIDCT coefficients,shouldthey berequiredfor analy-sisor testing.Analyzinga functionallyequivalentdecoderwhich doesnot followthis patternrequiresmoreeffort to get to thesecoefficients. Therefore,from an

Copyright c�


electricalengineeringperspective,dataflow applicationsdonothave “covers” thatpreventaccessto their components.

Easyaccessto dataatdifferentprocessingstagesalsoenablesdevelopersto usesignalprocessingtechniques(translation,interpolation,etc.). For fields like mul-timediaor scientificvisualization,thesetechniqueshave beenshown to improveperformance[PLV97].

Inter-modulecommunicationis doneby passingmessagesor tokensthroughunidirectionalinputandoutputports—shown asblue(input)andred(output)plugsin Figure1. Therefore,dataflow systemsreplaceinter-moduledirectcallswith amessagepassingmechanism.Theoverheadassociatedwith this mechanismis themainliability of thepattern.

Dependingon their ports,modulesareclassifiedasfollows (a comprehensiveclassificationaccordingto variouscriteriais availablein [Lea96]):

Sources Interfacewith aninputdevice andhave oneor severaloutputports.

Sinks Interfacewith anoutputdevice andhave oneor severalinputports.

Filters Have both input and output ports (not necessarilyonly one in eachdi-rection)andperformprocessingon the informationfed into the input port.Whenprocessingcompletes,thefilter writestheresultsto theoutputport.

In Figure1, thefile readeris a source,thedisplayadapteris a sink andtheotherprocessingmodulesarefilters.

Unidirectionalinputandoutputportsarenota limitation. Rather, they increaseacomponent’s autonomy. Providedthattherearenofeed-backloops,processingisunaffectedby thepresenceor absenceof connectionsat theoutputport(s).There-fore,becauseany componentdependsonly on theupstreammodules,it is possibleto changeits outputconnectionsat runtime. This is calleddynamiccompositionanddeterminessomeof theinterestingpropertiesof dataflow architectures.

To allow interconectivity betweentwo modules,theoutputportof theupstreammoduleandtheinput port of thedownstreammodulehave to beplug-compatible.(For simplicity, in Figure1 all moduleshave thesametypeof port.) However, hav-ing many port (plug) typeslimits interconectivity andrequiresadaptersto connectincompatibleports.

Two priority levelsareavailablefor processingat thefilter level. High prior-ity processingcanbe donewhenthe filter receivesa messagefrom the upstreammodule. Onceacquired,thedatacanbeprocessedat a later time, at lower prior-ity. For instanceswhereprocessingis time-comsuming—e.g.,scientificvisualiza-tion applications—thetwo priority levels areimportant. Otherwise,if the output

Copyright c�


valuescanbecomputedrelatively fast,all processingis performedat high prior-ity. However, scheduling(i.e., “when” the actualprocessingtakesplace)is non-deterministicin bothcases.

Applicationsfollowing the dataflow architecturecanadaptto heterogeneousanddynamicallychangingenvironmentsatruntime.Differentimplementationsforstatelessfilters areexchangedto adjustthe resourcecostandquality characteris-tics within someuser-definedlimits. In Figure 1, two different IDCT modulesareavailableanddependingontheircharacteristics,thedecoderusesoneor theother. Therefore,dynamiccom-positionallowsanapplicationto (1) adjusttheresourceconsumptionof the systemat runtime, and (2) adaptto different computingand communicationsenviron-ments,aswell aschangesin resourceavailability.

Sometimestheoverheadof inter-modulecommunicationhasunacceptableper-formancepenalties. An effective solution for this problemis to tradeflexibil-ity for performance[PLV96]. This is accomplishedby replacingthe adjacentperformance-criticalmoduleswith asingleoptimizedmodule.Staticcompositionprovidestheunderlyingapplication(e.g.,compiler)withenoughinformationto collapsethesequenceof filtersinto afunction-ally equivalentprimitivefilter, reducingtheoverheadof inter-modulecommunication.However, thiscannotbemodifiedat runtimeanylonger.

Staticbindingshouldbeusedto improve performancefor filters thathave lowreconfigurabilitydemandsandarecalledwith highfrequency. Dynamicbindingisbestsuitedfor filters thathave high reconfigurabilitydemandsandlow invocationfrequency. A goodbalancebetweenthe useof staticand dynamiccompositionensuresefficient implementationswhile maintainingaflexible, configurablearchi-tecture.Therefore,dataflow applicationsarescalablewith differentcommunica-tion andprocessingrequirements.For theJPEGdecoderfrom Figure1, thesyntaxdecoderis calledmany timesfor eachimageandthereforeis staticallyboundtothedequantizer[PLV97]. Theothercomponentsarecalledwith lower frequenciesandthemessagepassingoverheadis tolerable.

Posnaket al [PLV97] provide a quantitative evaluationof a dataarchitecturein the context of their PresentationProcessingEngineframework. The analysisconsidersthedimensionsin which this patternhasthestrongestimpact:reuseandperformance. (i) To estimatereuse,they considerthe taskof building a mediaplayerplug-in for Netscape.UsingthePPE,this requiresa few linesof Tcl code(seebelow) andlittle domainexpertise. In contrast,reusingtheBerkeley MPEGsourcecode(thereforestartingfrom a working product)requiresa good under-standingof the existing codeand a significantly larger programmingeffort anddomainexpertise.(ii) For performanceevaluation,they comparePPEapplications

Copyright c�


with commercialproducts.Thedecodingtimefor aJPEGimage(with thedecoderfrom Figure1) is within 5% of thetime requiredby theIndependentJPEGGroupdecoder. Similarly, the framerateof anMPEGplayeris at most10%lower thantheBerkeley player. Theseresultsshow thatthedata flow architecture canprovidereusable,high-performancesoftwaresolutions.

Usersfamiliar only with theapplicationdomain(e.g.,scientificvisualization)cancreatenew applicationsby simply connectingexisting modules,without per-formingany otherprogramming.Thisisaccomplishedwith scriptinglanguages[Lin94,JBR96] or visualprogrammingtools [AEW96] thatassistthecreationof modulenetworks[Foo88].

Thenetwork normallytriggersrecomputationswheneverafilter’soutputvaluechanges. While manipulatedinteractively, it shouldbe possibleto temporarilydisablethe network suchthat no computationtriggersuntil the network is in avalid, stablestate.Disablingcomputationsis usefulif severalparametersneedtobemodifiedwithout having thefilters recomputeevery time a changeis made,orif processingtakesa long time.

To summarize,the data flow architecture hasthe following benefits (✓) andliabilities (✗):

✓ It emphasizesreuseat theprocessingmodulelevel andfacilitatestheriseofend-userprogramming,automationandsoftwarecomponents.

✓ Becausethe interactionmechanismbetweenmodulesis simple, the archi-tectureis suitablefor domain-specificframeworksandoftenis thesubjectofvisualprogrammingtools.

✓ Dataflow applicationsarescalablein severaldimensions—numberof trans-formations,processors,datastreams;and communicationand processingrequirements.

✓ Thefine granularitydecompositioninto simplefilters providesaccessto thedatastreamatvariousprocessingstages.

✗ A dataflow architectureis not a goodchoicefor applicationswith dynamiccontrolflow or feedbackloops.

✗ For instanceswheretheoverheadof enforcingthe inter-moduleinterfaceistoohigh,adifferentarchitecturalchoicemightbeabettersolution.

✗ It doesnot dealwell with unanticipatedconditions. Signalingerrorsthatoccurinsidefilter modulesis cumbersomeanddifficult [BMR � 96]. Modulesdo not make any assumptionsabout their context and communicateonly

Copyright c�


template<class DataType> class PushInput {public:

virtual ˜PushInput() { };virtual void Put(DataType &data) =0;

};

Figure2: ThePushInput class.

with otherdata-processingmodules.Only whencombinedwith additionalknowledgeaboutthenetwork topologyandtheapplication’s domaincouldanerrormessagegeneratedby amodulebemeaningful.TheProcessing andcontrol partitions patternprovidesonepossiblesolution.

✗ Thearchitectureworksbestfor applicationswheremodulesexchangesimpledataanddo not sharestate. It is not suitablewhenthe exchangeddataiscomplex or for databaseapplications.

Resultingcontext

Applicationsfollowing the data flow architecture canrun on heterogeneousdis-tributedsystems.Becausecontrolflow is not explicitly represented,this changeistransparentfor sources,filtersandsinks.

Implementation notes

This sectionfollows theguidelinesfrom [PLV96]. Processingmodulesinherit aninput interface(port) from PushInput andanoutputinterfacefrom PushOutput .PushInput —Figure 2—is an abstractclassthat determinesthe input datatype.Subclassesimplementthe Put() methodto processthe input dataand passitdownstream. PushOutput —Figure 3—determinesthe outputdatatype and de-finesmethodsfor dynamiccomposition—Attach() andDetach() . Attachmentbetweentwo modulesis abstractedby thePushPort class—Figure4. This facili-tatesestablishingone-to-many connections,in which casePushOutput hasto bemodifiedaccordingly.

C++ templatesparameterizetheclassespresentedin Figures2–4by thetypesof datathatentersandleaveseachprocessingmodule.Thecompiler’s typecheck-ing systempreventsconnectingtwo moduleswhicharenotplug-compatible.

Basedon theseclasses,implementingprocessingmodulesis straightforward.Figure5 shows thecodecorrespondingto a modulethattakesoneinteger input

Copyright c�


template<class DataType> class PushOutput {public:

virtual ˜PushOutput() { };virtual void Attach(PushInput<Da taT ype > *next)

{_port=new PushPort<DataType>( nex t);

};virtual void Detach()

{delete _port;

};protected:

inline void Output(DataType &data) { _port->Output(data ); };private:

PushPort<DataType> *_port;};

Figure3: ThePushOutput class.

template<class DataType> class PushPort {public:

PushPort(PushInput <DataT ype > *module): _module(module) { };

˜PushPort() { };inline void Output(DataType &data) { _module->Put(data ); };

protected:PushInput<DataType > *_module;

};

Figure4: ThePushPort class.

Copyright c�


class Sqrt : public PushInput<int>, public PushOutput<double> {public:

Sqrt() { };˜Sqrt() { };void Put(int &i){

double d=sqrt(i);Output(d);

};};

Figure5: An Sqrt processingmodule.

andoutputsits squareroot. However, this simpleimplementationhasseverallimi-tationswith respectto how processingis initiatedandhow datais passedbetweenmodules.Thefollowing sectionscover theseaspectsandprovidealternatives.

In this example,typeparameterization—templates—and functioninlining areusedto implementstaticcomposition.Figure6 shows thecodecorrespondingto afilter thatincrementsits integer input. Processing—incrementing—is performedby the Transform() inline method.The FastInc classcanparameterizethefil-ter from Figure7. BecauseFastFilter invokes only the inlined Transform()method,FastInc ’s input andoutputportsarebypassedandthe implementationis efficient. Figure8 shows how to instantiatethestaticcompositionof FastIncwith FastFilter . Theresultingfilter first incrementsthe input andthenoutputsits squareroot. Theideabehindimplementingstaticcompositionis bypassingtheinput andoutputportsto eliminatethecommunicationoverhead.This canbeac-complishedin any languageanddoesnot requiretemplatesandinline methods.

Examples

1. Scientific visualization is one domainwherethe data flow architecture isusedextensively. Systemslike AVS [AVS93] or Iris Explorer[EXP93] al-low usersto createvisualizationapplicationsandvisualizevariousdatatypesin many differentways.This is doneby connectingmodulesinto anetwork,with thehelpof a visualnetwork editor. Becausethey provide a wide rangeof genericfilters, thesesystemsoffer solutionsto a largenumberof visual-izationproblems.Figure9 shows anexampleof anAVS network.

Whenever required,the existing setof filters canalsobe expanded. Newfiltersarecreatedwith amodulebuildertool. Thisallowsend-usersto extend

Copyright c�


class FastInc : public PushInput<int>, public PushOutput<int> {public:

FastInc() { };˜FastInc() { };virtual void Put(int &i)

{int j=i;Transform(j);Output(j);

};inline void Transform(int &i) { i++; };

};

Figure6: A filter for staticcomposition.Only the inlined methodis usedby thecompositefilter.

template<class T>class FastFilter : public PushInput<int>, public PushOutput<double> {public:

FastFilter(T &component): _component(compon ent ) { };

˜FastFilter() { };virtual void Put(int &i)

{int j=i;_component.Transf orm(j) ;double d=sqrt(j);Output(d);

};private:

T _component;};

Figure7: A compositefilter.

FastInc fi;FastFilter<FastInc > ff(fi);

Figure8: Instantiatingthecompositefilter.

Copyright c�


Figure9: AVS Network. Top sideportsare inputs,while bottomsideportsareoutputs. The port typesarecolor-codedandthe network editor doesnot permitconnectingincompatibleports.

functionalitywith aminimalamountof programming.

2. Dataflow architectureshavealsobeeninvestigatedfor hardwaresystems[Gur85,Pap91]. Theexecutionmodeloffersattractivepropertiesfor parallelprocessing—implicit synchronizationof parallelactivitiesandself schedulability. Unlikethe von Neumannmodel which explicitly statesthe sequenceof instruc-tions, in the dataflow model the executionof any instructionis driven bytheoperandavailability. Thisemphasizesahighdegreeof parallelismat theinstructionlevel. TheMonsoonProject[Pap91] developedby MIT andMo-torolaproduceda data-flow multiprocessortargetedto large-scalescientificandsymboliccomputation.Its successmotivatedmuchof thework onsim-ilar projects[NPA92] andcontributedto spreadtheinterestin dataflow andparallelprogramming.

3. AvionicsControl Systems(ACS)alsoemploy thispattern[Lea94]. BecauseACSarecomplex systems,constructinga setof componentsthatmergeallpossiblecombinationsis notfeasible.Thedata flow architecture providesthemeansfor combiningtogetherdifferenttypesof existingcomponents(filters)to serve aparticularpurpose.

4. Anotherdomainwherethe data flow architecture is employed by applica-

Copyright c�


tions(ActiveMovie [AMS], VuSystem[Lin94]), toolkits(Berkeley Continu-ousMediaToolkit [JBR96]) andframeworks(MET++ [Ack94], PresentationProcessingEngine[PLV97], Java MediaFramework [SUN97]) is multime-dia [MN98].

VuSystemapplications2 illustrateverywell theflexibility of thisarchitecture.In the“room monitor,” theoutputof a surveillancecamerais analyzedsuchthat just the framesthat containmotion arerecorded.The “joke browser”extractsonlyselectedparts(e.g.,jokes)from thecompleterecordingof alatenight show. Althoughthesetwo applicationsarevery different(the formerprocessesreal-timevideo while the latter provides content-basedaccess),bothof themhave beenbuilt with thesametool just by connectingexistingmodules.

ActiveMovie allows usersto playdigital moviesandsoundencodedin vari-ousformats.It consistsof sources,filters andrenderersconnectedin a filtergraph.All graphcomponentsareimplementedasComponentObjectModel(COM) objects. Filters have pins which are connectedwith streams,butother communicationchannelsfor specializedcommunication(e.g., errornotifications)areavailable.

Thepresenceof thedata flow architecture within theforthcomingJavaMediaFramework demonstratesits validity andconfirmsit asa recurringsolutionthathaspassedthetestof time.

Variants3

1. Bill Walker’s Ph.D.thesis[Wal94] presentsa framework thatusesthis pat-tern in the context of computer-assistedmusic. Unlike typical dataflowarchitectures,thissystemhasfeedback loopsandsharedstate. Theprocess-ing modulesarecalledComposers andTransformers . Global informationindependentof thecomponentsis encapsulatedwithin aPolicyDictionaryobject.

2. In [Rit84], DennisRitchie describesa variantof this patternandhow it isimplementedin the UNI X stream system. Dataflow is bidirectionalandfilters have queuesfor eachdirection. The queuesare also employed forflow control—Section3.

2Some of the VuSystem applications are available on the world-wide web athttp://www.tns.lcs.mit.edu/vs/vusystem.html .

3Thedifferencesbetweenthedataflow architectureandthevariantsdiscussedin thissectionareshown in italics.

Copyright c�


RelatedPatterns� Messagesencapsulateall typesof informationexchangedby collaborating

modules.ThePayloads patternallows modulesto distinguishbetweenmes-sagesandthedatawithin them.

� Data flow architectures replaceinter-moduledirectcallswith amessagepass-ing mechanism.ThePayload passing protocol patternsprovideseveralalter-nativesfor thismechanism.

� A distinctpartof adataflow applicationis in chargewith dynamiccomposi-tion andhandleserrormessages.Processing and control partitions describeshow to organizesuchapplications.

� Systemsfollowing theLayers pattern[BMR � 96] areorganizedaslayersthatexchangedatabetweenthem. However, in this caseeachlayercorrespondsto adifferentabstractionlevel wheredatahasdifferentsemantics.

� Staticcompositionis aninstanceof theComposite pattern[GHJV95]. Thisensuresa consistentinterfacebetweenprimitive (e.g.,staticallycomposedfilter) andcontainer(e.g.,sequenceof filters)objects.

� Streams [Edw95], Pipes and filters [Meu95, BMR � 96] andPipeline [Sha96]provide similar solutions.However, thedata flow architecture is moregen-eral.For example,Pipes and filters takesamorestaticapproach,whereoncetheprocessingpipelineis setup, it is notallowedto change.

Copyright c�


2 Pattern: Payloads

Context

In the landmarkpaper“The Early History of Smalltalk” [Kay93], Alan Kay re-membersa few ideasfrom thesixtiesthathave influencedhis thinkingaboutOOP.Oneof themwasthemethodof transportingfiles on tapefor theBurroughs220,while hewasworkingasaprogrammerin theAir Force(around1961):

Therewereno standardoperatingsystemsof file formatsbackthen,sosomedesignerdecidedto finessethis problemby takingeachfileanddividing it into threeparts. The third part wasall of the actualdatarecordsof arbitrarysizeandformats.Thesecondpartcontainedthe B220 proceduresthat knew how to get at recordsand fields tocopy andupdatethethird part.And thefirst partwasanarrayof rela-tivepointersinto entrypointsof theproceduresin thesecondpart(theinitial pointerswerein a standardorderrepresentingstandardmean-ings).

Currentcomputersystemsusedifferentmeansto exchangeinformation. Inmostcircumstances,this is doneby passingmessagesthrougha fastcommunica-tion channel.However, theabove requirementsarethesame.(i) Messagesencap-sulateall typesof information,includingcontrolanddataof variablelength.Thiscorrespondsto thethird partof theB220file. (ii) Applicationsneeda mechanismto accessthe varioustypesof informationwithin messages.The mechanismde-pendson themessagecontentsandcorrespondsto theB220procedures.(iii) Thestandardpiecesof informationassociatedwith eachmessagearerequiredby allmessagehandlers—applicationsthathandlemessages.Thiscorrespondsto thear-rayof pointers.

Problem

Communicationwithin a software systemis performedby exchangingdifferenttypesof messagesbetweencommunicatingentities. How to distinguishbetweenmessagesandtheinformationwithin messages?

Forces� Communicationis restrictedto messagepassing;

� Thestructureof eachmessagedependson theinformationthatit contains;

Copyright c�


� Thecommunicatingentitiesexchangemany differenttypesof information;

� Applicationsreceive a wide rangeof messages,includingmessagesthey donotprocess;

� Dependingontheinformationthey encapsulate,somemessagesneedspecialprocessing.

Solution

Representmessageswith payloads. A payloadprovides an abstractmodel thatallows the communicatingentitiesto identify differentmessagetypes,aswell asdistinguishtheinformationencapsulatedwithin eachpayload.

Payloadshave two components:

Descriptor component Descriptorscontaingeneral informationaboutthe mes-sage,suchastype,asynchronousflag, priority level, etc. For eachmessagetype,thedescriptoralsocontainstype-specificparameters. For example,ifthepayloadcontainsanimage,onepossibilityis to encodeits name,sizeandformat.

Data component The datacomponentholds the informationtransportedby themessage.Its sizeandformatdependon thedescriptorcomponent.

Thepreviouscomponentsoffer solutionsfor two of therequirementsidentifiedin “Context.” Thedescriptorprovidesa standardway to organizethe informationabouteachpayload.It correspondsto thefirst partof theB220file. Similarly, thedatacomponentcontainstheactualinformation.Thiscorrespondsto thethird partof thefile. However, so far noneof this componentsoffersbehavior—the secondpart.This is coveredlateron in thissection.

Not all payloadscontainboth components.Sometimespayloadsthat corre-spondto controlmessagesdo not needany additionaldata.Therefore,thesepay-loadscontainonly thedescriptor. Whenever bothcomponentsarepresent,thesizeof thedatacomponentis usuallymuchlargerthanthedescriptor. Thischaracteris-tic is usedto optimizethepayloadcopying mechanism—seebelow.

Figure 10 shows a control payloadand a datapayloadcorrespondingto animage. The generalinformationencodedin the descriptorcontainsthe messagetype,an asynchronousflag anda priority level. In contrast,the descriptorof thedatapayloadcorrespondsto animageandhasthreeadditionalfields.Thesecontaintheimagename,sizeandformat.

An object-orientedapproachis anelegantsolutionfor payloads.Polymorphismprovidesbehavior parameterizedby thedatatype.This renderstheexplicit encod-ing of thepayloadtypein thedescriptorunnecessary. Removing theresponsibility

Copyright c�


TypeAsynchronousPriority

Type-specificParameters

Descriptor

Data

DescriptorImage NameImage SizeFormatImage Data

TypeAsynchronousPriority

Control Payload Data Payload

Figure10: Differentpayloadsandtheircomponents.

of messagetypecheckingfrom theprogrammerreducescomplexity andimprovesefficiency. Inheritancegroupstheattributesandbehavior commonto all messagetypesin asuperclass,thuspromotingreuse.Addinganew payloadrequiresonly toaccommodatethenew attribute(s)—ifany—andto provide theappropriatebehav-ior. Existingsoftwarecontinuesto work with new payloadsthroughthesuperclassinterface.Therefore,unlessit requiresthenew attributesor data,softwarecanbereusedwithoutmodification.Encapsulationallowsattributeslikeanasynchronousflag or a priority level to beassociatedwith eachpayload.Relocatingtheknowl-edgeaboutthis information insidepayloadsdecreasesthe couplingbetweenthecommunicatingentitiesandthe messagesthey exchange.Consequently, as longasthepayloadinterfacedoesnotchange,attributerepresentationscanbemodifiedwithoutaffectingexistingpayloadhandlers.

In concertwith a messagepassingmechanism(Section3), payloadsreplacedirect callswhenthesearenot feasible.Onecircumstanceis whenever thecom-municatingentitiesresideacrosslogical boundaries.This is typical to distributedsystemsandmultiprocessorcomputers.Applications(processes)runningondiffer-entmachinesor processorsexchangedataonly by sendingmessagesto eachother.Anothercircumstanceis whenever thecommunicatingentitiesexchangecomplexdata.Inter-layercalls in a layeredoperatingsystemtypically requirea largenum-ber of parameters.Several modernoperatingsystemshave replacedthesecallswith amessagepassingmechanism[TW97].

Although payloadsoffer several benefitsover direct calls, thesedo not comefor free. Thepatterntradesperformancefor flexibility. Oneof themainliabilities

Copyright c�


of thispatternis theoverheadrequiredfor payloadassemblinganddisassembling.However, thedecreasedcouplingbetweenthecommunicatingentitiesandthemes-sagesthey exchangefacilitatestheoptimizationof themessagepassingmechanism(Section3). Transfermechanismsthat requireadditionalinformationaboutmes-sagesareableto obtainit directly from themessage,throughawell-definedproto-col. Thiscanhelpreducethemessagepassingoverhead.

Anotheroperationthatmakespayloads(whenusedin conjunctionwith ames-sagepassingmechanism)lessefficient thandirectcallsis payloadcopying. Some-timesit is possibleto substitutepayloadcopying with changeof ownership.How-ever, if thepayloadis sentto multiple recipients,it hasto beclonedsuchthateachreceivergetsits owncopy. But cloningwastesspaceandmaynotevenbeviableforpayloadswith largememoryfootprints. Underthesecircumstances,thereceiverscansharethesamepayload.Shouldareceivermodify theincomingpayload,it hasto obtainits own privatecopy. Whencopying is cannotbeavoided,anoptimizedtechniquecanbeemployed:

Shallow copy Copy just thedescriptorandsharedatacomponents.However, theshareddatacomponentcannotbechanged.

Deepcopy Copy the datacomponentsas well. Implementingthis as copy-on-write canimprove performance.

If theentitiesthatexchangethedataresideacrosshardwareboundaries,changingof ownershipwithout copying cannotbeavoidedandtheentirepayloadhasto betransferred.

Onepossibleway to improve performanceis to packmultiple payloadsintoa singlecontainerpayload[SC95]. A typical instanceis whenever payloadsaretransferredover a network. In this case,althoughthe datatransfercanbe rela-tively fast,initiating individual connectionsis expensive. However, this approachis viable only for high messageratesor bursty traffic, suchthat the senderdoesnot have to hold a messagetoo long beforepassingit further. Containermessagesareemployed by operatingsystemswhich consistof several interactingcompo-nents[TW97, CRJ87]andInformationSystems[Fow97].

Passingpayloadsinsteadof using direct calls hasadditionalconsequences.(i) Payloadshide the detailsof the communicationchannel. Oncecommunica-tion is doneonly by passingpayloads,changesof thecommunicationchannelaretransparent.For example,thecommunicatingentitiescanberelocatedonmultipleprocessingunits thatarelinkedby a high-speednetwork—e.g.,ATM or Ethernet.Therefore,payloadsfacilitatethedistributionof existingapplicationsovermultipleprocessingunits,which canbeheterogeneous.(ii) Payloadsarestandloneobjectsandcanbepersistent.Mission-criticalapplicationsusepersistentmessagesto cope

Copyright c�


with failures.For example,IBM’ sExotica/FMQM(FlowMark onMessageQueueManager)[AAA � 95] projectis a fully-distributedworkflow systemthatemploysIBM’ s MessageQueueInterface(MQI) for persistentmessaging.MQI eliminatestheneedfor acentralizeddatabase,which in many workflow systemsconstitutesasinglepoint of failureandsometimesa bottleneck.Asynchronouscommunicationbetweenapplicationsthatrun at differentpointsin time becomespossible.There-fore, persistentpayloadsoffer increasedresilienceto failures,greaterscalabilityandflexibility of systemconfiguration.

A large numberof applicationsusepayloads. Consequently, automatedtoolsfor payloadmanagementcanbevaluableduringthesoftwaredevelopmentprocess.One suchtool is the MessageTranslationand Validation (MTV) Builder [Eng]from Accel SoftwareEngineering.MTV automatessoftwaregenerationto facili-tatecommunicationbetweensystemsanddevicesof varioustypes.Theautomatically-generatedcodeprovidesmessagetranslationandvalidationcapabilitiesthatcanbeintegratedinto an application. Payloadsare built and modified througha GUI.Startingfrom a visual representation,MTV Builder automaticallygeneratestheinterfacecontrol documents,the translationandvalidationsoftware,andthe testsoftware.Therefore,thecodemaintenancetime is eliminated.

In summary, the payloads patternhasthe following benefits(✓) and liabili-ties(✗):

✓ Payloadsincreasetheoverall flexibility andpermit theadditionof new fea-tures(e.g.,priority levels, supportfor asynchronousevents)with minimalchanges.

✓ Adding new messagetypesdoesnot requirechangingthe existing entitieswhich arenot interestedin them. For example,in a data flow architecture(Section1), filters passdownstreamthe messagesthey do not understand,withoutperformingany processing—alsoknown as“tunneling.”

✓ Messagecontentscan be modifiedat runtime. Modulesinsert or removemessagecomponentsbeforepassingthemfurther. Consequently, thetrafficcanbereducedby piggybackinginformationonpassingmessages.

✗ Themain liability of this patternis its inefficiency whencomparedwith di-rect calls. This is due to the high overheadassociatedwith copying andpayloadassembling/disassembling.

Implementation notes

As mentionedbefore,thekey propertiesof the object-orientedparadigmprovideanelegantsolutionfor thethreerequirementsidentifiedin “Context.”

Copyright c�


class Message {public:

Message();virtual ˜Message();virtual Serialize() =0;virtual Deserialize() =0;/*Other methods for messages*/

};

Figure11: TheMessage abstractbaseclass.

A flexible implementationsolutionis to regardthepayloadasacompositemes-sage[SC95].Concreteclassescorrespondingto variousmessagetypesarederivedfrom theabstractclassMessage—Figure11—andprovide implementationsfor itsinterface. The Payload class—Figure12—is a compositeMessage that extendsthe interfacewith severaldescriptor-specificmethods.In this example,eachpay-loadhasassociatedwith it a priority level andanasynchronousflag. ClientscansubclassPayload to extendthedescriptor-specificinterfacein a transparentway.

Examples

1. Many multimedia applicationsusethepayloads pattern.VuSystem[Lin94]hasVideoFrame for singleuncompressedvideoframe;AudioFragment fora sequenceof audiosamples;and Caption for close-captionedtext. Thepayloadsprovide marshalling/unmarshalling methodswhich allow VuSys-temmodulesto resideondifferentcomputers.In ActiveMovie [AMS], pay-loadsareeithermediasamplesor qualitycontroldata.Mediadataoriginatesat thesourceandis passedonly downstream.Qualitycontroldataprovidesameansto gracefullyadaptto loaddifferencesin themediastream.It is usedto sendnotificationmessagesfrom a renderereitherupstream,or directly toa designatedlocation. All theelementsof thearchitecturearchitecturerec-ognizeanasynchronouseventwhich requiresgracefulflushingof old data,followedby globalresynchronization.

2. AbstractSyntaxNotationOne(ASN.1) [X2088a] is a methodof specifyingabstractobjectsin theOpen SystemsInterconnection(OSI) architecture.TheBasicEncodingRules[X2088b] describehow to encodevaluesof eachASN.1 type as a string of bytes. BER encodeseachpart of a value as a

Copyright c�


class Payload : public Message {public:

Payload();virtual ˜Payload();// Message interfacevirtual Serialize() { /* */ };virtual Deserialize() { /* */ };/*Other methods for messages*/// Payload-specific interfaceint PriorityLevel() const { return _priorityLevel};bool IsAsynchronous() const { return _isAsynchronous};/*

Other descriptor-specific methods*/// Composite interfacevirtual void AddMessage(Message *) { /* */ };virtual void RemoveMessage(Messa ge *) { /* */ };

private:int _priorityLevel;bool _isAsynchronous;/*

Other descriptor-specific data*/vector<Message *> _components;

};

Figure12: ThePayload class.

Copyright c�


(identifier,length,contents) tuple.Theidentifierandlengthcorrespondto thedescriptorcomponent,while the contentscorrespondsto the datacompo-nent. Although ASN.1 and BER have beendesignedfor the application-presentationinterfacewithin the OSI architecture,they have alsobeenap-plied for distributedsystems.

3. As mentionedbefore,this patternis alsoemployedby someoperating sys-tems. In the caseof UNIX streams[Rit84], payloadsare calledmessageblocks. A headerspecifiestheir type (dataor control),aswell asotherat-tributes(e.g.,asynchronousevent).

4. Parallel computing is anotherdomainwherepayloadsareusedextensively,particularlyfor architecturesthatdo nothave sharedmemory. TheMessagePassingInterface(MPI) [SOHL� 96] is astandardizedandportablemessagepassingmechanismwhichrunsonawidevarietyof parallelcomputers.MPImessagescall thedescriptorcomponent“messageenvelope.”

RelatedPatterns� Applicationsthatusethedata flow architecture typically employ payloadsto

encapsulatethedatathatflows throughthenetwork.

Whathappenswhenasourcemodule(for example,afile reader)reachestheendof the input stream?This conditionis signaledby sendingdownstreama payloadthat correspondsto the “end of stream”control message.Themechanismis propagateddown the filter network until it reachesthe sink.Therefore,payloads enablemodulesto exchangecontrol information in atransparentway.

� Marshallingandunmarshallingmethodsrequirepayloadsto reconstructthem-selvesfromabytestream.Thereceiverendcanemploy afactory method [GHJV95]to reconstructtheappropriatetypeof payload.

� Composite message [SC95] facilitatesthe packagingof several messagesinto a composite.Its objective is to improve performanceby reducingthemessagepassingoverhead.

� Theproxy [GHJV95,BMR � 96] patterncanhelpreducetheoverheadof pay-loadcopying. A proxypayloadhasthesameinterfacebut postponesthedatatransferuntil its dataor descriptorcomponentsareneeded.

Copyright c�


References

[AAA � 95] G. Alonso,D. Agrawal, A. El Abbadi,C. Mohan,R. Gunthor, andM. Ka-math. EXOTICA/FMQM: A persistentmessage-basedarchitecturefor dis-tributed workflow management. In Proc. IFIP WG8.1 Working Confer-enceon InformationSystemsDevelopmentfor DecentralizedOrganizations,Trondheim,Norway, August1995.

[Ack94] PhilippAckermann.Designandimplementationof onobject-orientedmediacompositionframework. In Proc.InternationalComputerMusicConference,Aarhus,September1994.

[AEW96] PhilippAckermann,Dominik Eichelberg,andBernhardWagner. Visualpro-grammingin anobject-orientedframework. In Proc.SwissComputerScienceConference, Zurich,Switzerland,October1996.

[AMS] MicrosoftCorporation,Seattle,WA. ActiveMovieSoftwareDevelopmentKitversion1.0. http://www.microsoft. com/de von ly/ tec h/a mov1doc/ .

[AVS93] CONVEX ComputerCorporation,Richardson,TX. ConvexAVSDeveloper’sGuide, first edition,December1993.

[BMR � 96] Frank Buschman,Regine Meunier, HansRohnert,PeterSommerlad,andMichaelStal.Pattern-OrientedSoftwareArchitecture—ASystemof Patterns.JohnWiley & Sons,July1996.ISBN 0-47195-869-7.

[CRJ87] Roy H. Campbell,VincentRusso,andGaryJohnston.Choices:TheDesignof a MultiprocessorOperatingSystem. In Proc. USENIXC++ Workshop,pages109–123,SantaFe,NM, November1987.

[Den80] J.B. Dennis.Dataflow supercomputers.IEEEComputer, 13(11),1980.

[Edw95] StephenEdwards. Streams: A Pattern for “Pull-Driven” Processing, vol-ume1 of “Pattern Languagesof Program Design”, chapter21. Addison-Wesley, 1995.Editedby JamesO.CoplienandDouglasC.Schmidt.ISBN 0-201-60734-4.

[Eng] Accel Software Engineering. Messagetranslationand validation builder.http://www.accelse.c om/ .

[EXP93] Silicon Graphics,Inc., MountainView, CA. IRIS Explorer User’s Guide,1993.

[Foo88] BrianFoote.Designingto facilitatechangewith object-orientedframeworks.Master’s thesis,Universityof Illinois atUrbana-Champaign,1988.

[Fow97] Martin Fowler. AnalysisPatterns—ReusableObject Models. Addison-Wesley Object-OrientedSoftware Engineering Series. Addison-Wesley,1997.ISBN 0-201-89542-0.

[GHJV95] Erich Gamma,RichardHelm, RalphJohnson,andJohnVlissides. DesignPatterns—Elementsof ReusableObject-OrientedSoftware. Addison-Wesley,1995.ISBN 0-201-63361-2.

Copyright c�


[Gur85] J.R. Gurd. TheManchesterprototypedataflow computer. Communicationsof theACM, 28(1),January1985.

[JBR96] MacDonaldH. Jackson,J. Eric Baldeschwieler, and LawrenceA. Rowe.Berkeley ContinuousMediaToolkit API. Submittedfor publication,Septem-ber1996.

[Kay93] Alan C. Kay. The early history of Smalltalk. ACM SIGPLANnotices,28(3):69–92,March1993.

[Lea94] Doug Lea. Designpatternsfor avionics control systems,November1994.DSSAAdageProjectADAGE-OSW-94-01.

[Lea96] Doug Lea. Concurrent Programmingin Java. The Java Series.Addison-Wesley, 1996.ISBN 0-201-69581-2.

[Lin94] ChristopherJ.Lindblad. A programmingsystemfor thedynamicmanipula-tion of temporallysensitive data. TechnicalReport637,MassachutesInsti-tuteof Technology, August1994.Laboratoryfor ComputerScience.

[Meu95] RegineMeunier. ThePipesandFilters Architecture, volume1 of “PatternLanguagesof ProgramDesign”, chapter22. Addison-Wesley, 1995.Editedby JamesO. CoplienandDouglasC. Schmidt.ISBN 0-201-60734-4.

[MN98] Dragos-Anton Manolescuand Klara Nahrstedt. A scalableapproachtocontinuous-mediaprocessing. In The 8th International Workshopon Re-search Issuesin Data Engineering:Continuous-MediaDatabasesand Ap-plications, Orlando,FL, February1998.

[Moh97] C. Mohan. Recenttrendsin workflow managementproducts,standardsandresearch.In Proc. NATO AdvancedStudyInstitute(ASI) on WorkflowManagementSystemsand Interoperability, Istanbul, Turkey, August1997.Springer-Verlag.

[MS96] David MusserandAtul Saini. STLTutorial andReferenceGuide. Addison-Wesley, 1996.ISBN 0-201-63398-1.

[NPA92] R. S. Nikhil, Gregory M. Papadopoulos,andArvind. *T: A multithreadedmassively parallelarchitecture.In Proc. 19thAnnualInternationalSympo-siumonComputerArchitecture, pages156–167.ACM, 1992.

[Pap91] Gregory M. Papadopoulos.Implementationof a general-purposedataflowmultiprocessor. MIT Press,1991.

[PLV96] EdwardJ.Posnak,R.Greg Lavender, andHarrickM. Vin. Adaptivepipeline:an object structuralpatternfor adaptive applications. In The 3rd PatternLanguagesof Programmingconference, Monticello,IL, September1996.

[PLV97] Edward J. Posnak,R. Greg Lavender, and Harrick M. Vin. An adaptiveframework for developingmultimediasoftwarecomponents.Communica-tionsof theACM, 40(10),October1997.

Copyright c�


[Rit84] DennisM. Ritchie. A streaminput-outputsystem.AT&T Bell LaboratoriesTechnicalJournal, 63(8):1897–1910, October1984.

[RW94] ChrisRuemmlerandJohnWilkes. An introductionto disk drive modeling.IEEEComputer, 27(3):17–29,March1994.

[SC95] AamodSaneandRoy Campbell.CompositeMessages:A StructuralPatternfor CommunicationBetweenProcesses.In Proc. OOPSLAWorkshoponDesignPatternsfor Concurrent, Parallel and Distributed Object-OrientedSystems, October1995.

[Sha96] Mary Shaw. SomePatternsfor Software Architecture, volume2 of “PatternLanguagesof ProgramDesign”, chapter16. Addison-Wesley, 1996.Editedby JohnM. Vlissides,JamesO. CoplienandNormanL. Kerth.ISBN 0-201-89527-7.

[SOHL� 96] Marc Snir, Steve W. Otto, Steven Huss-Lederman,David W. Walker, andJack Dongarra. MPI—TheCompleteReference. The MIT Press,1996.ISBN 0-262-69184-1.

[SPG91] AbrahamSilberschatz,JamesL. Peterson,andPeterB. Galvin. OperatingSystemConcepts. Addison-Wesley, third edition,1991. ISBN 0-201-51379-X.

[SUN97] SUN Microsystems, Inc. Java media players.http://java.sun.com/ pro duc ts/ jav a-medi a/j mf, November1997.

[TW97] Andrew S.TanenbaumandAlbert S.Woodhul. OperatingSystems—Designand Implementation. Prentice-Hall,secondedition, 1997. ISBN 0-13-638677-6.

[Wal94] William F. Walker. A Conversation-BasedFrameworkFor MusicalImprovi-sation. PhDthesis,Universityof Illinois atUrbana-Champaign,1994.

[X2088a] CCITT RecommendationX.208: Specificationof AbstractSyntaxNotationOne(ASN.1),1988.

[X2088b] CCITT RecommendationX.209: Specificationof BasicEncodingRulesforAbstractSyntaxNotationOne(ASN.1),1988.

1 pattern: data ﬂo w architecture · c 1998dragosa.manolescu 3 scalability in several dimensions...

Documents