Implementing Web Service Protocols in SOA: WS-Coordination and ...

Implementing Web Service Protocols in SOA: WS-Coordination andWS-BusinessActivityFriedrich H. VogtHamburg University of TechnologyBoris GruschkoHamburg University of TechnologySimon ZambrovskiHamburg University of TechnologyPeter FurnissChoreology Ltd.Alastair GreenChoreology Ltd.AbstractWeb Service protocol standards should be unambiguousand provide a complete description of the allowed behaviorof the protocols’ participants. Implementation of suchprotocols is an error-prone process, firstly because of thelack of precision and completeness of the standards, andsecondly because of erroneous transformation of semanticsfrom the specification to the final implementation. Applyingthe TLA+ paradigm we first consider the protocol onan abstract level. Safety properties taken from real worldscenarios are compared to the facilities of the protocol. Asresult, we identified some limitation of applicability of theWS-BA protocol to abstract application use cases, modelledfrom the real world scenarios. These limitations are anomission of possible activities seen in the real world. Further,WS-C and WS-BA make assumptions about the internalstructures of the participants, violating SOA paradigm.The former error could be detected by the use of formalmethods. The latter can be circumvented by a sophisticatedimplementation strategy. The proposed strategy of implementingWS-Coordination and WS-BusinessActivity allowsnon-intrusive integration of the transactional framework,considering SOA requirements. This paper describes theresults of analysis and some design decisions taken duringthe proof-of-concept implementation of WS-C and WS-BAframeworks.1 IntroductionSOAP[6] based Web Services are seen as a solutionfor some interoperability problems of heterogenous distributedsystems. This fact leads to rapid developmentof large number of protocols using SOAP conventions formessage exchange. Transaction support is an importantproperty of distributed systems. In the area of transactionalWeb Services, several protocols or groups of protocolshave been proposed. One such set consists of the threeprotocols WS-Coordination[2], defining an extensible coordinationframework, WS-AtomicTransactions[3], leveragingWS-Coordination(WS-C) for use with systems awareof ACID properties and finally, WS-BusinessActivities [4],designed for support of long-lived activities. The WS-Cframework can be used with different coordination protocols,including the WS-AT and WS-BA specifications.In this paper we describe our experience with implementingWS-C and WS-BA specifications and focus onguarding correctness of implementation. For this purposewe show how formal methods can help implementing safesystems. We also describe the decisions made during thedesign of proof-of-concept implementation and strategiesadopted to deal with areas not precisely defined in specifications.2 General approachWe separate the development process in four phases: thedefinition, the formal specification, the implementation andthe validation.First we choose the protocol stack according the applicationrequirement. This requirement is stated in safetyproperties. Second we analyse given specifications. Ambiguityor lack of information found in specifications underminesthe confidence level. To give a firm discussionbase we use abstract models of the protocol behaviour.Those models are result of the specification phase. In caseof WS-BusinessActivity and WS-Coordination the protocolstate tables are not clear enough to serve as implementationmodel. Formal specifications are used to clarify issues inquestion. Using TLA+[10] we can check the consistency ofsuch abstract models. This approach was inspired by formalmodelling of WS-AtomicTransactions protocol describedin[8]. Given the possibility to map the state transitions toexchanged messages, the generation of state graph of thesystem provides us with all possible sequences of messages1

