Implementing Web Service Protocols in SOA:WS-Coordination and
Friedrich H.V ogt Hamburg University of Technology
Simon Zambrovski Hamburg University of Technology
Boris Gruschko Hamburg University of Technology
Web Service protocol standards should be unambiguous and provide a complete description of the allowed behav-ior of the protocols’participants.Implementation of such protocols is an error-prone process,?rstly because of the lack of precision and completeness of the standards,and secondly because of erroneous transformation of semantics from the speci?cation to the?nal implementation.Apply-ing the TLA+paradigm we?rst consider the protocol on an abstract level.Safety properties taken from real world scenarios are compared to the facilities of the protocol.As result,we identi?ed some limitation of applicability of the WS-BA protocol to abstract application use cases,modelled from the real world scenarios.These limitations are an omission of possible activities seen in the real world.Fur-ther,WS-C and WS-BA make assumptions about the inter-nal structures of the participants,violating SOA paradigm. The former error could be detected by the use of formal methods.The latter can be circumvented by a sophisticated implementation strategy.The proposed strategy of imple-menting WS-Coordination and WS-BusinessActivity allows non-intrusive integration of the transactional framework, considering SOA requirements.This paper describes the results of analysis and some design decisions taken during the proof-of-concept implementation of WS-C and WS-BA frameworks.
SOAPbased Web Services are seen as a solution for some interoperability problems of heterogenous dis-tributed systems.This fact leads to rapid development of large number of protocols using SOAP conventions for message exchange.Transaction support is an important property of distributed systems.In the area of transac-tional Web Services,several protocols or groups of proto-
cols have been proposed.One such set consists of the three protocols WS-Coordination,de?ning an extensible coor-dination framework,WS-AtomicTransactions,leverag-ing WS-Coordination(WS-C)for use with systems aware of ACID properties and?nally,WS-BusinessActivities, designed for support of long-lived activities.The WS-C framework can be used with different coordination proto-cols,including the WS-AT and WS-BA speci?cations.
In this paper we describe our experience with imple-menting WS-C and WS-BA speci?cations and focus on guarding correctness of implementation.For this purpose we show how formal methods can help implementing safe systems.We also describe the decisions made during the design of proof-of-concept implementation and strategies adopted to deal with areas not precisely de?ned in speci-?cations.
We separate the development process in four phases:the de?nition,the formal speci?cation,the implementation and the validation.
First we choose the protocol stack according the appli-cation requirement.This requirement is stated in safety properties.Second we analyse given speci?cations.Am-biguity or lack of information found in speci?cations un-dermines the con?dence level.To give a?rm discussion base we use abstract models of the protocol behaviour.
Those models are result of the speci?cation phase.In case of WS-BusinessActivity and WS-Coordination the protocol state tables are not clear enough to serve as implementation model.Formal speci?cations are used to clarify issues in question.Using TLA+we can check the consistency of such abstract models.This approach was inspired by formal modelling of WS-AtomicTransactions protocol described in.Given the possibility to map the state transitions to exchanged messages,the generation of state graph of the system provides us with all possible sequences of messages 1
generated during an exchange.Because WS-BA only de-?nes the behavior and message exchange of coordination protocols we are only interested in those messages.
For the implementation of the protocol we found the for-mal speci?cation is a prerequisit for reaching the required level of con?dence.In addition,it is more natural for the developer to handle the abstractions of TLA+speci?cations than state transition tables.Inthe consruction of a TLA+ speci?cation for the WS-BA protocol is described as ef-fortless,for an expert in the?eld of formal speci?cations. The time needed to construct the speci?cation that checked safety properties,has been reported to be in the range of two hours.
To?nally check the behavior of the resulting implemen-tation we can use the validation approach proposed in checking the message traces.To simplify the properties of traces to be checked the TLA+speci?cation can be used as an abstract input.
In following we give a short speci?cation overview then discuss the ambiguities and areas of omission in the models, describe our proposals and?nish the paper with validation approach followed by a conclusion.
The WS-Coordination speci?cation describes three roles for the communicating parties.The overview of the de-?ned system model can be depicted from Fig. 1.An Ini-tiator role is played by the entity aiming for a consen-sus among multiple Web Services.The Participant role is played by an entity offering some service that needs to be coordinated during the interaction.The Coordina-tor role is played by an entity coordinating the commu-nicating parties to achieve the consensus.The speci?-cation also introduces the message exchange needed for the Activation and Registration of the participants.In the Activation phase,the CoordinationContext is ac-quired from the Coordinator’s Activation Service.The CoordinationContext,a logical abstraction identify-ing the interaction is also de?ned in WS-C.It is attached to business messages being exchanged between the communi-cating parties,embedded in a SOAP header.In the Registra-tion phase,the participant Web Service signals its interest on the mutual outcome of the coordinated interaction.Dur-ing this phase the coordination protocol is negotiated and endpoint addresses of Coordinator’s and Participant’s pro-tocol services are exchanged,forming a logical connection between Coordinator and Participant.The message?ow over this logical connection depends on the coordination protocol being used and is not part of WS-C speci?cation.
The WS-BusinessActivity speci?cation de?nes two co-ordination protocols.These are the Business Activity With Coordinator Completion(BACC)as shown in Fig.2and
Business Activity With Participant Completion(BAPC).
BACC and BAPC are two-phase protocols,but differ from classic2PC protocolin the following manner.The?rst phase is used for exchange of business messages between the parties.In case of BAPC,the end of the?rst phase occurs when the Completed message is sent from Par-ticipant to Coordinator,indicating that the Participant has completed processing and stored all data persistently.The second phase is used for con?rmation or negation of results achieved during the?rst phase.
The BAPC is designed for activities in which the deci-sion about transition from the?rst to the second phase can be made by the Participant.The BACC is designed for ac-tivities in which this decision is made by Coordinator.
The work on the proof-of-concept WS-BA implemen-tation was preceded by the reading and discussion of the speci?cation itself.In this section we provide our insights and comments produced during the internal discussion of the speci?cation useful for the understanding of the written
speci?cation by a team about to implement it.
Concerning on formal analysis of the WS-C and WS-BA speci?cations using TLA+paradigm led to review of ap-plicability of the protocols to the business scenarios taken from the real world.We came to a conclusion that WS-BA can only support”do-compensate”behavior patterns for the Participants.In the”do-compensate”model the con-?rmed state is identical to the provisional state.In other pat-terns such as”provisional-?nal”and”validate-do”behavior patterns,the participant establishes a(provisional)”com-plete”state of the application data that will be changed to the con?rmed state if and when the Close message is re-ceived.The fact that in WS-BA the Closing state has no state transition to the Faulting state means that no ac-tion on data can be performed while the system is in that state.WS-BA permits a transition to the Faulting state from the Compensating state since it recognises that any change of application state can sometimes turn out to be impossible.Supporting the other patterns by adding the Closing to Faulting state transition would result in a wider applicability of WS-BA to natural scenarios,espe-cially those where the release of application data in its?nal state will have wider consequences.In terms of service-oriented design the behavior supported by WS-BA coordi-nation protocols violate the SOA paradigm,prescribing the internal behavior of the system.This prescription results from the negotiation of the coordination protocol,where the participant commits himself to an internal behavior pattern supported by the negotiated protocol.
WS-Coordination and WS-BusinessActivity are proto-col frameworks designed for usage in the SOA environ-ment.Nevertheless the protocol authors made some deci-sions about the internal buildup of communication parties as described in.The tightly-coupled Coordinator and Initiator as well as Participant encapsulating both business and transactional logic are examples of that.Our under-standing of WS-*protocols as building blocks of distributed system led to different view of the system than described in .Speci?cally our architecture was shaped by consider-ation of seamless integration of WS-C and WS-BA frame-works in existing WS-Scenarios minimizing the adaptation efforts.For this purpose we introduce the transactional middleware separating the coordination from the business logic as shown in Fig.3.The function of the transactional middleware is the management of the coordination context and coordination protocol execution.By assuming this as-signment,the transactional middleware allows for an easier
Client implementation.(The addition of the transactional middleware brings our WS-BA implementation closer to the architecture described in WS-AtomicTransactions, where the WS-AT Completion protocol is analogous to the message exchanges between the client and the middleware described below.)
4.2.1Initiation and Termination
The WS-C speci?cation de?nes a message?ow that has to be understood by all communication parties.To allow non-intrusive integration of WS-C framework with existing Web Services and their clients we introduce mechanisms for en-abling and disabling WS-Coordination support on demand.
For this purpose the model de?ned in WS-C speci?cation is extended with a new role called Transactor.The Transac-tor accepts four different messages from Initiator that deal with initiation and termination of coordination support,as well as lead to the?nal coordinated outcome of the protocol in use.Transactional support for interactions between Web Services and their clients begins when the Initiator sends a Begin message to Transactor.Similarly,to end the trans-actional support the End message is sent to Transactor.The Transactor form the?rst part of transactional middleware as seen in Fig.3.
4.2.2Delivery of decisions
In both WS-BusinessActivity protocols the participant reaches the Completed protocol state.In the BAPC pro-tocol,the Participant reaches this state after it has sent the Coordinator a Completed message.According to the BACC(see Fig.2)protocol,the Participant reaches this state after receiving the Complete message from the Co-ordinator,and having successfully progressed through the Completing state.In the Completed state the logic on the participant side has recorded all its business data and 3
expects a decision from the Coordinator about further pro-tocol progression,which should eventually lead to protocol instance termination.In general,however,the Coordina-tor has no ability to understand the semantics of the busi-ness messages being exchanged between the client and the Web Service.In particular it has no knowledge about the business process?ow.This knowledge is only available to the client acting as Initiator.This means the Coordinator cannot decide by itself which message to send to the Par-ticipant after the Participant has reached the Completed state.For this purpose we extend the Transactor by intro-ducing the ability to transmit a decision of the client to the Coordinator.This decision is business?ow dependent and enables the Coordinator to send the appropriate coordina-tion protocol message to the Participant.For this to happen, the Transactor can receive two messages from the Initia-tor,namely a Confirm message,and a Cancel message. This decision indication received by the Transactor is made available to the tightly-coupled Coordinator.Also impor-tant to mention here is that these Confirm and Cancel messages include the endpoint address of the Web Service (to which the earlier business messages were sent)so that the decision by the client can be associated with the partic-ular Web Service.The transactional middleware consists of the Transactor and the Coordinator,which is thus decou-pled from the Initiator.
The WS-Coordination speci?cation prescribes that the Par-ticipant register with the Coordinator if it intends to par-ticipate in a coordinated business activity.However,the Register message does not contain enough information for the Coordinator to determine which business activity the Participant wants to take part in.It is possible to re-solve this lack of information in several ways.For example, the Coordinator could provide distinct Registration Service endpoint addresses for each business activity.We chose an-other approach and extended the Register message in-teraction by adding the missing information in the form of identi?cation information of the Participant.We also pro-vide the address of the business Web Service endpoint in the Register message.Given the possibility of a Par-ticipant taking part in several business activities simultane-ously,our extension of the Register response mes-sage allows its assignment to the corresponding business activity.The CoordinationContextIdentifier, de?ned in WS-C speci?cation for identifying the coordi-nated interaction uniquely,has been used as the exten-sion for both messages.An example emphRegister mes-sage with the identi?er is shown in Listing1in which the CoordinationContextIdentifier is provided in
x m l n s:w s c o o r=”...”xmlns:wsa=”...” xmlns:wsu=”...” > h t t p://schemas.xmlsoap.org/ws/2004/01 /wsba/ B u s i n e s s A g r e e m e n t W i t h P a r t i c i p a n t C o m p l e t i o n
x m l n s:w s c o o r=”...”xmlns:wsa=”...”
h t t p://schemas.xmlsoap.org/ws/2004/01
B u s i n e s s A g r e e m e n t
W i t h P a r t i c i p a n t C o m p l e t i o n
h t t p://example.org/R e q u e s t
h t t p://example.org/BAPCPort
h t t p://example.org/?i d=1
h t t p://example.org/B u s i n e s s P o r t
4.3.2Coordination Protocols Extension
Both the Coordinator and the Participant can hold several coordination protocol instances simultaneously.The WS-BusinessActivity speci?cation does not provide enough in-formation to differentiate between coordination protocol in-stances.Similar to the case of Register and Register response messages we include the identi?cation element in the messages to allow the receiving party unique assign-ment between the coordination messages and corresponding protocol instances.
The separation of Coordinator from Initiator has been enabled by usage of a Proxy System.The Proxy System con-sists of two parts:a Proxy Client deployed on the Initiator side and Proxy Service as a part of proposed transactional middleware.The Proxy Client is realised as a SOAP handler intercepting the messages,redirecting them to the Proxy 4
Service,which is a part of Transactor.The initial creation of CoordinationContext is ensured on the middle-ware,which augments the rerouted business messages with CoordinationContext of corresponding business ac-tivity.
Our de?nition of the Participant differs slightly from that described in WS-C speci?cation.We describe only the transactional component of the business Web Service as the Participant.Since the Participant and the business Web Service have different roles,the former being respon-sible for coordination,and the latter for business function-ality,it is good design to keep them separate.On the other hand,coupling between the two roles is required for mutual exchange of information about their internal states,since proper progression of coordination depends on these states. There are several approaches for a business Web Service to inform the Participant,or for the Participant to inform the business Web Service about the changes of their respective internal states.Our approach of loose-coupling of the busi-ness Web Service and the Participant is based solely on the observation of the in-and outbound communication of the business Web Service.Using Decision engine linked with a SOAP handler intercepting the messages of the business Web Service the Participant concludes the change of inter-nal state of the business Web Service.For this purpose the Decision Engine is equipped with a precon?gured Rule Set constisting of XQuerypredicates.The recorded mes-sages are written into Tracedata structure,which is used as container for Rule Set evaluation.Further discus-sion of the applicability of the proposed approach and the Rule Set is beyond the scope of this paper and is a sub-ject of further research.The concept of Decision Engine minimizes the effort needed to adapt an existing business Web Service for usage with WS-BA to writing of a con?g-uration?le containing the mappings between the coordina-tion and business expressions.For simulation purposes a common travel agency scenario has been implemented.A complete example interaction depicting the components de-scribed previously is shown in Fig.4.
We packaged our WS-BA framework implementation as an J2EE application,that has been deployed in two JBoss Application Servers.Apache Axis1.2has been used as Web Service toolkit.For the usage of TLA+language an Eclipse IDE plugin has been developed.
6Validation of the Implementation
Validation of the implementation of a given protocol pro-vides the con?dence in the correctness of decisions met dur-ing the implementation process.It is hard to verify an im-plementation of the presented system.The mathematical validation of the implementation seems unfeasible,due to the complexity of the matter at hand.Nevertheless,we show
Figure4.Sample interaction scenario
a way to acquire an assertion about the correctness of the
implementation.To test our implementation we used the method suggested in.The proposed approach allows separation of the implementation details from the testing of the overall compliance with the WS-BA speci?cation.The Traces which are used for the Decision Engine are at the same time being stored for later evaluation.
As proposed inthe evaluation of the Traces does not prove the de?nitive compliance of the implementation with the WS-BA speci?cation.It merely guarantees that no speci?cation violation has been observed.The validation relies upon a set of predicates which provide a description of the constraints laid upon the communication by the WS-BA speci?cation.
The main effort during the proposed validation is needed to be applied to the creation of the predicates set.This set is speci?c to the protocol which implementation is to be tested.Thus there is no possibility to reuse a created pred-icates set for testing the implementation of another proto-col.A useful base for the creation of the predicates set is a formal speci?cation of the state transitions of the protocol.
From this speci?cation a comprehensive set of predicates can be derived.Another advantage of using a formal speci-?cation is the avoidance of errors in the predicates set.
The formal analysis of the WS-Coordination and WS-BusinessActivity speci?cations led to determination of am-bigous areas in the described frameworks.The TLA+par-adigm helped us perform this analysis.During the analy-sis phase we uncovered a limitation of the speci?cations in terms of applicability to real world scenarios.In our un-derstanding of SOA this limitation violates the black box approach to the behaviour of the participants.We accepted this limitation for the cause of overall interoperability of our implementation.Further we discovered a structural de-pendancy between introduced entities.This also violates the SOA paradigm.This dependancy could be resolved by sophisticated design of the WS-BA framework implemen-tation.The introduction of transactional middleware forms a loosly-coupled transactional system according to WS-C and WS-BA speci?cations.To allow for the mapping be-tween incoming messages and their corresponding BAs we took advantage of the extensibility of elements descibed in WS-C and WS-BA speci?cations.The easy integration into existing Web Service scenarios is enabled by the usage of Proxy System and Decision Engine,whose functional-ity is described in the Sec.5The communication protocol de?ned between the Initiator and Transactor is needed to guarantee the loose-coupling of system components.The insights gained during the proof-of-concept implementation emphasize our analysis and design decisions.The proof-of-concept implementation has been exposed to an extended validation phase using data gathered during the test runs of an example scenario.The overall experience shows,that the usage of formal methods during an implementation of Web Service protocols in SOA helps clarify the protocols under consideration and raises the con?dence of the implementors into their understanding of the protocols. References
P.A.Bernstein and E.Newcomer.Principles of Trans-
action Processing.Morgan Kaufmann Publishers, 1997.
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,Tony Storey,and Satish Thatte.Web Services Coordination Framework(WS-Coordination),September2003. Luis Felipe Cabrera,George Copeland,William
Cox,Tom Freund,Johannes Klein,David Langwor-thy,Ian Robinson,Tony Storey,and Satish Thatte.
Web Services Atomic Transaction Framework(WS-AtomicTransaction)),Januar2004.
Luis Felipe Cabrera,George Copeland,William
Cox,Tom Freund,Johannes Klein,David Langwor-
thy,Ian Robinson,Tony Storey,and Satish Thatte.
Web Services Business Activity Framework(WS-
Luis Felipe Cabrera,George Copeland,
Jim Johnson,and David Langworthy.Co-
ordinating Web Services Activities with
and WS-BusinessActivity.Available at
awarana.SOAP Services Description Language
Peter Furnis and Alastair Green.Choreology Ltd.
Feedback to the authors of WS-Coordination,WS-
AtomicTransaction and WS-BusinessActivity.Avail-
able at http://www.choreology.com/downloads/,May
James E.Johnson,David E.Langworthy,Leslie Lam-
port,and Friedrich H.V ogt.Formal speci?cation of
b services protocol.Electroni
c Notes in Theo-
retical Computer Science,Volume105,10December
James E.Johnson,David E.Langworthy,Leslie Lam-
port,and Friedrich H.V ogt.Formal speci?cation of a
web services protocol.to appear in Elseview Science,
Leslie Lamport.Specifying Systems.Addison Wesley,
Eric Newcomer and Greg Lomow.Understanding
SOA with Web Services.Addison Wesley Professional,
Marcus Venzke.Speci?cations using XQuery Expres-
sions on Traces.Mario Bravetti,Gianluigi Zavattaro
(Eds.):Proceedings of the First International Work-
shop on Web Services and Formal Methods,February
W3C.XQuery:the W3C query language
for XML–W3C working draft.Available at
Simon Zambrovski and Boris Gruschko.
TLA+Eclipse IDE Plugin.Available at