ExamplebookingtheconnectingightR2mayfailduetolackofavailableseatsA2emphasizesthepointthatifnothingcaneverfailthenidempotenceisallthatisneededforatomicitywheneachrequestRiisretrieduntilallhavesucce ID: 416509
Download Pdf The PPT/PDF document "AtomicDistributedTransactions:aRESTfulDe..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
AtomicDistributedTransactions:aRESTfulDesignGuyPardonATOMIKOSguy@atomikos.comhttp://www.atomikos.comCesarePautassoFacultyofInformatics,UniversityofLugano,Switzerlandc.pautasso@ieee.orghttp://www.pautasso.infoABSTRACTTheRESTarchitecturalstylesupportsthereliableinteractionofclientswithasingleserver.However,noguaranteescanbemadeformorecomplexinteractionswhichrequiretoatomicallytrans-ferstateamongresourcesdistributedacrossmultipleservers.Inthispaperwedescribealightweightdesignfortransactionalcom-positionofRESTfulservices.TheapproachbasedontheTry-Cancel/Conrm(TCC)patterndoesnotrequireanyextensiontotheHTTPprotocol.ThedesignassumesthatresourcesaredesignedtocomplywiththeTCCpatternandensuresthattheresourcesin-volvedinthetransactionarenotawareofit.Itdelegatestherespon-sabilityofachievingtheatomicityofthetransactiontoacoordina-torwhichexposesaRESTfulAPI.CategoriesandSubjectDescriptorsK.4.4[ElectronicCommerce]:DistributedCommercialTransac-tions;H.2.4[Systems]:TransactionprocessingKeywordsRESTfulWebservices;REST;WebAPIDesign;Atomicity;AtomicDistributedTransactionProtocol1.INTRODUCTIONReliabilityofsingleclient-serverinteractionsisconsideredasaprimaryconcernbytheRESTarchitecturalstyle[4].Thisisachievedthroughtheuniforminterfacesemanticsofidempotentmethods(e.g.,GET,PUT,DELETEinHTTP)sothatanyfailureduringtheseinteractionscanbeaddressedbysimplyretryingtherequest.However,noguaranteescanbemadeforcomplexinter-actionswhichatomicallytransferstateamongmultipleresourcesdistributedacrossmultipleRESTfulWebservices[20].Forex-ample,whenaclientinteractswithmorethanoneRESTfulAPIsforightreservations,wewanttoensurethatallrequestsareper-formedatomicallytocompletethereservationofallightsasasinglestep.Thegoalofthispaperistodescribeasimplesolutionwhichtsthefollowingdesignconstraints:1)Usingalightweighttransactionmodel(e.g.,ATOMIKOSTCC[13])tominimizeinteroperabilityrisks;2)AvoidingextensionstotheHTTPprotocoltomaximizeadoption;3)DeployingthetransactioncoordinatorasaRESTfulservice(asmotivatedintheremainderofthispaper);4)Keepingtheparticipantsunawarethattheyarepartofatransaction(shippingtransactioncontextshasshowntobemajorpainpointofdistributedtransactions).Copyrightisheldbytheauthor/owner(s).WWW'14Companion,,April711,2014,Seoul,Korea.ACM978-1-4503-2745-9/14/04.http://dx.doi.org/10.1145/2567948.2579221.Theproblemabouthowtotransparentlydealagainstfailuresce-narioswithinRESTcompositions,wherestateneedstobeatomi-callytransferredbetweenmorethantwoservices,isanimportantone.ThesolutionmakesitpossibletogroupmultipleRESTfulin-teractionsandtreatthemasasinglelogicalstep,aswellastoensurethatitispossibletoguaranteetheconsistencyofasetofresourceswhichbelongtomultipleRESTfulWebservicesthataredeployedondifferentWebservers.Whereassolutionshavebeenproposedtobatchinteractionsaffectingmultipleresourcesprovidedbyasingleserver(e.g.,WebDAV'sexplicitlockingmethods[6],orthetransac-tionsasaresourceapproachfrom[20,p.231]),thesearenotappli-cabletointeractwithmultipleresourcesdistributedacrossmultipleservices.Thispaper'scontributionfocusesonaddressingtheatomicityproperty[7]ofdistributedtransactionsacrossRESTfulWebser-vicesinasimpleway[10].Thisalreadyaddressestherequirementsofawideclassofapplications,whereatomicityisanecessity,whileisolationisnot.Forexample,allscenariosinvolvingsomekindofresourcereservationwhereclientsmayneedtoatomicallyperformmultiplepurchases,or,moreingeneral,atomicallychangethestateofasetofdistributedresources.Thispaperisstructuredasfollows.InSection2weenumeratetheassumptionsbehindtheTry-Cancel/Conrmpatternandhowitrelatestolightweightdistributedtransactions.Section3outlinesthetransactionprotocol,whichisillustratedwithanexampleinthefollowingSection4.Wepresentadetailedviewonthedesignoftheprotocolin5,andsummarizetheparticipantandcoordinatorAPIsinSections6and7.WereectuponthedesignanddiscusssomeopenquestionsinSection8.WegiveabriefsurveyofrelatedworkinSection9beforedrawingsomeconclusionsinSection10.2.ASSUMPTIONSTheprotocolwefollowisbasedonthefollowingassumptions-withouttheseassumptionsthereisnopracticalneedfortheoutlinedsolution.Assumption1(A1):AbusinesstransactionTissendingrequestsRitodifferentRESTfulservicesSj.EachparticipantSjisau-tonomousandloosely-coupledwithTandtheotherSj.Example:Trepresentsaightreservationacrosstwoairlines,consistingofarequestR1tobookarstightatairlineS1andaconnectingightR2atairlineS2.A1isimportantsinceitdistinguishesoursolutionfromexistingtechniqueslikesession-basedoptimisticlocking(astandardindus-trypracticethatworksacrossonesiteonly[5,p.416]).Notethatforsimplicity,weassumenoorderingamongRi(noexplicitrstorlastrequest).Assumption2(A2):AnyRiofTcanfailinanon-transientway. Example:bookingtheconnectingightR2mayfailduetolackofavailableseats.A2emphasizesthepointthatifnothingcaneverfailthenidem-potenceisallthatisneededforatomicitywheneachrequestRiisretrieduntilallhavesucceeded.Idempotencecanhelpresolvetran-sient,technicalfailuresbutnotfundamentalfailuressuchaslackofbusinessresourcestocomplywiththerequest.Assumption3(A3):Tneedstobeatomic,i.e.,Tneedstoeitherhappenentirely(allRi2Tsucceed)ornotatall.Inthelattercase,theendresultneedstobeasifnoneoftheRiexecutedintherstplace.Example:youwanttobooktheentireight(R1andR2)ornoneatall.Ifonlypartoftheightwouldbebooked,youwouldbechargedforanincompletetripthatwouldleadyoutothewrongdestination.A3statestheimportantrequirementthattheoutcomeofthewholetransactioniswhatmatters.Assumption4(A4):SitemporarilyreservesresourcesonbehalfofRiinT.Example:airlineS1holdsaseatreservationforthedurationofT,butwillnotkeeptheseatreservedforever:eitherTsucceeds(andS1billsthecustomer)orTfails(andS1releasestheseatforanothercustomertobook).Corollary1(C1):EachRitakingpartinTmayneedtobecan-celledafterithasbeenexecuted.Consequently,eachRineedstohaveacancellationeventRi;cancelassociatedwithit.FromA1+A2itfollowsthatpartialtransactionscanexistincaseoffailure(s)1.Forinstance,itispossibleforR2tofail,leavingtheeffectsofR1.FromA3itfollowsthatR1thenneedstobecancelled.S1isautonomous(byA1)sothisrequirestheexistenceofacanceleventR1;canceltoinformS1aboutthisevent.Inthiscase,byinvok-ingR1;cancel,thesystemcanensureatomicity.ThesameholdsforeveryRi.Corollary2(C2):EachparticipantSiwilloffer/awaitaconrma-tionRi;confirmforeveryRi.FromA4weknowthatSireservesresourcesonbehalfofT.FromC1weknowthatRicanbecancelled.SiwillthusawaitconrmationofRitosignalthatcancellationwillnolongerhap-pen.SinceonlyTcanknowwhenallitsrequestshavesuccessfullynished,itistheresponsibilityofTtotriggertheconrmation.Example:afterightreservationR2completes,alsoightR1needstobeconrmedwithS1(andbyT)sothatpaymentcanbeissued.Cancellingaconrmedightmaystillbepossiblebutcouldleadtocancellationfees.3.PROTOCOLOUTLINEThepreviousassumptionsleadtothisprotocol:1.AclientgoesaboutinteractingwithmultipleRESTfulserviceAPIsfollowingagivenworkow.2.Interactionsmayleadtoastatetransitionoftheserviceiden-tiedbysomereservationURI.ThisURIcanbelaterusedtocon-rmorcancelit.Iftheservicedoesnothearanythingaftersomeservice-specictimeout,itwillcancelautonomously.3a.Oncetheworkowsuccessfullycompletes,thesetofreser-vationURIsisusedtoconrmthestatetransitionsoftheserviceswithidempotentrequests(e.g.,PUT).3b.Iftheworkowfails,thesetofreservationURIsthathavebeencollecteduntilthefailureoccursareusedtosignaleachofthe 1Asfailuresweabstractbothbusiness-levelfailuresaswellastech-nicalfailures,suchasservercrashesornetworkoutages.serviceswithidempotentmessages(e.g.,DELETE)tocanceltheirstatetransition.Theprotocolguaranteesatomicitybecauseifitstopsbeforesteps3a/3btheresultisacancelperformedindependentlybyeachpartic-ipantafteratimeout.Otherwiseeachparticipantreceivesanidem-potentrequestforconrmation(step3a)/cancellation(step3b)sentduringthenalphase.Amoredetaileddiscussioncoveringmostfailureandrecoveryscenarioscanbefoundin[14]andinthede-taileddesignpresentedbelow.Aswitheverytwo-phasecommitsolution,heuristicsareneededtodealwithtimeouts.Todealwiththem,weproposethatinstep2,atimeoutisspeciedafterwhichtheservicewillunilaterallycancel.Ifstep3happenstoolatethenthismightresultin'heuristic'anomalies(i.e.thetransactionatomicitywasviolated).Inthatcase,humaninterventionisrequiredtoreconcilethestateacrossallsites.Inanycase,thetransactionserviceinstep3isfreetodecidewhenitwillattemptconrmation(i.e.,itmightconservativelyabortthetransactioniftheparticipantsaretooclosetoexpiring).4.EXAMPLEAswearegoingtoshow,weclaimthattheRESTuniformin-terfaceissufcienttocomplywiththeassumptionsrequiredtoimplementtheproposedprotocol.Thus,itispossibletoachievedistributedtransactionsoverRESTfulserviceAPIswithoutanyex-tensionoftheHTTPprotocol,iftheservicesaredesignedtocomplywiththeTry-Cancel/Conrmpattern.Inthecontextoftherunningexample,thispatterncanbeap-pliedtothedesignoftheRESTfulightreservationAPIasfol-lows.ClientscaninquireabouttheavailabilityofightsattheURI:/flight/{flight-no}/seat.Forexample,theGET/flight/LX101/seatrequestwillreturnahyperlinktosomeoftheavailableseatsontheightLX101ornoneiftheightisfullybooked.TheURIofthechosenseatcanbeforwardedwithaPOSTrequesttothe/bookingURL,whichwillcreateanewbookingresourcebyreturningahyperlinkidentifyingitsuchas/booking/{id}/.Thebodyoftherequestcancontainpaymentinformationaswellasareferencetothechosenightandseat(i.e.,seathref="/flight/LX101/seat/63F"/&#x-2.2;ä¤).Seatsonaightareonlyreservedforalimitedamountoftime,duringwhichtheclientshouldconrmthereservation.Thebookingcanbecon-rmedusingaPUT/booking/{id}requestorcanceledwiththecorrespondingDELETE/booking/{id}request.TheexampleillustratesthataRESTfulserviceAPIcompliantwiththeuniforminterfaceconstraintscanmakeuseofhyperme-diadesigntosupporttheinteractionwithclientsfollowingtheTry-Cancel/Conrmpattern.Intheexamples,clientsinitializethestateofareservationwithastandardPOSTrequest,whichreturnsaURIidentifyingtheresourcethathasbeeninitialized.ClientscanusethisURItoconrmthereservation(withPUT)ortocancelit(withDELETE).Additionally,thestateofthenewlycreatedresourceshouldbediscardedifaconrmationisnotreceivedbytheservicewithinagiventimeout(thedurationofwhichcanbediscoveredbytheclientwithaGETrequestonthesamehyperlink).Apossiblesuccessfulrunoftheprotocolguaranteeingtheatom-icityofmultipleHTTPinteractionscouldbesummarizedasfol-lows:1.)GETswiss.com/flight/LX101/seat(2001.)GETeasyjet.com/flight/EZ999/seat(2002.)POSTswiss.com/booking(302Location:/booking/A 2.)POSTeasyjet.com/booking(302Location:/booking/B3a.)PUTswiss.com/booking/A(2043a.)PUTeasyjet.com/booking/B(204Thefollowingshowsafailedrunofthecomposition,wheretheprotocolswillperformthecancellationofthesuccessfullycom-pletedstatetransitions:1.)GETswiss.com/flight/LX101/seat(2002.)POSTswiss.com/booking(302Location:/booking/A1.)GETeasyjet.com/flight/EZ999/seat(204(Noseatavailable)3b.)DELEteswiss.com/booking/A(2005.DETAILEDPROTOCOLDESIGNThesectionproposesanincrementalpresentationofourdesigndecisions,motivationsandtrade-offs,basedonastory-basedap-proach.Whereverpossible,wehavekepttheresponsebodytoaminimum(merely204status)inordertoavoidtheneedforden-ingad-hocrepresentationmediatypesthatintroducemorecouplingthannecessary[17].5.1TheBasics:CancelvsConrmOneofthepropertiesofclassicaltransactionsistheguaranteethateverychangeistemporary(subjectto'rollback')untiltheappli-cationexplicitlyindicatesthateverythingisdoneandcanbesaved('commit').ForREST,wethinkthesameshouldbepossible.How-ever,thereisnoclassical'rollback'becauseweuseserviceinvoca-tionsratherthandatabasesandtheirlockingmechanismtoachievethis.InTCC,thenotionof'rollback'isreplacedby'cancel'.Like-wise,thenotionof'commit'isreplacedby'conrm'.5.1.1CancelAsanapplicationdeveloper,incaseoffailures,Iwanttorevertchangesacrossmultiple,separateparticipants.Forsimplicity(andjustlikeinclassicaltransactionsystems),wehavechosenthecancellationmechanismtobeimplicitandinternaltoeachparticipantservice:aftersometime-out,eachparticipantwill/shouldcancel(revert)itonitsown.Thisway,withoutfurthernotications,eachparticipantservicewilleventuallycancelandtheglobaltransactionwillbecancelledbydefault.Thisgreatlysimpli-esthefailuresemanticsacrossmultipleparticipantservices.Notethatournotionofcancellingdoesnotprecludeanyapplication-specicrecoverymechanisms.Forinstance,ane-commerceweb-siteprobablyallowsreservationstobemadewithaPOSTrequest.Ifthereplygetslost,theusermightstillbeabletoverifyifthereservationwasdone(e.g.,viaaGETtosomeshoppingbasketorequivalentresourcerepresentingthesessionstate)andcontinuefromthere.Wemerelyoffertheextraoptionofcancellingasalastresort.5.1.2ConrmAsanapplicationdeveloper,IwanttoconrmassoonasIamdonesothatnoparticipantwillcancelafterwardsIfbydefaulteverythingwillbecancelled,thereneedstobeawaytoperformotherwise.InTCC,thisisdoneviaanexplicit'conrm'requestontheparticipantservice(s)involved.InordertodothiswithREST,theminimalrequirementisaURIaddressingtheresourcetobeconrmed.Onlytheparticipantservicecan/shoulddeterminewhatthatURIis-soitneedsawaytocommunicatethisURItowardstheoutsideworld.Withthisinmind,wedesignedthenotionoftheparticipantreservationlink.ThelinkURI(usedtoconrmit)isassociatedwiththeexpiresattributeindicatingwhentheparticipantitselfwillcancelautonomously.Thereisalsosome(xed)meta-dataabouttheprotocolitself,usefultoindicatethesemanticsofthelink(thetcclinkrelation).TheparticipantreservationlinkcouldbeembeddedinaJSONpayloadasshowninthefollowingexample:{"participantLink":{"uri":"http://www.swiss.com/booking/A","expires":"2014-01-11T10:15:54.261+01:00","rel":"tcc",}}Itisuptotheparticipanttonegotiatewiththeclientanappro-priatetimeoutduration.Inthesimplestcase,reservationsareguar-anteedforaxedamountoftime.Itisalsopossibletoconsidercaseswherethetimeoutdependsontheclientprole,oranex-tendedtimeoutmaybegrantedforafee.Sincethisfeatureaffectstheinterfacebetweentheparticipantandtheapplication,wedonotexploreitfurtherinthispaper.Theassumptionofourdesignisthataparticipantreservationlinkisproperlyidentied(hencethetcclinkrelation)sothatcon-rmationcanbedonewiththefollowing:)PUT/booking/AHTTP/1.1Host:www.swiss.comAccept:application/tcc(HTTP/1.1204NoContentAlthoughthisonlyshowshowtoconrmonesingleparticipant,itdoeslaythefoundationforourcompletesolution.5.1.3TimeoutAsaparticipant,Iwanttokeeptheabilitytotime-outandcancelthereservationonmyend.Clientsshouldbeinformedthatconr-mationisnolongerpossible.Conrmationrequestsmightcometoolate,i.e.afterthepartici-pantalreadytimedoutandcancelledonitsown.Thisviolatestheintentionofconrmationandthereforeshouldbecommunicatedtothecaller.Theparticipantdoesthisasfollows:)PUT/booking/AHTTP/1.1Host:www.swiss.comAccept:application/tcc(HTTP/1.1404NotFound5.2ReusingTheHardBits:CoordinatorWithnothingmorebutthebasics,distributedtransactionsarepossibleiftheyaremanagedbytheapplicationdeveloper(muchliketheXAprotocolenablesACIDtransactions).However,thisiserror-proneanddifculttomanage,becauseconcernslikerecov-eryandfailurehandlingneedtobetakenintoaccount.Also,itisimportanttoavoidconrmationattemptsafteroneormoretime-outshavehappened,sincethismayleadtoconictingoutcomesoftheglobaltransaction.Allthisisspecializedlogicthatishardtobuildonyourown.JustlikeACIDtransactionsrelyonatransac-tionmanagertomanagetheXAintricacies,weintroduceasimilarcomponentsharingthesameresponsibilities.5.2.1TransactionCoordinatorAsanapplicationdeveloper,Iwanttoreuseexistingconrma-tionlogicsothatIdon'thavetodealwithfailurerecoveryonmyown Iftheconrmationlogicisofferedasareusablecomponent(the'coordinator')thenmanyconcernsnolongerneedtobedealtwithbytheapplicationdeveloper.Also,theerrorscenariosthataremostdifculttotestareabstractedawayintoareusableandtestedcom-ponentthatcanbetrusted.Forthesereasons,wedevelopedatrans-actioncoordinatorcomponent.Moreover,thiscomponentcanalsobedeliveredasaservice-asexplainednextandshowninFigure1.5.2.2TransactionsasaServiceAsanapplicationdeveloper,IwantthecoordinatortobeaREST-fulservicesoIcanaccessitanywhere,anytimeWhatbetterwaytomakeacomponentavailabletoaRESTap-plicationthanbyexposingitasaRESTfulserviceitself?Therearemanyadvantages,someofthembeing:IntegrationintoRESTapplicationsis,bydenition,easyandnaturalsincenoothertechnicaldependenciesthanRESTitselfareintroduced.Theservicecanbemadeavailabletoanydevice,anywhere,anytime.Theservicecanbedeployedonareliableenvironment,withgoodconnectivitytotheparticipants,whilekeepingtherestoftheapplicationsclosertotheirusers(e.g.,onmobiledevices).ThankstothesimplicityofRESTandsincenoHTTPexten-sionsarerequired,theinteroperabilityofthetransactioncoordina-torwithbothapplicationsandparticipantservicesismucheasiertoachieve.5.2.3ConrmationTheapplicationdevelopernowneedsawaytoinvokethecoordi-natorservicetoperformtheconrmationphase.Wechosethefollowingverysimpleapproach,whereasetofreservationlinksissimplytransferredtothecoordinatorservicewithanidempotentPUTrequestcarryinga'transaction'payloadintherequestbody.TheexampleshowstheuseofplainJSON[1],butanycollectionmediatypethatcancarryasetoflinksassociatedwithasetoftimestampscando.)PUT/coordinator/confirmHTTP/1.1Host:www.taas.comContent-Type:application/tcc+jsonContent-Length:253{"transaction":[{"uri":"http://www.swiss.com/booking/A","expires":"2014-01-11T10:15:54.261+01:00"},{"uri":"http://www.easyjet.com/booking/B","expires":"2014-01-11T10:15:54.261+01:00"}]}Thecoordinatorwilldelegatetheconrmationrequesttoallpar-ticipant(link)sincludedinthesuppliedtransaction.Ifallgoesnethenthefollowingwouldbethetypicalresponse:(HTTP/1.1204NoContentForsimplicity,wedidnotattemptatransactionresourcedesign:thereisnoseparateresourcethatidentiesthetransaction.Shouldthisbenecessaryandrequiredthenwecanalwaysadditlater.Fornow,allthatmatterstousisvalidatingtheconceptoftransactionsforRESTwithaworkingbutminimalimplementation.5.2.4FailedConrmationAsanapplicationdeveloper,Iwanttoknowwhenthecoordina-torfailedtoconrm. BookingProcess 1. bookTrip 1.1 R1 = /booking/A 1.2 R2 = /booking/B 1.3 PUT /confirm 1.3.1 PUT R11.3.2 PUT R2 Figure1:TransactionCoordinatordeliveredasaservice.Whenthecoordinatorfailstoenforcetheconrmation,weneedawaytocommunicatetheproblembacktotheapplication.Therearetwoclassesofproblemsthatarerelevant:1.Problemswheretheoverallatomicityguaranteeshavebeenpreserved:thishappensifALLparticipantshavetimedoutorhavebeencanceledbythetimeconrmationstarts.2.Everythingelse:thisiswheretheoveralltransactionguaran-teesmightnothavebeenpreserved.Thishappensifsomepartici-pantstimedoutwhileothersconrmed,orifsomeparticipantshavebecomeunreachable.Thecorrespondingsolutionsarelikethis:1.Ifeveryparticipanttimedoutandcancelled:thisisindicatedbya'404NotFound'erroronbehalfofthecoordinator.Itsignalsthat,althoughconrmationwasdesired,cancellationhap-penedinstead.Whilethismaynotbedesirable,itdoesstilladheretotheatomictransactionalsemanticsofall-or-nothing.2.Everythingelse:tosignalconditionslikethese,thecoordi-natorusesa'409Conflict'statuscodeandcanreturnade-tailedlog,showingwhichofthegivenreservationlinkscouldbeconrmedandwhichcouldnotbeconrmed.Notethatitisthere-sponsibilityofthecoordinatortominimizethenumberoffailuresinthisclass.5.3Recovery5.3.1IdempotentConrmation(attheParticipant)Asacoordinator,IwantconrmationoftheparticipanttobeidempotentsoIcanretryconrmationafterafailureorcrash.ThisisoneofthemainreasonswhywechosetousePUTforconrmation.Withthegivendesignoftheparticipantsofar,weneednoextrachangestosupportthis.Allthecoordinatorneedstodoislogtheparticipantlinksofongoingtransactionsintheconrmationphase.Recoveryisneededintwotypicalcases:1.Thecoordinatoritselfcrashes:onceitcomesbackup,itre-triestheremainingparticipantlinksforwhichitwasconrmingthetransaction.2.Anyparticipantcrashes,or(theequivalent)becomesunreach-ableduetonetworkerrors:thecoordinatorsimplyretriesconrmrequests.5.3.2IdempotentConrmation(attheCoordinator)Asanapplicationdeveloper,Iwantconrmationbythecoordi-natortobeidempotentsoIcanretryconrmationafterafailureorcrash. Imaginethattheapplicationsucceedsatdoingallthework,atallparticipantserviceprovidersinvolved.Atthattimeitwouldrequestthecoordinatortoconrm.Iftherearecrashesornetworkfailuresthentheresponseoftheconrmrequestmightgetlost;thiswouldleavetheapplicationindoubtabouttheoutcomeofthetransaction.AccordingtotheRESTstatelessnessconstraint,oncethecoor-dinatorcompletestheconrmrequest,itshouldforgetaboutit,sotheapplicationshouldholditsownstateandshouldstillrememberthesetofparticipantsinvolved.Consequently,itcan(andshould)retryconrmrequestswhenneeded.ThisiswhywechosetousePUTalsoforthecoordinator'sconrmrequests.Thecoordinatorwillreturnthesameresponsetosubsequentconrmationrequestsinvolvingthesameparticipants.5.4OptimizationsThebasicprotocolcanbeoptimizedabitforbetterresourceus-age.Indeed,ifthereareanyapplication-levelerrorsthenitseemsinefcienttosimplyletparticipantsholdontotherequiredbusinessresourcesuntiltheytimeoutbythemselves.Sohere,wepresentsomeoptimizations.5.4.1ParticipantCancellationAsaparticipantprovider,IwouldliketobenotiedasearlyaspossiblewhenthereisaneedtocancelTheparticipantserviceislikelytoreservevaluablebusinessre-sourcesforthedurationofthetransaction.Shouldtherebeaneedtocancelthenitisverylikelythattheparticipantservicewantstoknowaboutthiswellbeforeittimesout.Again,sincewearetalkingaboutREST,theminimumrequirementisaURItofollowfornotifyingtheparticipant.Forsimplicity,wedidnotwanttoin-troduceanadditionalURI.Rather,weassumethatthesameURIrepresentingthereservationresourcethatisusedforconrmationcanoptionallyalsobeusedforcancellationasfollows:)DELETE/booking/AHTTP/1.1Host:www.swiss.comAccept:application/tcc(HTTP/1.1204NoContentNotethattheactualresponsedoesnotreallymattersincethecancellationrequestismerelyacourtesycallonbehalfoftheap-plication(developer).Initsabsence,theparticipantwouldcancelautonomouslyanyway.Thecapabilitytocancelaparticipantexplicitlyisreallyoptionalinourdesign:anyparticipantcanchoosetoignoreit.Ifapartici-pantproviderdoesnotsupportcancellationbytheapplicationthenanyDELETErequestwouldsimplyproduce:(HTTP/1.1405MethodNotAllowedThisdoesnotaffectoverallcorrectnessofthestate,sincethepar-ticipantwilltimeoutandcancelautonomouslyanyway.Thus,theconsistencyofthedistributedtransactioniseventuallypreserved.5.4.2CoordinatorCancellationAsanapplicationdeveloper,IwanttodelegatethecancellationlogictothecoordinatorsoIdon'thavetocancelthoseparticipantprovidersmyself.Thefollowingexampleshowshowtheapplicationcancancelalltheparticipantsinvolved:)PUT/coordinator/cancelHTTP/1.1Host:www.taas.comContent-Type:application/tcc+jsonContent-Length:253{"transaction":[{"uri":"http://www.swiss.com/booking/A","expires":"2014-01-11T10:15:54.261+01:00"},{"uri":"http://www.easyjet.com/booking/B","expires":"2014-01-11T10:15:54.261+01:00"}]}5.4.3FailedParticipantCancellationAsacoordinator,Idon'tcareifcancellationfailsonthepartici-pantThecoordinatornotiestheparticipantofcancellation,butig-norestheresult.Thismakesperfectsense,becausecancellationisdrivenbytheparticipantprovider'sneedstoreleasereservedre-sourceasearlyaspossible.Ineffect,cancellationismerelyano-ticationoutofcourtesy.Thereareanumberofdifferentreasonsthatsupportthisdecision:1.Sinceexplicitcancellationofaparticipantisreallyanop-tionaloperation,someparticipantsmayreturna405erroriftheydonotsupportthisoperation.2.Sincetheparticipantmayhavetimedoutbeforethecoordina-torrequestsanexplicitcancellationonit,itmayreturna404error.3.TheparticipantURIdoesnotreallyexistforsomereason.Inallthesecases,theoveralltransactioniscancelledeverywhere(sincenoparticipantiseverconrmed).Hence,alltheseerrorscanbesafelyignoredbythecoordinator-makingtheprotocolmorecomfortabletousebecauseapplicationdevelopersneedtoworrylessabouterrorhandling.5.4.4FailedCoordinatorCancellationAsanapplicationdeveloper,Idon'tcareifcancellationfailsonthecoordinatorForthesamereasons,thecoordinatordoesnotreturnanyerrorsuponcancellation;instead,italwaysreturn204(includingcaseswheresomeparticipantURIdoesnotexist).Corollary:cancellationbythecoordinatorisidempotentThisfollowsfromthepreviousdiscussion:failedcancellationsatbothparticipantsandthecoordinatorcanbeignored.HencewedecidedtousethePUTmethodforthecoordinator'scancellationinterface:itisidempotentandallowsrequestbodycontent(unlikeDELETE).5.5MIMETypes5.5.1Participant:application/tccTheparticipantinteractionsrequirenorequestpayload,nordotheyreturnanyresponsepayload.SowechosethisMIMEtypepurelyforindicatingthesemanticsofconrm/cancelexpectedbytheclient.Wedeliberatelyomittedanypayloadfromtheparticipantinteractions,soimplementationscanbeassimpleaspossiblewithminimalinteroperabilityrisks.ThereisnoneedfortheparticipanttosupportanythinglikeXMLorJSONforthatmatter.5.5.2Coordinator:application/tcc+jsonJSONseemedthebestoptiontomakethecoordinatoraccessibletothelargestrangeofapplications.Asweimplycustomsemanticswithsomeoftheattributes,thisisreectedintheMIMEtype.6.PARTICIPANTAPIHerewesummarizetheactualRESTfulAPIfromthepartici-pantperspective.Becauseparticipantinstancesareimplemented bythird-partyproviders,interoperabilitycanonlybeachievedwithaminimalistic,simpleandcleardesign.6.1ParticipantResponsibilitiesTheparticipantmanagestheprovider-specicstateofareserva-tionofbusinessresources.Bydefaultthereservationtimesoutafterawhile,unlessitisconrmedbytheapplication(coordinator).6.2Required:time-outandcancelEveryparticipantimplementationMUSTcancelautonomouslyaftersomeinternaltimeout.Moreprecisely:nothingispermanentuntiltheparticipantreceivesconrmation.6.3Required:participantlinkEveryparticipantimplementationMUSTreturnparticipantlinkinstancesforaninvocationthatcanbeconrmedonitsend.TheselinkscontainmetadatasuchastheURItoinvoke(forconrmation),theexpirationdate/timewhentheparticipantwillcancelonitsown,andotherinformationrelatedtotheprotocolversionandsemantics.Asanexample,participantlinksareofthefollowingform:{"participantLink":{"uri":"http://www.example.com/part/123","expires":"2014-01-11T10:15:54.261+01:00","rel":"tcc"}}Theexchangeofparticipantlinksisbetweentheparticipantandtheapplication,outsidethecontextoftheTCCprotocol.AlthoughourexamplesuggestsJSON,thereisnorealrequirementonthedataformatofthisexchange:thisisentirelybetweenthepartic-ipantproviderandtheapplicationdevelopertoagreeon.Otherapproaches,suchasLinkheaders[22]canbeused.6.4Required:PUTtoconrmTheURIindicatedintheparticipantlinkinstancesMUSTsup-portthePUToperationinordertoconrm:)PUT/part/123HTTP/1.1Host:www.example.comAccept:application/tcc(HTTP/1.1204NoContentNotetheMIMEtypeoftherequest,indicatingtheexpectationsoftheclientaboutthesemanticsimpliedbytheTCCprotocol.Iftheconrmationrequestarrivesaftertheparticipanthasal-readytimedoutandcancelledonitsownthentheparticipantMUSTreturna404error:)PUT/part/123HTTP/1.1Host:www.example.comAccept:application/tcc(HTTP/1.1404NotFoundAnyothererrorswilltriggerrecoverylogicinthecoordinatorservice(typicallyintheformofretriesuntilitgivesup).6.5Optional:DELETEtocancelEachparticipantURIMAYoptionallyimplementDELETEtoreceiveexplicitrequeststocancel:)DELETE/part/123HTTP/1.1Host:www.example.comAccept:application/tcc(HTTP/1.1204NoContentAnyerrorsduringcancelcanbeignoredanddonotaffecttheoveralltransactionoutcome.Incaseofanintermediate(internal)timeout/cancelbythepartic-ipantitself,itisOKtoreturn404:)DELETE/part/123HTTP/1.1Host:www.example.comAccept:application/tcc(HTTP/1.1404NotFoundSinceDELETEisreallyanoptionaloperation,someparticipantsmaychoosenottoimplementit.Inthatcase:)DELETE/part/123HTTP/1.1Host:www.example.comAccept:application/tcc(HTTP/1.1405MethodNotAllowedThisisperfectlyneinouroveralldesign.Anyothers(suchas,butnotlimitedto,theMIMEtypenotbeingunderstood)arealsonehere.6.6Optional:GETforfailurediagnosticsTheparticipantservicemayimplementGETtoallowforfailurediagnostics.In-linewithourintentofbeingminimalistic,diagnos-ticfeaturesare(currently)outsidethescopeofourprotocolitselfandlefttotheapplicationdesigners,sotheycanbetunedonaper-casebasis.7.COORDINATORAPIThecoordinatorserviceisimplementedbyusandusedbyappli-cationdevelopers.Therefore,wepresentthecoordinatorprotocolfromthepoint-of-viewofaclientoftheRESTfulinterfaceasop-posedtodiscusstheimplementationinternalsofthecoordinator.7.1CoordinatorResponsibilitiesThecoordinator'scoreresponsibilitiesarethefollowing:1.Conrmallparticipantswhenaskedtodoso.2.Recoverafterfailuresofparticipantinstancesorthecoordina-toritself,inparticularduringtheconrmationphase.3.Intelligentlyusethesuppliedexpirationdate/timeinforma-tiontominimizethenumberofheuristictransactionoutcomes.4.Determinetherighterroronproblematicoutcomesofconr-mation.5.Nicetohave:allowcancellationofallparticipants.7.2PUTtoconrmUsePUTtoconrmatransactionwiththecoordinatorservice.Atransactionisreallyonlyacollectionofparticipantlinks:)PUT/coordinator/confirmHTTP/1.1Host:www.taas.comContent-Type:application/tcc+jsonContent-Length:425{"transaction":[{"uri":"http://www.example.com/part/123","expires":"2014-01-11T10:15:54.261+01:00"},{"uri":"http://www.example.com/part/234","expires":"2014-01-11T10:15:54.261+01:00"}]}Ifallgoeswellthentheresultwouldbe:(HTTP/1.1204NoContentIftherequesttoconrmarrivestoolate-meaningallparticipantshavetimedoutandcancelledalready,then: (HTTP/1.1404NotFoundTheworstthatcanhappenisamixedoutcomewheresomepar-ticipantsconrmed,whereasothersdidnot.Thisisindicatedasfollows:(HTTP/1.1409ConflictOfcourse,theideaistominimizethenumberofcaseswherethishappens-whichisoneimportantpartofthecoordinator'sresponsi-bilities.Ifandwhenthishappens,though,itisuptotheapplicationtoinspecttheaffectedparticipants-possiblyviaaGETrequesttoeachparticipantURI.7.3PUTtocancelAcancellationrequestissimilartoconrmation,exceptfortheURIonwhichthecoordinatorislistening:)PUT/coordinator/cancelHTTP/1.1Host:www.taas.comContent-Type:application/tcc+jsonContent-Length:425{"transaction":[{"uri":"http://www.example.com/part/123","expires":"2014-01-11T10:15:54.261+01:00"},{"uri":"http://www.example.com/part/234","expires":"2014-01-11T10:15:54.261+01:00"}]}Theonlyforeseenresultis:(HTTP/1.1204NoContentAnyotheroutcomecanbesafelyignoredsincebydenitionnoparticipanthasbeenconrmed,meaningeventuallyallworkwillbecancelledeverywhere.8.DISCUSSIONWehavepresentedaminimalisticprotocolthatoffersthebasicsofatomicityguaranteesfortransactionsspanningacrossmultipleRESTfulWebservices.Thissectionprovidesanoverviewofde-signissuesthatarestillopentofurtherrenementanddiscussion.8.1Application-LevelErrors:CancelafterConrmForsimplicity,thecoordinatordoesnotchecknorprohibitthecasewheretheapplicationrstconrmsatransactionandthenlatercancelsthesametransaction-forwhateverreason.Wecon-siderthistobebadbehaviorontheaccountoftheapplication,butcheckingforitwouldmeanintroducingnewerrorcodesonboththeparticipantsideandthecoordinatorside.We'vetriedthat,andasaresultwecouldnolongertoleratethecancellationofunknownpar-ticipants,norcouldwetolerateothertypesofparticipantfailures.Theresultingaddedcomplexityseemedtoohightojustifythecor-respondinggainssowe'vechosennottorejectsuchsequenceofrequests.Itisthustheresponsabilityoftheapplicationdevelopertoavoidthatconrmedtransactionsarethencancelledatalaterpointintime.8.2SecurityWedidnotconsidersecuritybecausewethoughtitisanorthogo-nalmattertypicallydealtwithbyHTTPS.Nevertheless,theremaybeargumentsinfavorofmorenon-trivialsolutionssuchasURIsigning,OAuthandthelike.Likewise,weassumethatthepartic-ipantreservationURIsarepublicURIsthatcanbeforwardedbytheapplicationtothecoordinator.ThisiscommonbehaviorontheopenWeb,wherelinksaremeanttobeshared.However,ifthepar-ticipantwillonlyallowtheoriginalclientapplicationtofollowthereservationlink,thenadditionalworkisneededfortheapplicationtodelegatetrusttothecoordinatorsothatalsothisothercompo-nentisallowedtofollowthelinktotheparticipant.Weconsiderthisissuetobepartoffuturework,basedonthefeedbackwegetfromthisrstimplementation.8.3TransactionResourceModelSofar,atransactiononlyexistsexplicitlyastherequestbodyofastatelessconrm/cancelrequesttowardsthecoordinator.ThereisnoRESTfulresourceforityet.Fornow,thisminimalisticdesignshouldbeenoughtogetusthenecessaryfeedbackconcerningthefeasibilityanddesirabilityofourapproach.Applicationsshouldbeabletobuildaresource-fulmodelontopofthis,andlaterversionsofourAPIshouldbeabletoincorporatesuchadditions.8.4IANAStandardizationSofar,wedidnotachievestandardizationatIANAforourneu-tralMIMEtypesorlinkrelationshipsbecausewehaven'tfoundthestandardsorganizationthatneedstoparticipateinthat.WefeelliketheMIMEtypesinvolvedshouldnotbevendor-specic(i.e.,inthevnd.*namespace)becausewestressinteroperability.However,thatleavestheopenquestionofhowtoavoidcollisionsinthenamingoftheMIMEtypesandthetcclinkrelationship.8.5DiscoveryofCoordinatorAPIClientsofthecoordinatorsdonotneedtoincludehard-codedref-erencestotheconrmandcancelURIsofthecoordinatorservice.Instead,hypermediacanbeusedtoletthemdiscovertheactualURIswithaGETrequestonthecoordinatorrootURI.HyperlinkswillbereturnedreferringtotheconrmationURI(withalinkre-lationshiprel="confirm")andtothecancellationURI(withalinkrelationshiprel="cancel").ThestandardizationoftheselinkrelationshipswithIANAiscurrentlypending.9.RELATEDWORKRESTiswidelyperceivedasanestablishedlightweighttechnol-ogyforbuildingWebservices[20]andWebAPIs[19].Theprop-ertiesoftheRESTarchitecturalstylearemeanttoenableserendip-itousreusebymeansofcomposition[23].TheideaofRESTfulservicecompositionhasalsobeenexploredintheBiteproject[2,21],orwiththeBPELforRESTextensions[15].Allofthesecontributionstodonotexplicitlyaddresstherequire-mentfortransactionalcompositionofRESTfulservices.Inadditiontoseveralthreadsontherest-discussmailinglist,summarizedby[8],theproblemoftransactionalinteractionsforRESTfulserviceshasstartedtoattractsomeinterestalsointhere-searchcommunity.ArecentsurveyofRESTfultransactionmodelshasbeenpublishedhere[12].Forexample,[18]proposedanap-proachtoRESTfultransactionsbasedonisolationtheorems.TheRETRO[11]transactionmodelalsocomplieswiththeRESTar-chitecturalstyle.TheTimestamp-basedTwoPhaseCommitPro-tocolforRESTfulServices(TS2PC4RS)algorithmwasoriginallypresentedin[3]andextendedtodealwithfaulttolerancein[9].Ourapproachshareswith2PCthechallengeofachievingadis-tributedagreement,howeverwebuilduponthenotionofreserva-tionwhichtsdirectlyintothebusinessmodeloftheparticipantserviceprovideranddoesnotrequireparticipantstodealwithlow-leveldetailsofrunning2PCprotocolrounds. InthispaperwepresentedaRESTfuldesignbasedonapply-ingtheTry-Cancel/ConrmpatterntothedesignofaRESTfulser-vice.Thepatterntswiththebusinessrequirementsofmanyser-viceprovidersthatneedtoparticipatewithinlongrunningtransac-tionsthatdonotrequireisolation.Thus,theyofferservicesallow-ingclientstoissuerequeststriggeringstatetransitions(orresourcereservations)whichcanlaterbecanceledandhavetobeconrmedwithinagiventimewindow.Thesebasicassumptionscouldbeweakened.Forinstance,itmightbethatsomeserviceprovidersdonotholdreservations.Like-wise,itmightbethatsomerequestscannotfailundernormalcir-cumstances(likeread-onlyGETrequests).Furtherresearchalongtheselines,willhelptowidentheapplicabilityoftransactionsoverRESTfulAPIswhichdonotfullycomplywiththeTry-Cancel/Conrmpattern.Aninformalproofoftheprotocoluponwhichthedesignpre-sentedinthispaperisbasedwasoriginallypublishedin[14].Thispaperaddstheconceptofhavingthetransactioncoordinatordeliv-eredasaserviceandpresentsadetailedRESTfuldesignforitsin-terfaceandasystematicdiscussionofitsmainusecases,includingrecoveryscenarios.AbrowserextensionthatcaninterceptparticipantreservationURIsastheusernavigatesbetweendifferentsiteshasbeenpre-sentedin[16].Thebrowserextensionmakesuseofanembed-dedimplementationofthecoordinatortoatomicallyconrmadis-tributedtransactionimplicitlyrecordedbytrackingthenavigationactivitiesofthebrowser.UsingtheAPIdesignpresentedinthispaper,itbecomespossibletooff-loadtheconrmationtothecoor-dinatordeliveredasaservice.10.CONCLUSIONSInthispaperwehavegivenadetailedpresentationofasimpleRESTfuldesignforachievingatomicityindistributedtransactionsinvolvingmultiple,separateWebresourcesthatcomplywiththeTry-Cancel/Conrm(TCC)pattern.Therearecurrentlytwoknownimplementationsofthedesign(oneinJavabyATOMIKOS2andanotherinJavaScriptbytheUniversityofLugano).Sinceoursolu-tiondoesnotrequireanyHTTPprotocolextension,butcanbeseenmorelikeapattern,oradesignbestpractice,wedonotthinkitcanbestandardizedperse.However,thedesignpresentedinthispapercouldgrowtobecomethestandardinterfaceofaRESTfultrans-actioncoordinatordeliveredasaservice.Toachievethis,weplantosubmittheMIMEtypesandLinkrelationtoIANA.Likewise,itwouldbebenecialtoprovidescaffoldinginseverallanguagesandframeworkstomakeiteasiertosupporttheTCCpatternwhenbuildingwell-behavedparticipants.Aspreviouslymentioned,fu-tureworkalsoinvolvesdealingwithsecurityissuesandextendingthecoordinatorAPItosupportpersistingtransactionsasresourcesinadditiontothecurrentstatelessapproach.Whiletherearealreadymanyexamplesofe-commerceWebsitesthatprovideuserswiththeabilitytoreserveitemsforagiventime,weexpectsimilarfunctionalitytobepushedinthecorrespondingWebAPIs,whichwillthenrequireanagreeduponmechanismforadvertisingthepresenceofparticipantlinkswithinresponsepay-loads.Thiswillbecriticaltoachieveadoptionofourapproach,sothatatomiccompositionsofRESTfulservicescanworkontheWorldWideWeb. 2http://www.atomikos.com/Main/ForServiceOrientedArchitectures11.REFERENCES[1]D.Crockford.JSON:Thefat-freealternativetoXML.InProc.ofXML2006,Boston,USA,December2006.http://www.json.org/fatfree.html.[2]F.Curbera,M.Duftler,R.Khalaf,andD.Lovell.Bite:Workowcompositionfortheweb.InProc.ofthe5thInternationalConferenceonService-OrientedComputing(ICSOC2007),Vienna,Austria,2007.[3]L.A.H.daSilvaMacielandC.M.Hirata.Atimestamp-basedtwophasecommitprotocolforWebservicesusingRESTarchitecturalstyle.JournalofWebEngineering,9(3):266282,2010.[4]R.Fielding.ArchitecturalStylesandTheDesignofNetwork-basedSoftwareArchitectures.PhDthesis,UniversityofCalifornia,Irvine,2000.[5]M.Fowler.PatternsofEnterpriseApplicationArchitecture.Addison-Wesley,November2002.[6]Y.Y.Goland,E.J.Whitehead,A.Faizi,S.Carter,andD.Jensen.HTTPextensionsfordistributedauthoringWebDAV.InternetRFC2518,Feb.1999.[7]J.Gray.Thetransactionconcept:Virtuesandlimitations(invitedpaper).InProc.oftheSeventhInternationalConferenceonVeryLargeDataBases,VLDB'81,pages144154.VLDBEndowment,1981.[8]M.Little.RESTandtransactions?,2009.http://www.infoq.com/news/2009/06/rest-ts.[9]L.A.H.d.S.MacielandC.M.Hirata.Fault-toleranttimestamp-basedtwo-phasecommitprotocolforRESTfulservices.Software:PracticeandExperience,43(12):14591488,2013.[10]T.MargariaandM.Hinchey.SimplicityinIT:Thepowerofless.Computer,46(11):2325,2013.[11]A.Marinos,A.R.Razavi,S.Moschoyiannis,andP.J.Krause.RETRO:AconsistentandrecoverableRESTfultransactionmodel.InICWS2009,pages181188,2009.[12]N.Mihindukulasooriya,M.E.Gutiérrez,andR.G.Castro.SevenchallengesforRESTfultransactionmodels.InProc.ofFifthInternationalWorkshoponRESTfulDesign(WS-REST2014),2014.[13]G.Pardon.Try-Cancel/Conrm:Transactionsfor(Web)Services,2009.http://www.atomikos.com/Publications/TryCancelConfirm.[14]G.PardonandC.Pautasso.TowardsdistributedatomictransactionsoverRESTfulservices.InREST:FromResearchtoPractice,pages507524.Springer,2011.[15]C.Pautasso.BPELforREST.InProc.ofthe7thInternationalConferenceonBusinessProcessManagement(BPM08),Milan,Italy,September2008.[16]C.PautassoandM.Babazadeh.Theatomicwebbrowser.Posteratthe22ndInternationalWorldWideWebConference(WWW2013),pages217218,May2013.[17]C.PautassoandE.Wilde.WhyistheWeblooselycoupled?amulti-facetedmetricforservicedesign.InProc.of18thInternationalWorldWideWebConference(WWW2009),pages911920,2009.[18]A.R.Razavi,A.Marinos,S.Moschoyiannis,andP.J.Krause.RESTfultransactionssupportedbytheisolationtheorems.InICWE'09,pages394409,2009.[19]L.Richardson,M.Amundsen,andS.Ruby.RESTfulWebAPIs.O'Reilly,September2013.[20]L.RichardsonandS.Ruby.RESTfulWebServices.O'Reilly,May2007.[21]F.Rosenberg,F.Curbera,M.J.Duftler,andR.Kahalf.ComposingRESTfulservicesandcollaborativeworkows.IEEEInternetComputing,12(5):2431,September-October2008.[22]T.SteinerandJ.Algermissen.FulllingthehypermediaconstraintviaHTTPOPTIONS,theHTTPvocabularyinRDF,andlinkheaders.InProc.oftheSecondInternationalWorkshoponRESTfulDesign(WS-REST2011),pages1114,2011.[23]S.Vinoski.Serendipitousreuse.IEEEInternetComputing,12(1):8487,2008.