generated during an exchange. Because WS-BA only definesthe behavior and message exchange of coordinationprotocols we are only interested in those messages.For the implementation of the protocol we found the formalspecification is a prerequisit for reaching the requiredlevel of confidence. In addition, it is more natural for thedeveloper to handle the abstractions of TLA+ specificationsthan state transition tables. In [9] the consruction of a TLA+specification for the WS-BA protocol is described as effortless,for an expert in the field of formal specifications.The time needed to construct the specification that checkedsafety properties, has been reported to be in the range of twohours.To finally check the behavior of the resulting implementationwe can use the validation approach proposed in [12]checking the message traces. To simplify the properties oftraces to be checked the TLA+ specification can be used asan abstract input.In following we give a short specification overview thendiscuss the ambiguities and areas of omission in the models,describe our proposals and finish the paper with validationapproach followed by a conclusion.3 DefinitionsThe WS-Coordination specification describes three rolesfor the communicating parties. The overview of the definedsystem model can be depicted from Fig. 1. An Initiatorrole is played by the entity aiming for a consensusamong multiple Web Services. The Participant roleis played by an entity offering some service that needsto be coordinated during the interaction. The Coordinatorrole is played by an entity coordinating the communicatingparties to achieve the consensus. The specificationalso introduces the message exchange needed forthe Activation and Registration of the participants. In theActivation phase, the CoordinationContext is acquiredfrom the Coordinator’s Activation Service. TheCoordinationContext, a logical abstraction identifyingthe interaction is also defined in WS-C. It is attached tobusiness messages being exchanged between the communicatingparties, embedded in a SOAP header. In the Registrationphase, the participant Web Service signals its intereston the mutual outcome of the coordinated interaction. Duringthis phase the coordination protocol is negotiated andendpoint addresses of Coordinator’s and Participant’s protocolservices are exchanged, forming a logical connectionbetween Coordinator and Participant. The message flowover this logical connection depends on the coordinationprotocol being used and is not part of WS-C specification.The WS-BusinessActivity specification defines two coordinationprotocols. These are the Business Activity WithCoordinator Completion (BACC) as shown in Fig. 2 andBusiness Activity With Participant Completion (BAPC).BACC and BAPC are two-phase protocols, but differ fromclassic 2PC protocol [1] in the following manner. The firstphase is used for exchange of business messages betweenthe parties. In case of BAPC, the end of the first phaseoccurs when the Completed message is sent from Participantto Coordinator, indicating that the Participant hascompleted processing and stored all data persistently. Thesecond phase is used for confirmation or negation of resultsachieved during the first phase.The BAPC is designed for activities in which the decisionabout transition from the first to the second phase canbe made by the Participant. The BACC is designed for activitiesin which this decision is made by Coordinator.4 Specification AnalysisThe work on the proof-of-concept WS-BA implementationwas preceded by the reading and discussion of thespecification itself. In this section we provide our insightsand comments produced during the internal discussion ofthe specification useful for the understanding of the writtenApp1(Initiator)ActivationServiceRegistrationServiceCoordinatorcreateCoordinationContext()register()App2(Web Service)ParticipantFigure 1. System overview (Specification)Figure 2. BACC2

specification by a team about to implement it.4.1 Application modelsConcerning on formal analysis of the WS-C and WS-BAspecifications using TLA+ paradigm led to review of applicabilityof the protocols to the business scenarios takenfrom the real world. We came to a conclusion that WS-BA can only support ”do-compensate”[7] behavior patternsfor the Participants. In the ”do-compensate” model the confirmedstate is identical to the provisional state. In other patternssuch as ”provisional-final” and ”validate-do” behaviorpatterns[7], the participant establishes a (provisional) ”complete”state of the application data that will be changed tothe confirmed state if and when the Close message is received.The fact that in WS-BA the Closing state has nostate transition to the Faulting state means that no actionon data can be performed while the system is in thatstate. WS-BA permits a transition to the Faulting statefrom the Compensating state since it recognises that anychange of application state can sometimes turn out to beimpossible. Supporting the other patterns by adding theClosing to Faulting state transition would result in awider applicability of WS-BA to natural scenarios, especiallythose where the release of application data in its finalstate will have wider consequences. In terms of serviceorienteddesign the behavior supported by WS-BA coordinationprotocols violate the SOA paradigm, prescribing theinternal behavior of the system. This prescription resultsfrom the negotiation of the coordination protocol, where theparticipant commits himself to an internal behavior patternsupported by the negotiated protocol.4.2 Analysis ResultsWS-Coordination and WS-BusinessActivity are protocolframeworks designed for usage in the SOA environment.Nevertheless the protocol authors made some decisionsabout the internal buildup of communication partiesas described in [5]. The tightly-coupled Coordinator andInitiator as well as Participant encapsulating both businessand transactional logic are examples of that. Our understandingof WS-* protocols as building blocks of distributedsystem led to different view of the system than described in[5]. Specifically our architecture was shaped by considerationof seamless integration of WS-C and WS-BA frameworksin existing WS-Scenarios minimizing the adaptationefforts. For this purpose we introduce the transactionalmiddleware separating the coordination from the businesslogic as shown in Fig. 3. The function of the transactionalmiddleware is the management of the coordination contextand coordination protocol execution. By assuming this assignment,the transactional middleware allows for an easierClient implementation. (The addition of the transactionalmiddleware brings our WS-BA implementation closer tothe architecture described in WS-AtomicTransactions[3],where the WS-AT Completion protocol is analogous to themessage exchanges between the client and the middlewaredescribed below.)4.2.1 Initiation and TerminationThe WS-C specification defines a message flow that has tobe understood by all communication parties. To allow nonintrusiveintegration of WS-C framework with existing WebServices and their clients we introduce mechanisms for enablingand disabling WS-Coordination support on demand.For this purpose the model defined in WS-C specification isextended with a new role called Transactor. The Transactoraccepts four different messages from Initiator that dealwith initiation and termination of coordination support, aswell as lead to the final coordinated outcome of the protocolin use. Transactional support for interactions between WebServices and their clients begins when the Initiator sends aBegin message to Transactor. Similarly, to end the transactionalsupport the End message is sent to Transactor. TheTransactor form the first part of transactional middleware asseen in Fig. 3.App1(Initiator)ProxyClientTransactionServiceProxyServiceTransactorActivationServiceRegistrationServiceCoordinatorMiddlewarecreateCoordinationCtx()register()App2(Web Service)DecisionEngineParticipantFigure 3. System overview(Implementation)4.2.2 Delivery of decisionsIn both WS-BusinessActivity protocols the participantreaches the Completed protocol state. In the BAPC protocol,the Participant reaches this state after it has sent theCoordinator a Completed message. According to theBACC (see Fig. 2) protocol, the Participant reaches thisstate after receiving the Complete message from the Coordinator,and having successfully progressed through theCompleting state. In the Completed state the logic onthe participant side has recorded all its business data and3

