WhyistheWebLooselyCoupled?AMulti-FacetedMetricforServiceDesignCesarePa - PDF document

WhyistheWebLooselyCoupled?AMulti-FacetedMetricforServiceDesignCesarePautassoFacultyofInformaticsUniversityofLugano6900Lugano,Switzerlandcesare.pautasso@unisi.chErikWildeSchoolofInformationUCBerkeleydret@berkeley.eduABSTRACTLoosecouplingisoftenquotedasadesirablepropertyofsystemsarchitectures.OneofthemaingoalsofbuildingsystemsusingWebtechnologiesistoachieveloosecoupling.However,giventhelackofawidelyacceptedde“nitionofthisterm,itbecomeshardtousecouplingasacriterionto Thispaperisorganizedasfollows.We“rstintroducesomerelatedwork(Section2)anddiscusstheoriginsoftheterm(Section3)tomotivatetheneedforabetterde“nitionofloosecoupling.Section4enumeratestwelvefacetsofcou-plinggivingconcreteexamplesonhowtheyaectWebtech-nologies.Section5evaluatesourmulti-facetedde“nitiontomeasurethecouplingofconcretetechnologyexamples.Sec-tion6concludesthepaper.2.RELATEDWORKMostauthorsrecognizethatthenotionofdesigningser-vicestobelooselycoupledisthemostimportant,themostfarreaching,andtheleastunderstoodservicecharacteris-ticŽ[27,p.75].LooseCouplinghasbeennamedthesecretsauceofservice-orientationŽ[3,Chapter5].Also,theneedforloosecouplingŽissomewhatself-evidentandthenotionofloosecouplingisafundamentalunderpinningofSOAŽ[41,p.10].Howeverwhenitcomestode“ningpreciselywhatcharacteristicsofcouplingarethemostsigni“cantforthedesignofservice-orientedsystems,onlyalimitedconsensusemergesfromtheliterature.Zimmermannetal.[47,p.157]useloosecouplingim-plicitlyasasynonymof”exibilitybymeansofinformationhiding:aclientapplicationisnottightlycoupledwithaserver,butcodedagainstanabstractservicedescriptionŽ.Thisde“nitionresonateswiththefollowing:thephraselooselycoupleddescribesenter-priseservicescharacteristicofinteractinginwell-de“nedwayswithoutneedingtoknoweachothersinnerworkings.Thismeansthattheservicesfunctionalitycanchangewithoutaectingtheservicesthatuseit,aslongasthebehaviorde-scribedinitsinterfaceremainsthesame…thatis,aslongasitcontinuesprovidingthefunctionalityitprovides.Ž[44,p.111]Deliveringloosecouplingbymeansofcontractedinter-facesisalsorecommendedbyBloombergandSchmelzer[3,p.90].ThisviewisrelatedtotheforgivingnatureoftheWebŽ,whichenablesbrowserstoworktogetherwithWebserversdevelopedbydierentvendors.Asimilardef-initionofinterfacecouplingisprovidedbyNewcomerandLomow[27].Thesameauthorsalsomentiontheimportanceofreusingserviceinterfaces(sotheyarenotcoupledtoasin-glebusinessprocess)aswellasthedangerofcouplingclientsandservicestoaspeci“cplatform(i.e.,toavoidvendorlock-in).PlatformcouplingisalsomentionedbyWeerawaranaetal.[41].However,theauthorsstressthatamessage-basedapproachfostersloosecouplingŽandWebservicetechnologyisbuiltontheconceptof[asynchronous]mes-sagingŽ.Hence,Webservicetechnologyislooselycoupled,asopposedtodistributedobjectmiddlewareplatformsbasedonsynchronousinteractions.ThetightlycouplednatureofRPC-styleWebservicesisdiscussedbyHohpe[18],wheremessage-orientedmiddlewareispresentedasthelooselycou-pledsolutiontoenterpriseapplicationintegrationproblems.Kaye[20,Chapter10]discussestheimplicationsoftightvs.loosecouplingonthefollowingaspects:interaction,mes-sagingstyle,messagepaths,technologymix,datatypes,syntacticde“nition,bindings,semanticadaptation,softwareobjective,andconsequences.Krafzigetal.[23,Chapter3]alsotakeamulti-levelapproachtodescribecouplingindis-tributedsystems.Theseare:physicallevel(whetherservicesaredirectlyorindirectlyconnected),platform(i.e.,OSandprogramminglanguage)dependencyorindependency,com-municationsstyle(synchronousvs.asynchronous),typesys-tem(stronglytypedinterfacesvs.weaklytypedpayloads),interactionpatterns(chattydistributedobjectsvs.messagebus),processcontrol(centralizedvs.distributed),anddis-covery(staticbindingvs.dynamicbinding).Whereastheclassi“cationsdevelopedbyKayeandKrafzigarerelatedtothemulti-facetedde“nitionwearegoingtopresentinthispaper,wehaverevisitedtheirclassi“cationsinthecontextoftheSOAPvs.RESTdebate,entirelyfo-cusingonservicedesignissues(i.e.,thetechnicalquestionsregardingloosevs.tightcoupling),whiletheotherclassi“-cationsalsoincludeconsiderationsthataremorerelatedtotheimplementation,deployment,andmanagementaspectsofservices.3.ORIGINSIncomputerscience,thenotionofcouplingpredatestheemergenceofservice-orientedcomputing.Someearlyus-ageexamplescanbefoundindistributedsystemsandsoft-wareengineeringdesignprinciples.Indistributedsystems,looselycoupledarchitecturesaredistinguishedfromcloselycoupledŽ[36]onesbasedonwhethertwoprocessesmaycom-municatethroughsomeformofsharedmemory(close)ormayonlyrelyonmessagepassing(loose).Inpractice,loosecouplingintermsofspace,andsynchronizationbeenassociatedthepropertiesofdistributedsystemsde-signedaccordingtothepublish/subscribeparadigm[10].Insoftwareengineering,thebasicdesignprincipleofmodular-ityimpliesthedecompositionofasoftwarearchitectureintomodulescharacterizedbyhighcohesionlowcouplingoupling45,26].Thus,couplingmeasurestheinterdependenciesoftwomodulesŽ[15,5]anditcanbeunderstoodthatalowdegreeofcouplingisbene“cialtoaidtheunderstandingandsupporttheevolutionofasystem[25].EventhoughthetermloosecouplingŽisoftenassoci-atedwithsoftwarearchitectures(andwasintroducedintocomputerscienceasearlyas1974[35]),itsoriginscanbetracedbackevenearlier,leadingtoresearchonorganiza-tionalstructuresasearlyas1967[37]:Theconcept[ofloosecoupling]hasararecombinationoffacevalidity,metaphoricalsalience,andcutting-edgemysticism,allofwhichencour-ageresearcherstoadopttheconceptbutdonothelpthemtoexamineitsunderlyingstructure,themes,andimplications.[...]Becausetheconcepthasbeenunderspeci“ed,itsusehasgen-eratedcontroversy.Researcherswhoopposetheconceptonthebasisofitsimprecisionhavewatchedasmoreandmoreresearchersadoptit.Researcherswhoadvocatetheconceptonthebasisofitsfacevalidityhavewatcheditbecomeunrecognizable.Researcherswhoareinthemiddlehaveoftenusedtheconcepthesitantly,convincedthatit“tsthephenomenatheystudy,butuncertainaboutitsmeaning.Ž[29]Byapplyingthisquotefromorganizationresearchtothecontextofservice-orientedsystems,itiseasytorealizehowmarketingbuzzwordssweepthroughtheITindustryandgainacceptancethankstothepositiveimpressiontheyde-liverandthankstotheirimprecisede“nition,andthustheir FacetTightCouplingLooseCoupling 4.1DiscoveryRegistrationReferral4.2Identi“cationContext-basedGlobal4.3BindingEarlyLate4.4PlatformDependentIndependent4.5InteractionSynchronousAsynchronous4.6InterfaceOrientationHorizontalVertical4.7ModelSharedModelSelf-DescribingMessages4.8GranularityFineCoarse4.9StateShared,StatefulStateless4.10EvolutionBreakingCompatible4.11GeneratedCodeStaticNone/Dynamic4.12ConversationExplicitRe”ective Table1:CouplingFacetsSummarybetweenservicesthatcanbeexploitedforthepurposesofdiscovery.ItisworthnotingthattheglobalUDDIbusinessregistrieswerediscontinuedinJanuary2006.After5yearsofoperationtheyhadaccumulatedlessthan50000serviceregistrations(asmallnumberwhencomparedtothesizeoftheWeb),showingthatthetightlycoupledŽassumptionofexpectingallserviceproviderstomanuallyregisterthem-selveswasnotpractical.However,UDDIcontinuestothrivewithintheboundariesofthecorporate“rewall,showingthatatightlycoupledsolutioncanworkinalocalenvironment.Discoveryalsorequiresacommonmodel(seeSection4.7),becausediscoveryimpliesthatservices(andregistries)sharesomemodelofwhattodiscover,andhowtodiscoverit.Forexample,keywordsearch(i.e.,indexedphrases)isthelargestcommondenominatorontheWeb:itisafreetextmodel.Italsoisaweakmodelbecauseitdoesnotensurethatre-sultsactuallymatchagivenAPI,asshown,forexample,bytheworkontheWooglefree-textsearchengineforWebservices[8].4.2Identi“cationIdenti“cation(oftenalsoreferredtoasnaming)isoneofthemostimportantdesignconsiderationsinordertoconnectsystemswiththerealworld,andsystemswithsystems.Sys-temsusuallyperformtasksappliedtoobjectsfoundoutsideofthesystemsthemselves.Identi“cationisaboutmakingtheassociationbetweentherepresentationswithinthesys-tems,andtheseexternalentities(andofcoursealsofortheentitiesonlyexistingwithinsystems).Thechallengesre-latedtoidenti“cationincludedesigningnamespaces,assign-ingidentities,andprovidingidentity-relatedservices,suchasdiscoverylookups,bindings,orcomparisons[21].Tightlycoupledapproachestoidenti“cationmostlyrelyoncentralizedservices,wherethereisasingleentityassign-ingandmanagingidentities.Inthatcase,identityismostlytiedtothecontextwithinwhichservicesarecooperatingwiththatcentralentity.Assoonasidenti“ersaremovedoutsideofthatcontext,serviceslosetheabilitytomeaning-fullyhandletheseidenti“ers;theybecomeopaquewithnoclearlyde“nedruleshowtointerpretandresolvethem.Ide-ally,identi“ersintightlycoupledscenariosalwaysshouldbeaugmentedwithadditionalcontextinformationwhentheyleavetheoriginalcontext.Inpractice,however,thisrarelyhappensandtheproblemofresolvingidenti“ersduetoalossofcontextisafrequentlyoccurringproblem[38].Loosecouplingisbasedonanidentityconceptwhichdoesnotcoupleidenti“cationtocontext.InthecontextofREST,identi“cationisdoneusingaUniformResourceIdenti“er[1].URIscanusevariousidenti“cationwiththemostfrequentlyusedoneontheWebbeingthescheme.Servicesarefreetousewhateveridenti“cationschemetheylike,theimportantaspectbeingthatagreeingonURIsasthecommonwayofidenti“cationmakesiteas-iertousegloballyuniqueidenti“erswithoutrelyingonacentralizedauthority.Ifapplicationsinsistonusingopaquelocalidenti“ers,thesecanbefoldedintoURIsusingthescheme[22].However,thiswouldre-createtheproblemoftheseURIsneedingapropercontextforinterpretationthatistypicalfortightlycoupledidenti“cation.4.3BindingCloselyrelatedtodiscoveryandidenti“cation,bindingreferstotheprocessofresolvingsymbolicnamesintoiden-ti“ersusedatalowerabstractionlevel.Forexample,aDNSnamecanbeboundtooneofthecorrespondingIPaddressesusingaDNSlookup(aformofdiscovery).Inservice-orientedsystems,bindingcanbeappliedindierentways[30].Abstractserviceinterfacesreferredtobyclientsneedtobeboundtoaconcretenetworkendpointandtrans-portprotocolusedbytheserviceprovider.Likewise,thepartnerlinksofaBPELprocessneedtobeboundtocom-patibleWSDLporttypes.Atightlycoupledbindingisonethatishardtochange,e.g.,whenitisresolvedearly,alongtimebeforethere-sultofthelookupisactuallyneeded.Thus,compile-timeordeployment-timebindingareconsideredtoestablishatightcouplingbetweentheboundentities,asitwillnotbepossi-bletochangethebindingduringtherestofthelifecycleofthesystem.Dynamicbindinginsteadhappensatrun-time,andpartic-ularlyatthelatestpossibletime(e.g.,rightbeforeaserviceinvocation).Thisisaformofloosecoupling,becausethebindingisestablishedonlywhenitbecomesnecessary.Per-formingalookupbeforeeveryserviceinvocation,however,canimposeasigni“cantoverheadandestablishesatightcouplingbetweentheclientsandtheresolver.Notonlytheresolverbecomesascalabilitybottleneck,butiftheresolverwouldbecomeunavailable,allclientlookupswillfailandclientswillbeunabletoperformanyserviceinvocation.4.4PlatformPlatformcouplingconcernstherequirementsforallser-vicestobebasedonahomogeneousmiddlewareinfrastruc-ture.Iftwoservicesneedtocommunicate,theymustbe straction(thehorizontalinterfacebetweentheprotocolim-plementationandtheserviceuser)isdesigned(Figure2.2showsthebasicmodel,Figure2.3showsaninternalsepa-rationoftheclient-sidecode).Horizontalinterfacesoftenleadtohomogenousenvironments,whereallintegratedser-vicesdependonthesamemiddlewareAPIs(whichhidetheproprietaryprotocols).AtypicalexampleforaprotocolisTCP,whichimplementsinter-processcommunicationsontheInternet,andistheprotocolmostoftenusedthroughthesocketAPImentionedearlier.TocommunicatewithapeerovertheInternet,onlyTCPisrequired;socketsareapopularchoiceforusingTCP,butareanentirelylocalissue.4.7ModelThisfacetisaboutwhetherthedesignassumesthatthereisacommonapplication-leveldatamodelthatissharedamongserviceswithinaproblemdomain.Ifthisisthecase,thenmessagesaresimplytreatedasaserializationofthatmodel,whichisonlyusedtotransferamodelinstancefromoneservicetotheotherthroughsomecommunicationsmedium.Thisapproachoftenusesgeneratedcodeformar-shalingandunmarshaling,becausethemodelinstanceinessenceisthesharedinformation,andallservicesusethesamemethodformappingmodelstothewireformat.Thissharedmodeldesignintroducestightcoupling,be-causethereisastrongconceptualconnectionbetweenallservicessharingthesamedatamodel.Thiscouplingoftenisnotonlytightinprinciple,italsoistightinpractice,be-causeservicesarebuiltwithaparticularmethodortoolformarshalingandunmarshaling.Serviceswishingtouseadif-ferentmethodortoolhaveahardtimedoingso,becausetherepresentationonthewirehasnotbeendesignedforin-teroperabilityandreuseindierentcontexts,butinsteadisjustaserializationofthesharedmodel.Loosecouplingdoesnotassumethatthereisasharedmodel,insteadmessagesbeingexchangedareself-containedandaredesignedtobeprocessedasdocumentsinastan-dardizedrepresentationformat.Thusmessagescanbepro-cessedwithanytoolsetforthatformat[43].Looselycoupledservicescanuseadierentinternalmodel(adaptedtotheirlocalrequirements)aslongastheysolvetheproblemofmap-pingthestandarddocumentformattotheirinternalmodels.Whilethisadditionalstepofmappingdocumentstructurestoaninternalmodelmightberegardedasoverheadthatisnotrequiredinthetightlycoupledscenario,itisessentialforloosecoupling,becauseitallowscooperationbetweenservicesaslongasthereisasucientsharedunderstandingtode“neamappingbetweentheexternalcanonicalmessageformatandtheinternalmodelsofeachservice.4.8GranularityGranularityofservicesinterfacesisaboutthedesigntrade-obetweenthenumberofinteractionsthatarerequiredtoprovidecertainfunctionalitytoservicealargeclientcom-munity,andthecomplexityofthedataparameters(orop-erationsignatures)tobeexchangedwithineachinteraction.InAPIdesign,atypicalgoalistominimizethenumberofinteractions[17].Inservicedesign,thisisevenmoreso,duetothehighlatencyinvolvedinaserviceinvocation.Byusingmorecoarse-grainedinterfaces(i.e.,fewerinter-actionsrequired),servicescanexploittheextensibilityofwell-designedmessageformats,andserviceevolution(Sec-tion4.10)canbebasedonmessageextensibility,ratherthananextensionofthesetofpossibleserviceinteractions.Fine-granularinterfacesaretightlycoupledbecausechangesinaserviceintroduceorremoveoperations.Themainad-vantageof“ne-granularinterfacesusuallyiseciency,be-causeitispossibletopickspeci“cinteractionshavingtheexactsignaturerequiredbyasubsetoftheclients,forwhichtheoverheadofexchangingunnecessarydatacanbere-4.9StateDependingonthescaleofaservicelandscape,stateman-agementcanbecomeoneofthecentralproblemsinecientservicedesign.Statefulservicesarebasedontheassumptionthataservicekeepsstateofanongoinginteraction,leadingtoproblemsforserviceswithmanyclients,highthroughput,andlong-runningtransactions.Thealternativeistochooseastatelessservicedesign,whichkeepsstateinthemessagesthatarepassedbackandforthbetweencooperatingservices.Loosecouplingforstatemanagementmeansstatelessser-vices.Asanexample,theacronymRESTitselfstandsforRepresentationalStateTransferandhighlightsthatstate-lessinteractionsareoneofthekeypropertiesoftheWeb.Mechanismsforsessionmanagement(e.g.,cookies[24]orURIrewriting)areneverthelessalsoavailable.However,sharedstate(i.e.,statethatiskeptbytwoormoreinter-actingservices)alwaysimpliestightcoupling,becausetheremustbeassociatedmechanismsofestablishingandrecov-eringstatefulsessions,comparingstates,resolvinginconsis-tencies,implementingtime-outmechanisms,andperformingdistributedgarbagecollection.Themanagementoverheadofsharedstateissubstantial,soitshouldonlybeemployedwhenrequired,i.e.,toreducethesizeofmessagepayloads.4.10EvolutionThisfacetconcernshowservicescanevolveovertime,andhowthataectstheirclients.Fromthepointofviewoftheserviceprovider,compatibilityamongversionscanbeseenintwodirections:Backwardcompatibilityallowsolderclientstokeepfunctioningwhenusingaservicethathasbeenupgradedtoanewversion.Forwardcompatibilitylowsnewerclientstouseanoldversionofaservice,eventhoughtheyhavebeendevelopedagainstanewerversionoftheservice.Evolutionbecomesparticularlyimportantinconnectionwiththediscoveryfacet,becausethecompati-bilityofclientsandservicesshouldbetakenintoaccountduringthelookup.Also,incaseoflatebinding,run-timeerrorsmaybeproducedifclientsareboundtoevolved(andpotentiallyincompatible)services.Tightcouplingforthisfacetisimpliedbyanexactmatchofversions,sothatneitherforwardorbackwardcompatibil-ityaresupported.Alooselycoupleddesigninsteadattemptstoprovideasmuchforwardandbackwardcompatibilityaspossible,eveniftherearelimitstohowmanychangesanin-terfacecanwithstandwithoutbreakingclients.Loosecou-plingthereforeneedstocombinerulesabouthowtohandledieringversionnumbers,andwhatrulestoapplyintheeventofdieringversionnumbers. Interestingly,oneofthecorespeci“cationsoftheWeb,XMLitself,atthetimeofwritingisundergoingacontrover-sialupdate.Theproposed5theditionofXML1.0[4]wouldnotchangetheversionnumberofXML,butintroducenewfeatures.Thisway,theloosecouplingofXML-basedserviceswouldbecompromised,becausesomedocumentsconform-ingtothe5theditioncouldnotbeprocessedusingolderXMLprocessors.Itisstillunclearwhethertheproposed WS-*/ESB RPCoverHTTP RESTfulHTTP DegreeofCoupling LooseCouplingCouplingFacet TightCoupling Design-SpecificCoupling IdentificationBindingPlatformInteractionInterfaceOrientationInterfaceOrientationInterfaceOrientationModelGranularityStateEvolutionGeneratedCodeGeneratedCodeGeneratedCodeConversation IdentificationBindingPlatformInteractionModelGranularityStateEvolutionConversation DiscoveryIdentificationBindingPlatformInteractionModelGranularityStateEvolutionConversation (a)RESTfulHTTP(b)RPCoverHTTP(c)WS-*/ESBFigure3:MeasuringthedegreeofcouplingimpliedbydierentWebservicestechnologies RESTfulHTTPRPCoverHTTPWS-*/ESB 4.1DiscoveryReferralReferralRegistration4.2Identi“cationGlobalGlobalContext-based4.3BindingLateEarly/LateLate4.4PlatformIndependentIndependentIndependent4.5InteractionAsynchronousSynchronousAsynchronous4.6InterfaceOrientationVerticalHorizontalHorizontal4.7ModelSelf-DescribingMessagesSharedModelSelf-D.Messages/SharedModel4.8GranularityFine/CoarseFine/CoarseFine/Coarse4.9StateStatelessStateless/Shared,StatefulStateless4.10EvolutionCompatible/BreakingCompatible/BreakingCompatible/Breaking4.11GeneratedCodeNone/DynamicStaticStatic4.12ConversationRe”ectiveExplicitExplicit Table2:WebServicesTechnologyEvaluationSummaryprotocol.However,whenitcomestotheinteractionfacet,somedierencesbecomeapparent.RPCinteractionsarebyde“nitionsynchronous.RESTfulinteractionsareinsteadasynchronous,sinceservicesinteractindirectlybyupdating,or)thestateofresources,whichcanbelateraccessedbyotherservices(with)[33].Inter-faceorientationisverticalinREST,whichonlyreliesontheprotocolandresourcerepresentations,whereasRPCisoftenbasedonthestubmechanismwheretheclientofaremoteserviceaccessedviaRPCcallsalocalinterfacewhichthenhandlesthefactthattheserviceisimplementedremotely.Thetwotechnologiesalsodierintermsofthemodelfacet,whereRPCfollowsasharedmodelapproach,whereallser-vicesmustagreebeforehandonthesyntaxandthesemanticsoftheexchangedmessages,whileRESTpromotesaSelf-DescribingRepresentationsŽsolution.RESTfulinteractionsarealsostateless,whileRPCoersbothoptions,asinteract-ingservicesmayestablishasessionbysharingstateamongthem,butalsomaybedesignedtoavoidsuchtightcou-pling.RPCisalsobasedongeneratedcodestubs,whileRESTdoesnotrequirethemasitfollowsamoredynamicapproachbasedonpluginextensibility.Alsoregardingcon-versations,RESTpromotesadynamic,re”ectiveapproach,whileRPC-basedWebservicesmaketheinteractioncon-straintsexplicitatdesign-time.Itisworthnotingthatnotallthefacetsareboundbythepropertiesofagiventechnology.Forexample,thegran-ularity,state,andevolutionfacetsdependontheconcretedesignchoiceofagivenservice-orientedsystemarchitecture,andarenotconstrainedbythechoiceoftheRESTvs.RPCstyles.Inotherwords,itispossibletodesigntightlycou-pledRESTfulWebservices,whichcanbechattyŽintheirinteractions,iftheirinterfacesexposealargenumberof“ne-grainedresources.ThesamecanbesaidaboutRPC-basedservices,whichcaneitherpublishmany“ne-grainedopera-tions,orafewcoarse-grainedones,dependingonthecho-sendesignstrategy.Alsointermsoftheevolutionfacet,aservicedesignneedstobeevaluatedatamorespeci“clevel.Forexample,XMLtechnologycansupportalooselycoupledevolutionfacetonlyifitisusedwithadditionalguidelinesforversioningandtheenforcementofWehavechosentoincludeinourevaluationtheWS-*/ESBtechnology(whichisnotWeb/HTTPcentric),becausetheenterpriseservicebusfamilyofmiddlewareproductsiswidelyperceivedtobethefoundationforlooselycoupledSOAim-plementations.Thus,itisinterestingtoapplyourmulti- AndrewBirrellBruceJayNelson.ImplementingRemoteProcedureCalls.ACMTransactionsonComputerSystems(TOCS),2:39…59,February1984.1984.JasonBloombergRonaldSchmelzer,editors.ServiceOrientorBeDoomed!JohnWiley&Sons,NewYork,NY,March2006.2006.TimBrayJeanPaoliC.MichaelSperberg-McQueenEveMaler,andFran¸coisYergeau.ExtensibleMarkupLanguage(XML)1.0(FifthEdition).WorldWideWebConsortium,RecommendationREC-xml-20081126,November2008.2008.LionelC.BriandJohnW.Daly,andurgenK.WAUni“edFrameworkforCouplingMeasurementinObject-OrientedSystems.IEEETransactionsonSoftwareEngineering,25(1):91…121,January1999.1999.DavidChappellEnterpriseServiceBus.OReilly,2004.2004.LucClementAndrewHatelyClausvonRiegen,andTonyRogers.UDDIVersion3.0.2.OrganizationfortheAdvancementofStructuredInformationStandards,UDDISpecTechnicalCommitteeDraft,October2004.2004.XinDongAlonY.HalevyJayantMadhavan,andJunZhang.SimilaritySearchforWebServices.InProceedingsofthe30thInternationalConferenceonVeryLargeDataBases,pages372…383,Toronto,Canada,September2004.004.ThomasErlService-OrientedArchitecture:Concepts,Technology,andDesign.PrenticeHall,2005.2005.PatrickTh.EugsterPascalA.FelberRachidGuerraoui,andAnne-MarieKermarrec.Themanyfacesofpublish/subscribe.ACMComputingSurveys35(2):114…131,2003.2003.GunarFiedlerThomasRaak,and.DatabaseCollaborationInsteadofIntegration.SvenHartmannMarkusStumptner,editors,Proceedingsofthe2ndAsia-Paci“cConferenceonConceptualModelling,pages49…58,Newcastle,Australia,January2005.2005.RoyThomasFieldingArchitecturalStylesandtheDesignofNetwork-basedSoftwareArchitectures.PhDthesis,UniversityofCalifornia,Irvine,Irvine,California,2000.000.RoyThomasFieldingJimGettysJeffreyC.MogulHenrikFrystykNielsenLarryMasinterPaulJ.Leach,andTimBerners-Lee.HypertextTransferProtocol„HTTP/1.1.InternetRFC2616,June1999.999.RoyThomasFieldingRichardN.TaylorPrincipledDesignoftheModernWebArchitecture.ACMTransactionsonInternetTechnology,2(2):115…150,MayyCarloGhezziMehdiJazayeri,andDinoMandrioliFundamentalsofSoftwareEngineering.PrenticeHall,2003.2003.JoeGregorio.URITemplate.InternetDraftdraft-gregorio-uritemplate-03,March2008.2008.MichiHenning.APIDesignMatters.ACMQueue5(4):24…36,May2007.2007.GregorHohpeEnterpriseIntegrationPatternsAddison-Wesley,October2003.2003.NicolaiM.JosuttisSOAInPractice.OReilly,AugustugustDougKayeLooselyCoupled:TheMissingPiecesofWebServices.RDSPress,August2003.2003.TimKindberg.Ubiquitousandcontextualidenti“erresolutionforthereal-worldwideweb.TechnicalReport95,HPLabs,2001.001.TimKindbergSandroHawke.ThetagURIScheme.InternetRFC4151,October2005.005.DirkKrafzigKarlBanke,andDirkSlamaSOA:Service-OrientedArchitectureBestPractices(TheCoadSeries).PrenticeHall,2004.2004.DavidM.KristolLouMontulli.HTTPStateManagementMechanism.InternetRFC2965,OctobererMicheleLanzaRaduMarinescuObject-OrientedMetricsinPractice.Springer,2006.2006.G.J.MyersComposite/StructuredDesign.VanNostrandReinhold,1978.1978.EricNewcomerGregLomowUnderstandingSOAwithWebservices.Addison-Wesley,2005.005.JohannOberleitnerThomasGschwind,andJazayeri.TheViennaComponentFrameworkenablingcompositionacrosscomponentmodels.InICSE03:Proc.ofthe25thInternationalConferenceonSoftwareEngineering,pages25…35,2003.2003.J.DouglasOrtonKarlE.Weick.LooselyCoupledSystems:AReconceptualization.AcademyofManagementReview,15(2):203…223,April1990.1990.CesarePautassoGustavoAlonso.FlexibleBindingforReusableCompositionofWebServices.InProc.ofthe4thWorkshoponSoftwareComposition(SC2005)Edinburgh,Scotland,April2005.2005.CesarePautassoOlafZimmermann,and.RESTfulWebServicesvs.ŽBigŽWebServices:MakingtheRightArchitecturalDecision.InProceedingsofthe17thInternationalWorldWideWebConference,pages805…814,Beijing,China,April2008.ACMPress.Press.CynthiaRettig.TheTroublewithEnterpriseSoftware.MITSloanManagementReview,49(1):21…27,2007.2007.LeonardRichardsonSamRubyRESTfulWebServices.OReilly,May2007.2007.JosA.Rijpma.Complexity,Tight-CouplingandReliability:ConnectingNormalAccidentsTheoryandHighReliabilityTheory.JournalofContingenciesandCrisis,5(1),March1997.1997.WayneP.StevensGlenfordJ.Myers,andLarryL.Constantine.StructuredDesign.IBMSystemsJournal13(2):115…139,1974.1974.AndrewS.TanenbaumDistributedOperatingSystemsPrentice-Hall,EnglewoodClis,NewJersey,SeptemberrJamesD.ThompsonOrganizationsinAction:SocialScienceBasesofAdministrativeTheory.McGraw-Hill,NewYork,NY,June1967.1967.ManolisTzagarakisNikosKarousos,andSiegfriedReich.NamingasaFundamentalConceptofOpenHypermediaSystems.InProceedingsofthe11thACMConferenceonHypertextandHypermedia,pages103…112,SanAntonio,Texas,May2000.ACMPress.Press.SteveVinoski.OldMeasuresforNewServices.InternetComputing,9(6):72…74,November2005.005.SteveVinoski.SerendipitousReuse.IEEEInternet,12(1):84…87,January2008.2008.SanjivaWeerawaranaFranciscoCurberaTonyStorey,andDonaldFergusonServicesPlatformArchitecture.PrenticeHall,March2005.005.KarlE.Weick.EducationalOrganizationsasLooselyCoupledSystems.AdministrativeScienceQuarterly21(1):1…19,March1976.1976.ErikWildeRobertJ.Glushko.DocumentDesignCommunicationsoftheACM,51(10):43…49,October2008.2008.DanWoodsThomasMatternEnterpriseSOA:DesigningITforBusinessInnovation.OReilly,2006.2006.E.YourdonL.ConstantineStructuralDesignPrenticeHall,1979.1979.HubertZimmermann.OSIReferenceModel„TheISOModelofArchitectureforOpenSystemsInterconnection.IEEETransactionsonCommunications,28(4):425…432,April1980.1980.OlafZimmermannMarkTomlinson,andStefanPerspectivesonWebServices:ApplyingSOAP,WSDL,andUDDItoReal-WorldProjects.Springer,September2003. Thispaperisorganizedasfollows.We“rstintroducesomerelatedwork(Section2)anddiscusstheoriginsoftheterm(Section3)tomotivatetheneedforabetterde“nitionofloosecoupling.Section4enumeratestwelvefacetsofcou-plinggivingconcreteexamplesonhowtheyaectWebtech-nologies.Section5evaluatesourmulti-facetedde“nitiontomeasurethecouplingofconcretetechnologyexamples.Sec-tion6concludesthepaper.2.RELATEDWORKMostauthorsrecognizethatthenotionofdesigningser-vicestobelooselycoupledisthemostimportant,themostfarreaching,andtheleastunderstoodservicecharacteris-ticŽ[27,p.75].LooseCouplinghasbeennamedthesecretsauceofservice-orientationŽ[3,Chapter5].Also,theneedforloosecouplingŽissomewhatself-evidentandthenotionofloosecouplingisafundamentalunderpinningofSOAŽ[41,p.10].Howeverwhenitcomestode“ningpreciselywhatcharacteristicsofcouplingarethemostsigni“cantforthedesignofservice-orientedsystems,onlyalimitedconsensusemergesfromtheliterature.Zimmermannetal.[47,p.157]useloosecouplingim-plicitlyasasynonymof”exibilitybymeansofinformationhiding:aclientapplicationisnottightlycoupledwithaserver,butcodedagainstanabstractservicedescriptionŽ.Thisde“nitionresonateswiththefollowing:thephraselooselycoupleddescribesenter-priseservicescharacteristicofinteractinginwell-de“nedwayswithoutneedingtoknoweachothersinnerworkings.Thismeansthattheservicesfunctionalitycanchangewithoutaectingtheservicesthatuseit,aslongasthebehaviorde-scribedinitsinterfaceremainsthesame…thatis,aslongasitcontinuesprovidingthefunctionalityitprovides.Ž[44,p.111]Deliveringloosecouplingbymeansofcontractedinter-facesisalsorecommendedbyBloombergandSchmelzer[3,p.90].ThisviewisrelatedtotheforgivingnatureoftheWebŽ,whichenablesbrowserstoworktogetherwithWebserversdevelopedbydierentvendors.Asimilardef-initionofinterfacecouplingisprovidedbyNewcomerandLomow[27].Thesameauthorsalsomentiontheimportanceofreusingserviceinterfaces(sotheyarenotcoupledtoasin-glebusinessprocess)aswellasthedangerofcouplingclientsandservicestoaspeci“cplatform(i.e.,toavoidvendorlock-in).PlatformcouplingisalsomentionedbyWeerawaranaetal.[41].However,theauthorsstressthatamessage-basedapproachfostersloosecouplingŽandWebservicetechnologyisbuiltontheconceptof[asynchronous]mes-sagingŽ.Hence,Webservicetechnologyislooselycoupled,asopposedtodistributedobjectmiddlewareplatformsbasedonsynchronousinteractions.ThetightlycouplednatureofRPC-styleWebservicesisdiscussedbyHohpe[18],wheremessage-orientedmiddlewareispresentedasthelooselycou-pledsolutiontoenterpriseapplicationintegrationproblems.Kaye[20,Chapter10]discussestheimplicationsoftightvs.loosecouplingonthefollowingaspects:interaction,mes-sagingstyle,messagepaths,technologymix,datatypes,syntacticde“nition,bindings,semanticadaptation,softwareobjective,andconsequences.Krafzigetal.[23,Chapter3]alsotakeamulti-levelapproachtodescribecouplingindis-tributedsystems.Theseare:physicallevel(whetherservicesaredirectlyorindirectlyconnected),platform(i.e.,OSandprogramminglanguage)dependencyorindependency,com-municationsstyle(synchronousvs.asynchronous),typesys-tem(stronglytypedinterfacesvs.weaklytypedpayloads),interactionpatterns(chattydistributedobjectsvs.messagebus),processcontrol(centralizedvs.distributed),anddis-covery(staticbindingvs.dynamicbinding).Whereastheclassi“cationsdevelopedbyKayeandKrafzigarerelatedtothemulti-facetedde“nitionwearegoingtopresentinthispaper,wehaverevisitedtheirclassi“cationsinthecontextoftheSOAPvs.RESTdebate,entirelyfo-cusingonservicedesignissues(i.e.,thetechnicalquestionsregardingloosevs.tightcoupling),whiletheotherclassi“-cationsalsoincludeconsiderationsthataremorerelatedtotheimplementation,deployment,andmanagementaspectsofservices.3.ORIGINSIncomputerscience,thenotionofcouplingpredatestheemergenceofservice-orientedcomputing.Someearlyus-ageexamplescanbefoundindistributedsystemsandsoft-wareengineeringdesignprinciples.Indistributedsystems,looselycoupledarchitecturesaredistinguishedfromcloselycoupledŽ[36]onesbasedonwhethertwoprocessesmaycom-municatethroughsomeformofsharedmemory(close)ormayonlyrelyonmessagepassing(loose).Inpractice,loosecouplingintermsofspace,andsynchronizationbeenassociatedthepropertiesofdistributedsystemsde-signedaccordingtothepublish/subscribeparadigm[10].Insoftwareengineering,thebasicdesignprincipleofmodular-ityimpliesthedecompositionofasoftwarearchitectureintomodulescharacterizedbyhighcohesionlowcouplingoupling45,26].Thus,couplingmeasurestheinterdependenciesoftwomodulesŽ[15,5]anditcanbeunderstoodthatalowdegreeofcouplingisbene“cialtoaidtheunderstandingandsupporttheevolutionofasystem[25].EventhoughthetermloosecouplingŽisoftenassoci-atedwithsoftwarearchitectures(andwasintroducedintocomputerscienceasearlyas1974[35]),itsoriginscanbetracedbackevenearlier,leadingtoresearchonorganiza-tionalstructuresasearlyas1967[37]:Theconcept[ofloosecoupling]hasararecombinationoffacevalidity,metaphoricalsalience,andcutting-edgemysticism,allofwhichencour-ageresearcherstoadopttheconceptbutdonothelpthemtoexamineitsunderlyingstructure,themes,andimplications.[...]Becausetheconcepthasbeenunderspeci“ed,itsusehasgen-eratedcontroversy.Researcherswhoopposetheconceptonthebasisofitsimprecisionhavewatchedasmoreandmoreresearchersadoptit.Researcherswhoadvocatetheconceptonthebasisofitsfacevalidityhavewatcheditbecomeunrecognizable.Researcherswhoareinthemiddlehaveoftenusedtheconcepthesitantly,convincedthatit“tsthephenomenatheystudy,butuncertainaboutitsmeaning.Ž[29]Byapplyingthisquotefromorganizationresearchtothecontextofservice-orientedsystems,itiseasytorealizehowmarketingbuzzwordssweepthroughtheITindustryandgainacceptancethankstothepositiveimpressiontheyde-liverandthankstotheirimprecisede“nition,andthustheir abilitytobequotedinmanydierentcontexts.Theprob-lemswhichmaycausetightcouplingorwhichcouldbeavoidedbyimplementingloosecouplingarethesameinor-ganizationsandITsystemarchitectures:thetensionbe-tweentheeciencyandsafetyofaninternallydeterminateandcompletelyrationalstructure,vs.thenecessityto“tintoanopenworldofuncertaintyandcon”ictingconcepts.Introducingtightcouplingincomplexsystemsmayalsoaf-fecttheirreliability,makingaccidentsmorepronetohappen,becauselocalfailuresaremorelikelytopropagate[34].Incaseofloosecoupling,thefollowingquoteisrelevanttoillus-tratehowitcan“twellwiththedesignofservice-orientedA“naladvantageofcouplingimageryisthatitsuggeststheideaofbuildingblocksthatcanbegraftedontoanorganizationorseveredwithrel-ativelylittledisturbancetoeithertheblocksortheorganization.[...]Thus,thecouplingim-agerygivesresearchersaccesstooneofthemorepowerfulwaysoftalkingaboutcomplexitynowavailable.Ž[42]LoosecouplingŽoftenisbeingperceivedasreferringtoanyintermediarystateonalinearscalegoingfromnocou-plingŽtotightcouplingŽ,withloosecouplingŽbeingany-whereinbetweenthesetwoextremes.Thisconceptualiza-tionlooksatcouplingasaone-dimensionalconcept.Or-tenandWeick[29]arguethatthelinearviewofcouplingistooconstrained,andsuggesttofollowatwo-dimensionalapproach.responsivenon-responsive non-distinctivedistinctivenon-coupledtightly coupledloosely coupleddecoupledFigure1:Two-DimensionalViewofCouplinginOr-ganizationalStudiesThetwo-dimensionalde“nitionshowninFigure1hasbeendevelopedwithinthecontextoforganizationalstud-ies.Butevenforthegoalofachievingloosecouplinginthecontextofservice-orientedsystemsdesign,thismodelcanbeusefultounderstandthatamulti-dimensionalapproachtode“netheconceptcanleadtoimprovedunderstanding.IftheITlandscapeforwhichservicesarebeingdesignedhasdistinctivecomponents,thenitisnotrealistictolookattightcouplingastheultimategoal.If,however,fororgani-zational,contractual,political,orlegalreasons,itispossibletoremovedistinctiveness,itispossibletodesignandde-ployatightlycoupledsystem.Inthetwo-dimensionalviewofcoupling,thequestionishowtoachieveresponsiveness(i.e.,theabilityforallbusiness-levelgoalstobeachievedbyhavingservicesinteract)giventhedesigngoalsand/ortheconstraintsoftheenvironment.Evenwiththistwo-dimensionalviewofcoupling,however,itisstillnotcompletelyclearwhatthesetwoorthogonalaxes(responsiveness,distinctiveness)refertointhecontextofservice-orientedsystemsdesign.Nowadaysitis,forexam-ple,well-acceptedthatdistinctivenessintermsofthephys- Withtheexceptionbeingtheintroductionofatechnologylayerwhichintroduceshomogeneity,whichisthetraditionalmiddlewareapproach.icalnetworkinfrastructureismostlyirrelevant„theInter-netprovidesaprotocolstackwhichmakesitunnecessarytodealwithnetworkprotocolissuesthatwereseriousissueswhencomputernetworkswerestilldominatedbyvendor-speci“cprotocolsuites.ThisbegsthequestionwhatkindofpropertiesoneshouldlookforwhenevaluatingagiventechnologyaccordingtothemodelshowninFigure1.ThenextSectionthusintroducesanumberoffacetswhichwehaveidenti“edasbeingimportantpropertiesfordecidinghowagivenservice-orienteddesignshouldbeevaluatedtomeasureitscouplingproperties.4.COUPLINGFACETSThissectionintroducesaframeworkwhichcanserveasatoolforanalyzingthekindofcouplingimpliedbyagiventechnologychoiceduringthedesignofaservice-orientedsystem.Fromthepreviousdiscussion,itisclearthatcou-plingisacomplexconceptthatrequirestoexploreamulti-dimensionalspace.Todoso,welookatvariousfacetstowhichthetermcanbeapplied.Wepreferthetermfacetsovertoemphasizethatnotallfacetsarecom-pletelyindependent.Whileenumeratingthefollowingfacets(summarizedinTable1),wehaveattemptedtoachieveahighdegreeofindependencebetweenthem,butwedonotclaimthattheyarefullyorthogonal.Thefacetscoverallrelevantdesignaspectsthathelptounderstandwhichkindofcouplingcanbefoundinasystem.Ourmethodforidentifyingrelevantfacetsisbasedontheprinciplethatafacetshouldbeincludedifthereisaconcretescenariowherethefacetcanhelptobetterunderstandhowasystemdesignoratechnologymightbeperceivedasbeingtightlyorlooselycoupled.4.1DiscoveryDiscoveryisoneofthefacetswhichcanbeapproachedindierentways.Inclosedenvironments,itispossibletode“neandimplementpoliciesforcompulsoryregistrationofservicedescriptionsandinterfaces,makingitpossibleforclientstodiscoverthem(e.g.,usingUDDIregistries[7]).TheWeb,however,hasnocentralregistrybeyondtheDNS(whichisnotWeb-speci“c,butacorepartoftheInternetprotocolsuite).SomeattemptsweremadetohaveWebsiteregistriesŽ(similartoYahoo!ortheOpenDirectoryProject)butsuchcentralizedregistry-basedapproacheswereoverwhelmedbytheWebsrateofgrowth,andthelackofauniversallyacceptedschemeforclassifyingWebresources.Nowadays,clientsperformdiscoveryontheWebthroughsearchengines.SearchenginesdonotnecessarilyrequiretheregistrationofnewWebpages,astheycanrelyoncrawlersfollowinghyperlinkstodiscoverthem.RESTfulWebservicesareusuallynotdescribedorreg-isteredinanystandardizedorcentralizedway.TheideaisthataRESTfulWebservicecanbediscoveredbydecentral-izedreferral(i.e.,byexchangingahyperlinkpointingtoit)anddoesnotneedadescriptionintermsofitsoperations,andthattherepresentationsthattheserviceacceptsandproducesareexposedthroughHTTP,andaredocumentedasmediatypes.Thus,discoveryforaRESTfulWebservicemeansinteractingwithit,andtheonlypossibleregistryŽmightbesetsofURItemplates[16],describinghowitsre-sourcesareaddressedthroughURIs.InthecaseofSOAPandWS-*,noequivalentlooselycoupledŽmechanismisavailabletodescriberelationships facetedde“nitionalsotomeasurethecouplingimpliedbythistechnology.WeobservethatESBprovidesloosecou-plingaccordingtofourfacets:binding(Dynamic),interac-tion(Asynchronous),state(Stateless)andplatform(Inde-pendent).However,thetechnologyusescontext-basediden-ti“cation(atightlycoupledsolution)andrequirescentral-izedserviceregistrationtosupportservicediscovery.Also,interactionsbasedonmultiplemessageexchangesareexplic-itlymodeledusingwork”owandconversationmodels.ThedevelopmentprocessofservicesconnectedbyanESBreliesoncodegenerationtechniques(thus,anESBpresentsanhorizontalinterfaceorientation).Therefore,accordingtoalloftheseother“vefacets,thiskindofmiddlewaretechnologydoesnothelptoachieveloosecoupling.Similartotheothertwoalternatives,thechoiceofusinganESBdoesnotcon-straintheevolutionandgranularityfacets.Additionally,itisalsopossibletochoosebetweenasharedmodeldesign,ortoleveragetheESBmediationcapabilitiestofosteramorelooselycoupleddesignbasedonself-describingmessages.Inmorequantitativeterms,thetablecountsthenumberoffacetsforwhichatechnologyresultsinlooseortightcou-pling.Wealsodistinguishfacetsforwhichthedegreeofcouplingdoesnotdependonthechosentechnologybutmayvarydependingonmorespeci“cdesigndecisions. RESTRPCWS-*/ESB Loose1034Tight045 Design-Speci“c253 Onlyinthebestcase(assumingthatalldesign-speci“cfacetsfollowlooselycoupledoptions)wecanconcludethatusingRESTfulHTTPwouldprovideasystemarchitecturefeaturingloosecouplingaccordingtoallfacets.ChoosingRPCoverHTTP,instead,wouldnotresultinacompletelylooselycoupledsystem,duetothe4facets(interaction,model,generatedcode,andconversation)whichonlypresentatightlycoupledapproach.Thisalternativealsorequires DiscoveryIdentificationBindingPlatformInteractionModelGranularityStateEvolutionConversationInterfaceOrientationGeneratedCode RPCoverHTTPRESTfulHTTP Figure4:ComparingthedegreeofcouplingimpliedbydierentWebservicestechnologiesmoreeorttoachievealooselycoupledsystem,asupto5facetsaredesign-speci“candareunconstrainedbythetechnologychoice.ThisnumberissmallerincaseoftheWS-*/ESBalternative,whereonly3facetsaredesign-speci“c.Amoredetailed,facet-by-facetcomparisonisvisualizedwiththeradarchartofFigure4.ItisinterestingtonoticethatthecurveindicatingthedegreeofcouplingimpliedbyRESTfulHTTPisstrictlyboundedbybothoftheothercurves.Ifwedonotconsiderthediscoveryandidenti“cationfacets,thesameholdsbetweentheRPCandtheESBcurves.Thus,ourmulti-facetedmetriccanbeusedtoestablishapartialor-deringbetweendierentWebservicestechnologiesintermsoftheirdegreeofcoupling.6.CONCLUSIONSSOAP-basedWebservicesandtheRESTarchitecturalstylehavebeenandstillarethetopicofmanydebates.Manyofthesedebatesareheated,oftenmissingthepointthatthemoreprescriptivestyleoftheSOAPapproachandthemoredescriptivestyleoftheRESTapproachhavetheirrootsindierentscenarios,theformerassumingclosedworldsandcontractualrelationships,whereasthelattercaterstoanopenworldwithad-hocinteractions[40].Sofar,onlyfewattemptshavebeenmadetocomparebothapproachesasobjectivelyaspossible[31].LoosecouplingŽandtightcouplingŽarefrequentlyusedtermsinsuchdebates,giventhepositiveconnotationoftheformerandthenegativeim-plicationsofthelatter.Reducedcouplingisbene“cialbe-causeinterdependenciestypicallymakecomplexITapplica-tionsystemsbrittleandslowtoadapttochanges[32].Intermsofthegoalswhichshouldbeaccomplishedwhendesigningservicesystems,WS-*andRESTcanbedescribedintegrationcooperation(Fiedleretal.[11]makeasim-ilardistinctionfordatabasesystems).Bothgoals(aswellaslooseŽandtightŽcoupling)arenotgoodorbadper-se.Theyaretheresultofastrategicdecisiononhowtode-signandimplementITarchitectures,andtherecanbevalidbusinessobjectivesforbothofthesegoals.Thesebusinessobjectivesshouldbetheinputforadecisionhowtodesignasystem,forexampleputtingahigheremphasisofperfor-manceoptimization(usuallyeasierwithtightcoupling)oragility(usuallyeasierwithloosecoupling).Thetwelvefacetsdescribedinthispapermakeiteasiertounderstandwhichapproachismoreappropriateforagivenproblem,andforwhichfacetofthesystemdesignalooseortightcouplingapproachshouldbepreferred.Intheend,aswehaveshowninourevaluation,veryfewsystemsarelooselyortightlycoupledaccordingtoallfacets.Instead,theyuseamixofbothdependingonthebusinessobjectivesandtheconstraintsofthechosenWebtechnologies.Ourmulti-facetedmetricthusalsode“nesasetofchoicesthatneedtobemade,givingsystemdesignersamorestructuredapproachformakingbetterdesigndecisionsandcomparingalternativeWebservicestechnologyoptions.AcknowledgementsTheauthorswouldliketothankDomenicoBianculliforhisconstructivefeedback.ThisworkispartiallysupportedbytheEU-IST-FP7-215605(RESERVOIR)project.7.REFERENCESREFERENCESTimBerners-LeeRoyThomasFielding,andLarry.UniformResourceIdenti“er(URI):GenericSyntax.InternetRFC3986,January2005. abilitytobequotedinmanydierentcontexts.Theprob-lemswhichmaycausetightcouplingorwhichcouldbeavoidedbyimplementingloosecouplingarethesameinor-ganizationsandITsystemarchitectures:thetensionbe-tweentheeciencyandsafetyofaninternallydeterminateandcompletelyrationalstructure,vs.thenecessityto“tintoanopenworldofuncertaintyandcon”ictingconcepts.Introducingtightcouplingincomplexsystemsmayalsoaf-fecttheirreliability,makingaccidentsmorepronetohappen,becauselocalfailuresaremorelikelytopropagate[34].Incaseofloosecoupling,thefollowingquoteisrelevanttoillus-tratehowitcan“twellwiththedesignofservice-orientedA“naladvantageofcouplingimageryisthatitsuggeststheideaofbuildingblocksthatcanbegraftedontoanorganizationorseveredwithrel-ativelylittledisturbancetoeithertheblocksortheorganization.[...]Thus,thecouplingim-agerygivesresearchersaccesstooneofthemorepowerfulwaysoftalkingaboutcomplexitynowavailable.Ž[42]LoosecouplingŽoftenisbeingperceivedasreferringtoanyintermediarystateonalinearscalegoingfromnocou-plingŽtotightcouplingŽ,withloosecouplingŽbeingany-whereinbetweenthesetwoextremes.Thisconceptualiza-tionlooksatcouplingasaone-dimensionalconcept.Or-tenandWeick[29]arguethatthelinearviewofcouplingistooconstrained,andsuggesttofollowatwo-dimensionalapproach.responsivenon-responsive non-distinctivedistinctivenon-coupledtightly coupledloosely coupleddecoupledFigure1:Two-DimensionalViewofCouplinginOr-ganizationalStudiesThetwo-dimensionalde“nitionshowninFigure1hasbeendevelopedwithinthecontextoforganizationalstud-ies.Butevenforthegoalofachievingloosecouplinginthecontextofservice-orientedsystemsdesign,thismodelcanbeusefultounderstandthatamulti-dimensionalapproachtode“netheconceptcanleadtoimprovedunderstanding.IftheITlandscapeforwhichservicesarebeingdesignedhasdistinctivecomponents,thenitisnotrealistictolookattightcouplingastheultimategoal.If,however,fororgani-zational,contractual,political,orlegalreasons,itispossibletoremovedistinctiveness,itispossibletodesignandde-ployatightlycoupledsystem.Inthetwo-dimensionalviewofcoupling,thequestionishowtoachieveresponsiveness(i.e.,theabilityforallbusiness-levelgoalstobeachievedbyhavingservicesinteract)giventhedesigngoalsand/ortheconstraintsoftheenvironment.Evenwiththistwo-dimensionalviewofcoupling,however,itisstillnotcompletelyclearwhatthesetwoorthogonalaxes(responsiveness,distinctiveness)refertointhecontextofservice-orientedsystemsdesign.Nowadaysitis,forexam-ple,well-acceptedthatdistinctivenessintermsofthephys- Withtheexceptionbeingtheintroductionofatechnologylayerwhichintroduceshomogeneity,whichisthetraditionalmiddlewareapproach.icalnetworkinfrastructureismostlyirrelevant„theInter-netprovidesaprotocolstackwhichmakesitunnecessarytodealwithnetworkprotocolissuesthatwereseriousissueswhencomputernetworkswerestilldominatedbyvendor-speci“cprotocolsuites.ThisbegsthequestionwhatkindofpropertiesoneshouldlookforwhenevaluatingagiventechnologyaccordingtothemodelshowninFigure1.ThenextSectionthusintroducesanumberoffacetswhichwehaveidenti“edasbeingimportantpropertiesfordecidinghowagivenservice-orienteddesignshouldbeevaluatedtomeasureitscouplingproperties.4.COUPLINGFACETSThissectionintroducesaframeworkwhichcanserveasatoolforanalyzingthekindofcouplingimpliedbyagiventechnologychoiceduringthedesignofaservice-orientedsystem.Fromthepreviousdiscussion,itisclearthatcou-plingisacomplexconceptthatrequirestoexploreamulti-dimensionalspace.Todoso,welookatvariousfacetstowhichthetermcanbeapplied.Wepreferthetermfacetsovertoemphasizethatnotallfacetsarecom-pletelyindependent.Whileenumeratingthefollowingfacets(summarizedinTable1),wehaveattemptedtoachieveahighdegreeofindependencebetweenthem,butwedonotclaimthattheyarefullyorthogonal.Thefacetscoverallrelevantdesignaspectsthathelptounderstandwhichkindofcouplingcanbefoundinasystem.Ourmethodforidentifyingrelevantfacetsisbasedontheprinciplethatafacetshouldbeincludedifthereisaconcretescenariowherethefacetcanhelptobetterunderstandhowasystemdesignoratechnologymightbeperceivedasbeingtightlyorlooselycoupled.4.1DiscoveryDiscoveryisoneofthefacetswhichcanbeapproachedindierentways.Inclosedenvironments,itispossibletode“neandimplementpoliciesforcompulsoryregistrationofservicedescriptionsandinterfaces,makingitpossibleforclientstodiscoverthem(e.g.,usingUDDIregistries[7]).TheWeb,however,hasnocentralregistrybeyondtheDNS(whichisnotWeb-speci“c,butacorepartoftheInternetprotocolsuite).SomeattemptsweremadetohaveWebsiteregistriesŽ(similartoYahoo!ortheOpenDirectoryProject)butsuchcentralizedregistry-basedapproacheswereoverwhelmedbytheWebsrateofgrowth,andthelackofauniversallyacceptedschemeforclassifyingWebresources.Nowadays,clientsperformdiscoveryontheWebthroughsearchengines.SearchenginesdonotnecessarilyrequiretheregistrationofnewWebpages,astheycanrelyoncrawlersfollowinghyperlinkstodiscoverthem.RESTfulWebservicesareusuallynotdescribedorreg-isteredinanystandardizedorcentralizedway.TheideaisthataRESTfulWebservicecanbediscoveredbydecentral-izedreferral(i.e.,byexchangingahyperlinkpointingtoit)anddoesnotneedadescriptionintermsofitsoperations,andthattherepresentationsthattheserviceacceptsandproducesareexposedthroughHTTP,andaredocumentedasmediatypes.Thus,discoveryforaRESTfulWebservicemeansinteractingwithit,andtheonlypossibleregistryŽmightbesetsofURItemplates[16],describinghowitsre-sourcesareaddressedthroughURIs.InthecaseofSOAPandWS-*,noequivalentlooselycoupledŽmechanismisavailabletodescriberelationships FacetTightCouplingLooseCoupling 4.1DiscoveryRegistrationReferral4.2Identi“cationContext-basedGlobal4.3BindingEarlyLate4.4PlatformDependentIndependent4.5InteractionSynchronousAsynchronous4.6InterfaceOrientationHorizontalVertical4.7ModelSharedModelSelf-DescribingMessages4.8GranularityFineCoarse4.9StateShared,StatefulStateless4.10EvolutionBreakingCompatible4.11GeneratedCodeStaticNone/Dynamic4.12ConversationExplicitRe”ective Table1:CouplingFacetsSummarybetweenservicesthatcanbeexploitedforthepurposesofdiscovery.ItisworthnotingthattheglobalUDDIbusinessregistrieswerediscontinuedinJanuary2006.After5yearsofoperationtheyhadaccumulatedlessthan50000serviceregistrations(asmallnumberwhencomparedtothesizeoftheWeb),showingthatthetightlycoupledŽassumptionofexpectingallserviceproviderstomanuallyregisterthem-selveswasnotpractical.However,UDDIcontinuestothrivewithintheboundariesofthecorporate“rewall,showingthatatightlycoupledsolutioncanworkinalocalenvironment.Discoveryalsorequiresacommonmodel(seeSection4.7),becausediscoveryimpliesthatservices(andregistries)sharesomemodelofwhattodiscover,andhowtodiscoverit.Forexample,keywordsearch(i.e.,indexedphrases)isthelargestcommondenominatorontheWeb:itisafreetextmodel.Italsoisaweakmodelbecauseitdoesnotensurethatre-sultsactuallymatchagivenAPI,asshown,forexample,bytheworkontheWooglefree-textsearchengineforWebservices[8].4.2Identi“cationIdenti“cation(oftenalsoreferredtoasnaming)isoneofthemostimportantdesignconsiderationsinordertoconnectsystemswiththerealworld,andsystemswithsystems.Sys-temsusuallyperformtasksappliedtoobjectsfoundoutsideofthesystemsthemselves.Identi“cationisaboutmakingtheassociationbetweentherepresentationswithinthesys-tems,andtheseexternalentities(andofcoursealsofortheentitiesonlyexistingwithinsystems).Thechallengesre-latedtoidenti“cationincludedesigningnamespaces,assign-ingidentities,andprovidingidentity-relatedservices,suchasdiscoverylookups,bindings,orcomparisons[21].Tightlycoupledapproachestoidenti“cationmostlyrelyoncentralizedservices,wherethereisasingleentityassign-ingandmanagingidentities.Inthatcase,identityismostlytiedtothecontextwithinwhichservicesarecooperatingwiththatcentralentity.Assoonasidenti“ersaremovedoutsideofthatcontext,serviceslosetheabilitytomeaning-fullyhandletheseidenti“ers;theybecomeopaquewithnoclearlyde“nedruleshowtointerpretandresolvethem.Ide-ally,identi“ersintightlycoupledscenariosalwaysshouldbeaugmentedwithadditionalcontextinformationwhentheyleavetheoriginalcontext.Inpractice,however,thisrarelyhappensandtheproblemofresolvingidenti“ersduetoalossofcontextisafrequentlyoccurringproblem[38].Loosecouplingisbasedonanidentityconceptwhichdoesnotcoupleidenti“cationtocontext.InthecontextofREST,identi“cationisdoneusingaUniformResourceIdenti“er[1].URIscanusevariousidenti“cationwiththemostfrequentlyusedoneontheWebbeingthescheme.Servicesarefreetousewhateveridenti“cationschemetheylike,theimportantaspectbeingthatagreeingonURIsasthecommonwayofidenti“cationmakesiteas-iertousegloballyuniqueidenti“erswithoutrelyingonacentralizedauthority.Ifapplicationsinsistonusingopaquelocalidenti“ers,thesecanbefoldedintoURIsusingthescheme[22].However,thiswouldre-createtheproblemoftheseURIsneedingapropercontextforinterpretationthatistypicalfortightlycoupledidenti“cation.4.3BindingCloselyrelatedtodiscoveryandidenti“cation,bindingreferstotheprocessofresolvingsymbolicnamesintoiden-ti“ersusedatalowerabstractionlevel.Forexample,aDNSnamecanbeboundtooneofthecorrespondingIPaddressesusingaDNSlookup(aformofdiscovery).Inservice-orientedsystems,bindingcanbeappliedindierentways[30].Abstractserviceinterfacesreferredtobyclientsneedtobeboundtoaconcretenetworkendpointandtrans-portprotocolusedbytheserviceprovider.Likewise,thepartnerlinksofaBPELprocessneedtobeboundtocom-patibleWSDLporttypes.Atightlycoupledbindingisonethatishardtochange,e.g.,whenitisresolvedearly,alongtimebeforethere-sultofthelookupisactuallyneeded.Thus,compile-timeordeployment-timebindingareconsideredtoestablishatightcouplingbetweentheboundentities,asitwillnotbepossi-bletochangethebindingduringtherestofthelifecycleofthesystem.Dynamicbindinginsteadhappensatrun-time,andpartic-ularlyatthelatestpossibletime(e.g.,rightbeforeaserviceinvocation).Thisisaformofloosecoupling,becausethebindingisestablishedonlywhenitbecomesnecessary.Per-formingalookupbeforeeveryserviceinvocation,however,canimposeasigni“cantoverheadandestablishesatightcouplingbetweentheclientsandtheresolver.Notonlytheresolverbecomesascalabilitybottleneck,butiftheresolverwouldbecomeunavailable,allclientlookupswillfailandclientswillbeunabletoperformanyserviceinvocation.4.4PlatformPlatformcouplingconcernstherequirementsforallser-vicestobebasedonahomogeneousmiddlewareinfrastruc-ture.Iftwoservicesneedtocommunicate,theymustbe straction(thehorizontalinterfacebetweentheprotocolim-plementationandtheserviceuser)isdesigned(Figure2.2showsthebasicmodel,Figure2.3showsaninternalsepa-rationoftheclient-sidecode).Horizontalinterfacesoftenleadtohomogenousenvironments,whereallintegratedser-vicesdependonthesamemiddlewareAPIs(whichhidetheproprietaryprotocols).AtypicalexampleforaprotocolisTCP,whichimplementsinter-processcommunicationsontheInternet,andistheprotocolmostoftenusedthroughthesocketAPImentionedearlier.TocommunicatewithapeerovertheInternet,onlyTCPisrequired;socketsareapopularchoiceforusingTCP,butareanentirelylocalissue.4.7ModelThisfacetisaboutwhetherthedesignassumesthatthereisacommonapplication-leveldatamodelthatissharedamongserviceswithinaproblemdomain.Ifthisisthecase,thenmessagesaresimplytreatedasaserializationofthatmodel,whichisonlyusedtotransferamodelinstancefromoneservicetotheotherthroughsomecommunicationsmedium.Thisapproachoftenusesgeneratedcodeformar-shalingandunmarshaling,becausethemodelinstanceinessenceisthesharedinformation,andallservicesusethesamemethodformappingmodelstothewireformat.Thissharedmodeldesignintroducestightcoupling,be-causethereisastrongconceptualconnectionbetweenallservicessharingthesamedatamodel.Thiscouplingoftenisnotonlytightinprinciple,italsoistightinpractice,be-causeservicesarebuiltwithaparticularmethodortoolformarshalingandunmarshaling.Serviceswishingtouseadif-ferentmethodortoolhaveahardtimedoingso,becausetherepresentationonthewirehasnotbeendesignedforin-teroperabilityandreuseindierentcontexts,butinsteadisjustaserializationofthesharedmodel.Loosecouplingdoesnotassumethatthereisasharedmodel,insteadmessagesbeingexchangedareself-containedandaredesignedtobeprocessedasdocumentsinastan-dardizedrepresentationformat.Thusmessagescanbepro-cessedwithanytoolsetforthatformat[43].Looselycoupledservicescanuseadierentinternalmodel(adaptedtotheirlocalrequirements)aslongastheysolvetheproblemofmap-pingthestandarddocumentformattotheirinternalmodels.Whilethisadditionalstepofmappingdocumentstructurestoaninternalmodelmightberegardedasoverheadthatisnotrequiredinthetightlycoupledscenario,itisessentialforloosecoupling,becauseitallowscooperationbetweenservicesaslongasthereisasucientsharedunderstandingtode“neamappingbetweentheexternalcanonicalmessageformatandtheinternalmodelsofeachservice.4.8GranularityGranularityofservicesinterfacesisaboutthedesigntrade-obetweenthenumberofinteractionsthatarerequiredtoprovidecertainfunctionalitytoservicealargeclientcom-munity,andthecomplexityofthedataparameters(orop-erationsignatures)tobeexchangedwithineachinteraction.InAPIdesign,atypicalgoalistominimizethenumberofinteractions[17].Inservicedesign,thisisevenmoreso,duetothehighlatencyinvolvedinaserviceinvocation.Byusingmorecoarse-grainedinterfaces(i.e.,fewerinter-actionsrequired),servicescanexploittheextensibilityofwell-designedmessageformats,andserviceevolution(Sec-tion4.10)canbebasedonmessageextensibility,ratherthananextensionofthesetofpossibleserviceinteractions.Fine-granularinterfacesaretightlycoupledbecausechangesinaserviceintroduceorremoveoperations.Themainad-vantageof“ne-granularinterfacesusuallyiseciency,be-causeitispossibletopickspeci“cinteractionshavingtheexactsignaturerequiredbyasubsetoftheclients,forwhichtheoverheadofexchangingunnecessarydatacanbere-4.9StateDependingonthescaleofaservicelandscape,stateman-agementcanbecomeoneofthecentralproblemsinecientservicedesign.Statefulservicesarebasedontheassumptionthataservicekeepsstateofanongoinginteraction,leadingtoproblemsforserviceswithmanyclients,highthroughput,andlong-runningtransactions.Thealternativeistochooseastatelessservicedesign,whichkeepsstateinthemessagesthatarepassedbackandforthbetweencooperatingservices.Loosecouplingforstatemanagementmeansstatelessser-vices.Asanexample,theacronymRESTitselfstandsforRepresentationalStateTransferandhighlightsthatstate-lessinteractionsareoneofthekeypropertiesoftheWeb.Mechanismsforsessionmanagement(e.g.,cookies[24]orURIrewriting)areneverthelessalsoavailable.However,sharedstate(i.e.,statethatiskeptbytwoormoreinter-actingservices)alwaysimpliestightcoupling,becausetheremustbeassociatedmechanismsofestablishingandrecov-eringstatefulsessions,comparingstates,resolvinginconsis-tencies,implementingtime-outmechanisms,andperformingdistributedgarbagecollection.Themanagementoverheadofsharedstateissubstantial,soitshouldonlybeemployedwhenrequired,i.e.,toreducethesizeofmessagepayloads.4.10EvolutionThisfacetconcernshowservicescanevolveovertime,andhowthataectstheirclients.Fromthepointofviewoftheserviceprovider,compatibilityamongversionscanbeseenintwodirections:Backwardcompatibilityallowsolderclientstokeepfunctioningwhenusingaservicethathasbeenupgradedtoanewversion.Forwardcompatibilitylowsnewerclientstouseanoldversionofaservice,eventhoughtheyhavebeendevelopedagainstanewerversionoftheservice.Evolutionbecomesparticularlyimportantinconnectionwiththediscoveryfacet,becausethecompati-bilityofclientsandservicesshouldbetakenintoaccountduringthelookup.Also,incaseoflatebinding,run-timeerrorsmaybeproducedifclientsareboundtoevolved(andpotentiallyincompatible)services.Tightcouplingforthisfacetisimpliedbyanexactmatchofversions,sothatneitherforwardorbackwardcompatibil-ityaresupported.Alooselycoupleddesigninsteadattemptstoprovideasmuchforwardandbackwardcompatibilityaspossible,eveniftherearelimitstohowmanychangesanin-terfacecanwithstandwithoutbreakingclients.Loosecou-plingthereforeneedstocombinerulesabouthowtohandledieringversionnumbers,andwhatrulestoapplyintheeventofdieringversionnumbers. Interestingly,oneofthecorespeci“cationsoftheWeb,XMLitself,atthetimeofwritingisundergoingacontrover-sialupdate.Theproposed5theditionofXML1.0[4]wouldnotchangetheversionnumberofXML,butintroducenewfeatures.Thisway,theloosecouplingofXML-basedserviceswouldbecompromised,becausesomedocumentsconform-ingtothe5theditioncouldnotbeprocessedusingolderXMLprocessors.Itisstillunclearwhethertheproposed WS-*/ESB RPCoverHTTP RESTfulHTTP DegreeofCoupling LooseCouplingCouplingFacet TightCoupling Design-SpecificCoupling DiscoveryIdentificationBindingPlatformInteractionInterfaceOrientationInterfaceInterfaceModelGranularityStateEvolutionGeneratedCodeGeneratedCodeGeneratedCodeConversation DiscoveryIdentificationBindingPlatformInteractionModelGranularityStateEvolutionConversation (a)RESTfulHTTP(b)RPCoverHTTP(c)WS-*/ESBFigure3:MeasuringthedegreeofcouplingimpliedbydierentWebservicestechnologies RESTfulHTTPRPCoverHTTPWS-*/ESB 4.1DiscoveryReferralReferralRegistration4.2Identi“cationGlobalGlobalContext-based4.3BindingLateEarly/LateLate4.4PlatformIndependentIndependentIndependent4.5InteractionAsynchronousSynchronousAsynchronous4.6InterfaceOrientationVerticalHorizontalHorizontal4.7ModelSelf-DescribingMessagesSharedModelSelf-D.Messages/SharedModel4.8GranularityFine/CoarseFine/CoarseFine/Coarse4.9StateStatelessStateless/Shared,StatefulStateless4.10EvolutionCompatible/BreakingCompatible/BreakingCompatible/Breaking4.11GeneratedCodeNone/DynamicStaticStatic4.12ConversationRe”ectiveExplicitExplicit Table2:WebServicesTechnologyEvaluationSummaryprotocol.However,whenitcomestotheinteractionfacet,somedierencesbecomeapparent.RPCinteractionsarebyde“nitionsynchronous.RESTfulinteractionsareinsteadasynchronous,sinceservicesinteractindirectlybyupdating,or)thestateofresources,whichcanbelateraccessedbyotherservices(with)[33].Inter-faceorientationisverticalinREST,whichonlyreliesontheprotocolandresourcerepresentations,whereasRPCisoftenbasedonthestubmechanismwheretheclientofaremoteserviceaccessedviaRPCcallsalocalinterfacewhichthenhandlesthefactthattheserviceisimplementedremotely.Thetwotechnologiesalsodierintermsofthemodelfacet,whereRPCfollowsasharedmodelapproach,whereallser-vicesmustagreebeforehandonthesyntaxandthesemanticsoftheexchangedmessages,whileRESTpromotesaSelf-DescribingRepresentationsŽsolution.RESTfulinteractionsarealsostateless,whileRPCoersbothoptions,asinteract-ingservicesmayestablishasessionbysharingstateamongthem,butalsomaybedesignedtoavoidsuchtightcou-pling.RPCisalsobasedongeneratedcodestubs,whileRESTdoesnotrequirethemasitfollowsamoredynamicapproachbasedonpluginextensibility.Alsoregardingcon-versations,RESTpromotesadynamic,re”ectiveapproach,whileRPC-basedWebservicesmaketheinteractioncon-straintsexplicitatdesign-time.Itisworthnotingthatnotallthefacetsareboundbythepropertiesofagiventechnology.Forexample,thegran-ularity,state,andevolutionfacetsdependontheconcretedesignchoiceofagivenservice-orientedsystemarchitecture,andarenotconstrainedbythechoiceoftheRESTvs.RPCstyles.Inotherwords,itispossibletodesigntightlycou-pledRESTfulWebservices,whichcanbechattyŽintheirinteractions,iftheirinterfacesexposealargenumberof“ne-grainedresources.ThesamecanbesaidaboutRPC-basedservices,whichcaneitherpublishmany“ne-grainedopera-tions,orafewcoarse-grainedones,dependingonthecho-sendesignstrategy.Alsointermsoftheevolutionfacet,aservicedesignneedstobeevaluatedatamorespeci“clevel.Forexample,XMLtechnologycansupportalooselycoupledevolutionfacetonlyifitisusedwithadditionalguidelinesforversioningandtheenforcementofWehavechosentoincludeinourevaluationtheWS-*/ESBtechnology(whichisnotWeb/HTTPcentric),becausetheenterpriseservicebusfamilyofmiddlewareproductsiswidelyperceivedtobethefoundationforlooselycoupledSOAim-plementations.Thus,itisinterestingtoapplyourmulti- facetedde“nitionalsotomeasurethecouplingimpliedbythistechnology.WeobservethatESBprovidesloosecou-plingaccordingtofourfacets:binding(Dynamic),interac-tion(Asynchronous),state(Stateless)andplatform(Inde-pendent).However,thetechnologyusescontext-basediden-ti“cation(atightlycoupledsolution)andrequirescentral-izedserviceregistrationtosupportservicediscovery.Also,interactionsbasedonmultiplemessageexchangesareexplic-itlymodeledusingwork”owandconversationmodels.ThedevelopmentprocessofservicesconnectedbyanESBreliesoncodegenerationtechniques(thus,anESBpresentsanhorizontalinterfaceorientation).Therefore,accordingtoalloftheseother“vefacets,thiskindofmiddlewaretechnologydoesnothelptoachieveloosecoupling.Similartotheothertwoalternatives,thechoiceofusinganESBdoesnotcon-straintheevolutionandgranularityfacets.Additionally,itisalsopossibletochoosebetweenasharedmodeldesign,ortoleveragetheESBmediationcapabilitiestofosteramorelooselycoupleddesignbasedonself-describingmessages.Inmorequantitativeterms,thetablecountsthenumberoffacetsforwhichatechnologyresultsinlooseortightcou-pling.Wealsodistinguishfacetsforwhichthedegreeofcouplingdoesnotdependonthechosentechnologybutmayvarydependingonmorespeci“cdesigndecisions. RESTRPCWS-*/ESB Loose1034Tight045 Design-Speci“c253 Onlyinthebestcase(assumingthatalldesign-speci“cfacetsfollowlooselycoupledoptions)wecanconcludethatusingRESTfulHTTPwouldprovideasystemarchitecturefeaturingloosecouplingaccordingtoallfacets.ChoosingRPCoverHTTP,instead,wouldnotresultinacompletelylooselycoupledsystem,duetothe4facets(interaction,model,generatedcode,andconversation)whichonlypresentatightlycoupledapproach.Thisalternativealsorequires DiscoveryIdentificationBindingPlatformInteractionModelGranularityStateEvolutionConversationInterfaceOrientationGeneratedCode RPCoverHTTPRESTfulHTTP Figure4:ComparingthedegreeofcouplingimpliedbydierentWebservicestechnologiesmoreeorttoachievealooselycoupledsystem,asupto5facetsaredesign-speci“candareunconstrainedbythetechnologychoice.ThisnumberissmallerincaseoftheWS-*/ESBalternative,whereonly3facetsaredesign-speci“c.Amoredetailed,facet-by-facetcomparisonisvisualizedwiththeradarchartofFigure4.ItisinterestingtonoticethatthecurveindicatingthedegreeofcouplingimpliedbyRESTfulHTTPisstrictlyboundedbybothoftheothercurves.Ifwedonotconsiderthediscoveryandidenti“cationfacets,thesameholdsbetweentheRPCandtheESBcurves.Thus,ourmulti-facetedmetriccanbeusedtoestablishapartialor-deringbetweendierentWebservicestechnologiesintermsoftheirdegreeofcoupling.6.CONCLUSIONSSOAP-basedWebservicesandtheRESTarchitecturalstylehavebeenandstillarethetopicofmanydebates.Manyofthesedebatesareheated,oftenmissingthepointthatthemoreprescriptivestyleoftheSOAPapproachandthemoredescriptivestyleoftheRESTapproachhavetheirrootsindierentscenarios,theformerassumingclosedworldsandcontractualrelationships,whereasthelattercaterstoanopenworldwithad-hocinteractions[40].Sofar,onlyfewattemptshavebeenmadetocomparebothapproachesasobjectivelyaspossible[31].LoosecouplingŽandtightcouplingŽarefrequentlyusedtermsinsuchdebates,giventhepositiveconnotationoftheformerandthenegativeim-plicationsofthelatter.Reducedcouplingisbene“cialbe-causeinterdependenciestypicallymakecomplexITapplica-tionsystemsbrittleandslowtoadapttochanges[32].Intermsofthegoalswhichshouldbeaccomplishedwhendesigningservicesystems,WS-*andRESTcanbedescribedintegrationcooperation(Fiedleretal.[11]makeasim-ilardistinctionfordatabasesystems).Bothgoals(aswellaslooseŽandtightŽcoupling)arenotgoodorbadper-se.Theyaretheresultofastrategicdecisiononhowtode-signandimplementITarchitectures,andtherecanbevalidbusinessobjectivesforbothofthesegoals.Thesebusinessobjectivesshouldbetheinputforadecisionhowtodesignasystem,forexampleputtingahigheremphasisofperfor-manceoptimization(usuallyeasierwithtightcoupling)oragility(usuallyeasierwithloosecoupling).Thetwelvefacetsdescribedinthispapermakeiteasiertounderstandwhichapproachismoreappropriateforagivenproblem,andforwhichfacetofthesystemdesignalooseortightcouplingapproachshouldbepreferred.Intheend,aswehaveshowninourevaluation,veryfewsystemsarelooselyortightlycoupledaccordingtoallfacets.Instead,theyuseamixofbothdependingonthebusinessobjectivesandtheconstraintsofthechosenWebtechnologies.Ourmulti-facetedmetricthusalsode“nesasetofchoicesthatneedtobemade,givingsystemdesignersamorestructuredapproachformakingbetterdesigndecisionsandcomparingalternativeWebservicestechnologyoptions.AcknowledgementsTheauthorswouldliketothankDomenicoBianculliforhisconstructivefeedback.ThisworkispartiallysupportedbytheEU-IST-FP7-215605(RESERVOIR)project.7.REFERENCESREFERENCESTimBerners-LeeRoyThomasFielding,andLarry.UniformResourceIdenti“er(URI):GenericSyntax.InternetRFC3986,January2005. AndrewBirrellBruceJayNelson.ImplementingRemoteProcedureCalls.ACMTransactionsonComputerSystems(TOCS),2:39…59,February1984.1984.JasonBloombergRonaldSchmelzer,editors.ServiceOrientorBeDoomed!JohnWiley&Sons,NewYork,NY,March2006.2006.TimBrayJeanPaoliC.MichaelSperberg-McQueenEveMaler,andFran¸coisYergeau.ExtensibleMarkupLanguage(XML)1.0(FifthEdition).WorldWideWebConsortium,RecommendationREC-xml-20081126,November2008.2008.LionelC.BriandJohnW.Daly,andurgenK.WAUni“edFrameworkforCouplingMeasurementinObject-OrientedSystems.IEEETransactionsonSoftwareEngineering,25(1):91…121,January1999.1999.DavidChappellEnterpriseServiceBus.OReilly,2004.2004.LucClementAndrewHatelyClausvonRiegen,andTonyRogers.UDDIVersion3.0.2.OrganizationfortheAdvancementofStructuredInformationStandards,UDDISpecTechnicalCommitteeDraft,October2004.2004.XinDongAlonY.HalevyJayantMadhavan,andJunZhang.SimilaritySearchforWebServices.InProceedingsofthe30thInternationalConferenceonVeryLargeDataBases,pages372…383,Toronto,Canada,September2004.004.ThomasErlService-OrientedArchitecture:Concepts,Technology,andDesign.PrenticeHall,2005.2005.PatrickTh.EugsterPascalA.FelberRachidGuerraoui,andAnne-MarieKermarrec.Themanyfacesofpublish/subscribe.ACMComputingSurveys35(2):114…131,2003.2003.GunarFiedlerThomasRaak,and.DatabaseCollaborationInsteadofIntegration.SvenHartmannMarkusStumptner,editors,Proceedingsofthe2ndAsia-Paci“cConferenceonConceptualModelling,pages49…58,Newcastle,Australia,January2005.2005.RoyThomasFieldingArchitecturalStylesandtheDesignofNetwork-basedSoftwareArchitectures.PhDthesis,UniversityofCalifornia,Irvine,Irvine,California,2000.2000.RoyThomasFieldingJimGettysJeffreyC.MogulHenrikFrystykNielsenLarryMasinterPaulJ.Leach,andTimBerners-Lee.HypertextTransferProtocol„HTTP/1.1.InternetRFC2616,June1999.1999.RoyThomasFieldingRichardN.TaylorPrincipledDesignoftheModernWebArchitecture.ACMTransactionsonInternetTechnology,2(2):115…150,MayyCarloGhezziMehdiJazayeri,andDinoMandrioliFundamentalsofSoftwareEngineering.PrenticeHall,2003.2003.JoeGregorio.URITemplate.InternetDraftdraft-gregorio-uritemplate-03,March2008.2008.MichiHenning.APIDesignMatters.ACMQueue5(4):24…36,May2007.2007.GregorHohpeEnterpriseIntegrationPatternsAddison-Wesley,October2003.2003.NicolaiM.JosuttisSOAInPractice.OReilly,AugustAugustDougKayeLooselyCoupled:TheMissingPiecesofWebServices.RDSPress,August2003.2003.TimKindberg.Ubiquitousandcontextualidenti“erresolutionforthereal-worldwideweb.TechnicalReport95,HPLabs,2001.2001.TimKindbergSandroHawke.ThetagURIScheme.InternetRFC4151,October2005.005.DirkKrafzigKarlBanke,andDirkSlamaSOA:Service-OrientedArchitectureBestPractices(TheCoadSeries).PrenticeHall,2004.2004.DavidM.KristolLouMontulli.HTTPStateManagementMechanism.InternetRFC2965,OctobererMicheleLanzaRaduMarinescuObject-OrientedMetricsinPractice.Springer,2006.2006.G.J.MyersComposite/StructuredDesign.VanNostrandReinhold,1978.1978.EricNewcomerGregLomowUnderstandingSOAwithWebservices.Addison-Wesley,2005.2005.JohannOberleitnerThomasGschwind,andJazayeri.TheViennaComponentFrameworkenablingcompositionacrosscomponentmodels.InICSE03:Proc.ofthe25thInternationalConferenceonSoftwareEngineering,pages25…35,2003.2003.J.DouglasOrtonKarlE.Weick.LooselyCoupledSystems:AReconceptualization.AcademyofManagementReview,15(2):203…223,April1990.1990.CesarePautassoGustavoAlonso.FlexibleBindingforReusableCompositionofWebServices.InProc.ofthe4thWorkshoponSoftwareComposition(SC2005)Edinburgh,Scotland,April2005.2005.CesarePautassoOlafZimmermann,and.RESTfulWebServicesvs.ŽBigŽWebServices:MakingtheRightArchitecturalDecision.InProceedingsofthe17thInternationalWorldWideWebConference,pages805…814,Beijing,China,April2008.ACMPress.Press.CynthiaRettig.TheTroublewithEnterpriseSoftware.MITSloanManagementReview,49(1):21…27,2007.2007.LeonardRichardsonSamRubyRESTfulWebServices.OReilly,May2007.2007.JosA.Rijpma.Complexity,Tight-CouplingandReliability:ConnectingNormalAccidentsTheoryandHighReliabilityTheory.JournalofContingenciesandCrisis,5(1),March1997.1997.WayneP.StevensGlenfordJ.Myers,andLarryL.Constantine.StructuredDesign.IBMSystemsJournal13(2):115…139,1974.1974.AndrewS.TanenbaumDistributedOperatingSystemsPrentice-Hall,EnglewoodClis,NewJersey,SeptembererJamesD.ThompsonOrganizationsinAction:SocialScienceBasesofAdministrativeTheory.McGraw-Hill,NewYork,NY,June1967.1967.ManolisTzagarakisNikosKarousos,andSiegfriedReich.NamingasaFundamentalConceptofOpenHypermediaSystems.InProceedingsofthe11thACMConferenceonHypertextandHypermedia,pages103…112,SanAntonio,Texas,May2000.ACMPress.Press.SteveVinoski.OldMeasuresforNewServices.InternetComputing,9(6):72…74,November2005.2005.SteveVinoski.SerendipitousReuse.IEEEInternet,12(1):84…87,January2008.2008.SanjivaWeerawaranaFranciscoCurberaTonyStorey,andDonaldFergusonServicesPlatformArchitecture.PrenticeHall,March2005.005.KarlE.Weick.EducationalOrganizationsasLooselyCoupledSystems.AdministrativeScienceQuarterly21(1):1…19,March1976.1976.ErikWildeRobertJ.Glushko.DocumentDesignCommunicationsoftheACM,51(10):43…49,October2008.2008.DanWoodsThomasMatternEnterpriseSOA:DesigningITforBusinessInnovation.OReilly,2006.2006.E.YourdonL.ConstantineStructuralDesignPrenticeHall,1979.1979.HubertZimmermann.OSIReferenceModel„TheISOModelofArchitectureforOpenSystemsInterconnection.IEEETransactionsonCommunications,28(4):425…432,April1980.1980.OlafZimmermannMarkTomlinson,andStefanPerspectivesonWebServices:ApplyingSOAP,WSDL,andUDDItoReal-WorldProjects.Springer,September2003.