expects a decision from the Coordinator about further protocolprogression, which should eventually lead to protocolinstance termination. In general, however, the Coordinatorhas no ability to understand the semantics of the businessmessages being exchanged between the client and theWeb Service. In particular it has no knowledge about thebusiness process flow. This knowledge is only available tothe client acting as Initiator. This means the Coordinatorcannot decide by itself which message to send to the Participantafter the Participant has reached the Completedstate. For this purpose we extend the Transactor by introducingthe ability to transmit a decision of the client to theCoordinator. This decision is business flow dependent andenables the Coordinator to send the appropriate coordinationprotocol message to the Participant. For this to happen,the Transactor can receive two messages from the Initiator,namely a Confirm message, and a Cancel message.This decision indication received by the Transactor is madeavailable to the tightly-coupled Coordinator. Also importantto mention here is that these Confirm and Cancelmessages include the endpoint address of the Web Service(to which the earlier business messages were sent) so thatthe decision by the client can be associated with the particularWeb Service. The transactional middleware consists ofthe Transactor and the Coordinator, which is thus decoupledfrom the Initiator.4.3 Specification Omissions4.3.1 RegistrationThe WS-Coordination specification prescribes that the Participantregister with the Coordinator if it intends to participatein a coordinated business activity. However, theRegister message does not contain enough informationfor the Coordinator to determine which business activitythe Participant wants to take part in. It is possible to resolvethis lack of information in several ways. For example,the Coordinator could provide distinct Registration Serviceendpoint addresses for each business activity. We chose anotherapproach and extended the Register message interactionby adding the missing information in the form ofidentification information of the Participant. We also providethe address of the business Web Service endpoint inthe Register message. Given the possibility of a Participanttaking part in several business activities simultaneously,our extension of the Register response messageallows its assignment to the corresponding businessactivity. The CoordinationContextIdentifier,defined in WS-C specification for identifying the coordinatedinteraction uniquely, has been used as the extensionfor both messages. An example emphRegister messagewith the identifier is shown in Listing 1 in which theCoordinationContextIdentifier is provided inwsu:Identifier element.h t t p : / / schemas . xmlsoap . org / ws / 2 0 0 4 / 0 1/ wsba /BusinessAgreementW i t h P a r t i c i p a n t C o m p l e t i o nh t t p : / / example . org / Requesth t t p : / / example . org / BAPCPorth t t p : / / example . org / ? i d =1h t t p : / / example . org / B u s i n e s s P o r tListing 1. Register Message4.3.2 Coordination Protocols ExtensionBoth the Coordinator and the Participant can hold severalcoordination protocol instances simultaneously. The WS-BusinessActivity specification does not provide enough informationto differentiate between coordination protocol instances.Similar to the case of Register and Registerresponse messages we include the identification elementin the messages to allow the receiving party unique assignmentbetween the coordination messages and correspondingprotocol instances.5 ImplementationThe separation of Coordinator from Initiator has beenenabled by usage of a Proxy System. The Proxy System consistsof two parts: a Proxy Client deployed on the Initiatorside and Proxy Service as a part of proposed transactionalmiddleware. The Proxy Client is realised as a SOAP handlerintercepting the messages, redirecting them to the Proxy4

Service, which is a part of Transactor. The initial creationof CoordinationContext is ensured on the middleware,which augments the rerouted business messages withCoordinationContext of corresponding business activity.Our definition of the Participant differs slightly fromthat described in WS-C specification. We describe onlythe transactional component of the business Web Serviceas the Participant. Since the Participant and the businessWeb Service have different roles, the former being responsiblefor coordination, and the latter for business functionality,it is good design to keep them separate. On the otherhand, coupling between the two roles is required for mutualexchange of information about their internal states, sinceproper progression of coordination depends on these states.There are several approaches for a business Web Service toinform the Participant, or for the Participant to inform thebusiness Web Service about the changes of their respectiveinternal states. Our approach of loose-coupling of the businessWeb Service and the Participant is based solely on theobservation of the in- and outbound communication of thebusiness Web Service. Using Decision engine linked witha SOAP handler intercepting the messages of the businessWeb Service the Participant concludes the change of internalstate of the business Web Service. For this purpose theDecision Engine is equipped with a preconfigured Rule Setconstisting of XQuery[13] predicates. The recorded messagesare written into Trace[12] data structure, which isused as container for Rule Set evaluation. Further discussionof the applicability of the proposed approach and theRule Set is beyond the scope of this paper and is a subjectof further research. The concept of Decision Engineminimizes the effort needed to adapt an existing businessWeb Service for usage with WS-BA to writing of a configurationfile containing the mappings between the coordinationand business expressions. For simulation purposes acommon travel agency scenario has been implemented. Acomplete example interaction depicting the components describedpreviously is shown in Fig. 4.We packaged our WS-BA framework implementation asan J2EE application, that has been deployed in two JBossApplication Servers. Apache Axis 1.2 has been used as WebService toolkit. For the usage of TLA+ language an EclipseIDE plugin has been developed[14].6 Validation of the ImplementationValidation of the implementation of a given protocol providesthe confidence in the correctness of decisions met duringthe implementation process. It is hard to verify an implementationof the presented system. The mathematicalvalidation of the implementation seems unfeasible, due tothe complexity of the matter at hand. Nevertheless, we showClient Middleware ParticipantBusinessmessagescancel()containingbusinessendpointaddressbegin()book()bookResponse()cancel()end()book()register()registerResponse()bookResponse()completed()compensate()compensated()MessagecontainingCoordinationContextbook()bookResponse()cancelBook()cancelBookResponse()Figure 4. Sample interaction scenarioBusinessWebServiceMessagegeneratedby DecisionEnginea way to acquire an assertion about the correctness of theimplementation. To test our implementation we used themethod suggested in [12]. The proposed approach allowsseparation of the implementation details from the testing ofthe overall compliance with the WS-BA specification. TheTraces which are used for the Decision Engine are at thesame time being stored for later evaluation.As proposed in [12] the evaluation of the Traces doesnot prove the definitive compliance of the implementationwith the WS-BA specification. It merely guarantees that nospecification violation has been observed. The validationrelies upon a set of predicates which provide a descriptionof the constraints laid upon the communication by the WS-BA specification.The main effort during the proposed validation is neededto be applied to the creation of the predicates set. This setis specific to the protocol which implementation is to betested. Thus there is no possibility to reuse a created predicatesset for testing the implementation of another protocol.A useful base for the creation of the predicates set is aformal specification of the state transitions of the protocol.From this specification a comprehensive set of predicatescan be derived. Another advantage of using a formal specificationis the avoidance of errors in the predicates set.5

7 ConclusionThe formal analysis of the WS-Coordination and WS-BusinessActivity specifications led to determination of ambigousareas in the described frameworks. The TLA+ paradigmhelped us perform this analysis. During the analysisphase we uncovered a limitation of the specifications interms of applicability to real world scenarios. In our understandingof SOA this limitation violates the black boxapproach to the behaviour of the participants. We acceptedthis limitation for the cause of overall interoperability ofour implementation. Further we discovered a structural dependancybetween introduced entities. This also violatesthe SOA paradigm. This dependancy could be resolved bysophisticated design of the WS-BA framework implementation.The introduction of transactional middleware formsa loosly-coupled transactional system according to WS-Cand WS-BA specifications. To allow for the mapping betweenincoming messages and their corresponding BAs wetook advantage of the extensibility of elements descibedin WS-C and WS-BA specifications. The easy integrationinto existing Web Service scenarios is enabled by the usageof Proxy System and Decision Engine, whose functionalityis described in the Sec. 5 The communication protocoldefined between the Initiator and Transactor is needed toguarantee the loose-coupling of system components. Theinsights gained during the proof-of-concept implementationemphasize our analysis and design decisions. The proof-ofconceptimplementation has been exposed to an extendedvalidation phase using data gathered during the test runs ofan example scenario. The overall experience shows, that theusage of formal methods during an implementation of WebService protocols in SOA helps clarify the protocols underconsideration and raises the confidence of the implementorsinto their understanding of the protocols.References[1] P.A. Bernstein and E. Newcomer. Principles of TransactionProcessing. Morgan Kaufmann Publishers,1997.[2] Luis Felipe Cabrera, George Copeland, William Cox,Max Feingold, Tom Freund, Jim Johnson, Chris Kaler,Johannes Klein, David Langworthy, Anthony Nadalin,David Orchard, Ian Robinson, John Shewchuk, TonyStorey, and Satish Thatte. Web Services CoordinationFramework (WS-Coordination), September 2003.[3] Luis Felipe Cabrera, George Copeland, WilliamCox, Tom Freund, Johannes Klein, David Langworthy,Ian Robinson, Tony Storey, and Satish Thatte.Web Services Atomic Transaction Framework(WS-AtomicTransaction)), Januar 2004.[4] Luis Felipe Cabrera, George Copeland, WilliamCox, Tom Freund, Johannes Klein, David Langworthy,Ian Robinson, Tony Storey, and Satish Thatte.Web Services Business Activity Framework (WS-BusinessActivity), Januar 2004.[5] Luis Felipe Cabrera, George Copeland,Jim Johnson, and David Langworthy. CoordinatingWeb Services Activities withWS-Coordination, WS-AtomicTransaction,and WS-BusinessActivity. Available athttp://msdn.microsoft.com/webservices/default.aspx,January 2004.[6] R. Chinnici, M. Gudgin, J.-J. Moreau, and S. Weerawarana.SOAP Services Description Language(WSDL) 1.2, March 2003. status : W3C WorkingDraft , http://www.w3.org/TR/wsdl12/.[7] Peter Furnis and Alastair Green. Choreology Ltd.Feedback to the authors of WS-Coordination, WS-AtomicTransaction and WS-BusinessActivity. Availableat http://www.choreology.com/downloads/, May2004.[8] James E. Johnson, David E. Langworthy, Leslie Lamport,and Friedrich H. Vogt. Formal specification ofa web services protocol. Electronic Notes in TheoreticalComputer Science, Volume 105, 10 December2004, Pages 147-158, December 2004.[9] James E. Johnson, David E. Langworthy, Leslie Lamport,and Friedrich H. Vogt. Formal specification of aweb services protocol. to appear in Elseview Science,January 2005.[10] Leslie Lamport. Specifying Systems. Addison Wesley,2003.[11] Eric Newcomer and Greg Lomow. UnderstandingSOA with Web Services. Addison Wesley Professional,2004.[12] Marcus Venzke. Specifications using XQuery Expressionson Traces. Mario Bravetti, Gianluigi Zavattaro(Eds.): Proceedings of the First International Workshopon Web Services and Formal Methods, February2004.[13] W3C. XQuery: the W3C query languagefor XML – W3C working draft. Available athttp://www.w3.org/TR/xquery/, 2001.[14] Simon Zambrovski and Boris Gruschko.TLA+ Eclipse IDE Plugin. Available athttp://www.techjava.de/, 2004.6