The Web Services-BusinessActivity–Initiator (WS-BA–I) Protocol: anExtension to the Web Services-BusinessActivity Specification

Hannes Erven*, Georg Hicker*, Christian Huemer* and Marco Zaptletal◦

* Business Informatics Group, ◦ Electronic Commerce GroupInstitute of Software Technology and Interactive Systems, Vienna University of Technology, Austria

hannes@erven.at, georg.hicker@reflex.at, huemer@big.tuwien.ac.at, marco@ec.tuwien.ac.at

Abstract

The Web Services Transaction protocol familyincludes the WS-AtomicTransaction and the WS-BusinessActivity specifications in order to carry outdistributed transactions in a Web Services (WS) environ-ment. The WS-AtomicTransaction specification definesall necessary interfaces to carry out transactional work.In contrary, the WS-BusinessActivity specificationfor long-running transactions intentionally left theinterface between initiator and coordinator undefined.This allows vendors to integrate WS-BusinessActivi-ty coordinators into their business process engines.However, it requires proprietary protocols betweeninitiator and coordinator. We propose an extensionprotocol to the WS-BusinessActivity specificationthat explicitly defines this interface between initiatorand coordinator. This extension allows coordinatorsand initiators from different vendors to interoperatetransparently. Accordingly, participants no longer needto trust an initiator-selected and likely initiator-runcoordination service, but may use commonly trusted,third-party coordination services.

1. Introduction

The WS-BusinessActivity specification [1] wascreated to enable web services to participate in long-running, loosely coupled transactions. This type oftransaction is commonly used when modelling businessprocesses, as for example in workflow systems wherethe workflow execution engine is responsible for coor-dinating the participants as defined by the rules of thebusiness processes.

At present, hardly any web service consuming soft-ware is backed by a workflow engine that provides WS-BusinessActivity coordination services. Hence there is

Coordinator Participant 2

Participant n

Participant 1Business

Logic

defined by WS-BA

Business Logic

Business Logic

Business Logic

(a)

defined by WS-BA defined by WS-BA-I

Coordinator Participant 2

Participant n

Participant 1

Business Logic

Initiator

Business Logic

Business Logic

Business Logic

(b)

Figure 1. WS-BusinessActivity and WS-Busi-nessActivity–Initiator overview

a need for independent, easy to use third party tools re-alizing business activity coordination services. Thesewill enable environments without workflow engines tocreate, coordinate and participate in long-running trans-actions.

The WS-BusinessActivity specification leaves thechoice of the coordination service to the application.This is depicted in Figure 1a. The lack of a well-definedinterface between application and coordinator requiresa coordination service that is either built into the appli-cation or tightly coupled to it. In other words, the busi-ness logic is tightly coupled to the coordination service.A participant has to trust this proprietary coordinationservice.

A “trusted third party” model, similar to the one

used for PKI certificate authorities, adds transactionsecurity to participants and initiators. However, thismodel requires a common protocol between initiatorand coordination service. In such a model, a coordina-tion service records all state changes and notifications.This means that a transaction’s progress is always reli-ably recorded by an independent party.

In this paper we introduce the WS-BusinessActivi-ty–Initiator protocol to be implemented between an ini-tiator and a coordination service. In Figure 1b we illus-trate how WS-BusinessActivity–Initiator and WS-Busi-nessActivity work together. The WS-BusinessActivity–Initiator specification proposes a protocol that enablesan initiator to enlist participants, to check on their cur-rent state and to inform the coordination service aboutdecisions it has made. The current proposal is designedas a “pull” protocol. Accordingly, the initiator is a sim-ple client that does not offer any services to the trans-action coordinator or participants. This enables evenapplications that do not run in web service containersand/or are behind firewalls or on NAT networks to cre-ate and control WS-BusinessActivity transactions. Theapproach we present in this paper has been implementedand contributed to the Apache Kandula project [2]. AWSDL description specifying the operations requiredby the WS-BusinessActivity–Initiator protocol is foundat [3].

The remainder of this paper is structured as follows:section 2 elaborates related work. In section 3 we brieflyintroduce the most important concepts of the WS-Busi-nessActivity standard. Afterwards, section 4 motivatesthe need for a standardized protocol between initiatorand coordinator. In section 5 we introduce this protocolin detail and illustrate it by a simple example. A shortsummary in section 6 concludes the paper.

2. Related work

For many years transaction processing has attracteda lot of attention. There exist various implementationsof the basic concepts and techniques as described byGray and Reuter [4]. Transaction processing is not onlyof great importance in database systems, but also in dis-tributed systems. The Object Management Group hasreleased a specification that provides transaction syn-chronization across the elements of a distributed clien-t/server application [5]. In this paper, we focus on thetransaction processing of a certain type of client/serverapplications, i.e. Web Services.

The WS-BusinessActivity specifcation [1] togetherwith the WS-AtomicTransaction [6] and the WS-Coordi-nation specifications [7] forms the WS-Transaction fam-ily, which is also referred to as the Web Services Trans-

action Framework (WSTF). Within this set of specifica-tions, WS-Coordination provides the foundation for im-plementing transactional web service interactions. It de-fines the coordination context of a transaction and proto-cols for registrating services therein. WS-AtomicTrans-action and WS-BusinessActivity build on WS-Coordina-tion by specifying differing types of transactional behav-ior. WS-AtomicTransaction focuses on transactions ac-cording to the ACID principle: Atomicity, Consistency,Isolation, and Durability. It implements the two-phasecommit protocol. WS-BusinessActivity, on the otherhand, focuses on long-running transactions allowing hu-man interactions and mixed outcomes.

This differentiation corresponds to the two kinds ofbusiness transactions for e-business applications as pro-posed in [8] and [9]. Atomic business transactions, onthe one hand, are small scale interactions that are com-posed of services that agree on enforcing a common out-come. This means, that either all services commit or allservices roll-back ensuring an atomic outcome. Long-running business transactions, on the other hand, aggre-gate several atomic transactions. They feature the samebehavior as open nested transactions by allowing theirsub-transactions to commit independently [10]. The su-perimposed business logic is then in charge of decidingon the overall outcome of the long-running transaction.

In [11], Papazoglu stresses the importance of trans-actional capabilities in terms of collaborative businessprocesses. He proposes a business transaction frame-work (BTF) orchestrating loosely coupled web servicesinto a single business transaction backed by transac-tional support. The BTF is responsible for coordinat-ing distributed autonomous business functionality andguarantees coordinated and predictable outcome forthe participating business partners. The work detailsthe functional criteria and the required components ofa BTF and compares standards such as the BusinessProcess Execution Language (BPEL) [12], WS-Atomic-Transaction, WS-Coordination, the Business Transac-tion Protocol (BTP) [13] and the ebXML Business Pro-cess Specification Schema (BPSS) [14] against it.

The Business Transaction Protocol (BTP), stan-dardized by OASIS, is an analog initiative for coordi-nating service interactions. It aims at defining a proto-col for representing and seamlessly managing complex,multi-step business-to-business (B2B) transactions overthe Internet. The BTP is not restricted to the webservice environment, but might be layered over otherframeworks like RosettaNet [15] or ebXML [16]. How-ever, in the web services world, the WSTF currentlyseems to be better supported than BTP.

Vogt et al. outline in [17] that WS-Coordina-tion and WS-BusinessActivity violate the SOA paradigm

by making assumptions about the internal structures ofthe participants. They underpin their assertion by ananalysis based on a proof-of-concept implementation ofWS-Coordination and WS-BusinessActivity . As a resultof this analysis they discover a tight-coupling betweenthe entities participating in the transaction (coordinator,initiator, and participant). Their approach introducesa transactional middleware that separates the client’sbusiness logic from the coordination logic. However,the middleware is still required to deal with businessmessages which prohibits a complete seperation of con-cerns. It follows, that their approach does not allow for athird-party coordinator service as proposed in our work.

The work by Sauter and Melzer [18] focuses on acomparison of WS-BusinessActivity and BPEL with re-spect to long-running transactions. They show the dif-ferences as well as the similarities between these stan-dards and discuss that they are not contradicting ap-proaches as sometimes argued. Furthermore, their workproposes to integrate WS-BusinessActivity into BPEL toallow for distributed coordination. Therefore, BPEL’scompensation handler is replaced by a coordination han-dler that coordinates nested scopes via SOAP messages.

3. The WS-BusinessActivity protocol

The WS-BusinessActivity standard [1] specifies thecoordination type business activity as defined in the ex-tendable WS-Coordination framework [7]. This coor-dination type defines long running transactions whichcould consist of several atomic transactions. In this co-ordination type processing of requests could take sometime, since human interaction or the assembly of partscould be necessary. This means an un-do cannot be real-ized by a roll-back function. Instead an un-do requires asophisticated compensation mechanism involving busi-ness logic. For example the cancelation of a bookingrequires a compensation mechanism that may includethe billing of cancelation fees.

The following attributes characterize transactionsof the business activity coordination type [1]:

• All state changes made during a transaction arerecorded. Especially application state and coordi-nation metadata are collected to enable later com-pensation.

• Messages have to be acknowledged so that coordi-nator and participant have the same perception ofstate.

• Each message has to be transmitted individually.This means that it is not allowed to combine mes-sages.

The WS-BusinessActivity specification allows nest-ing business activities. Consequently, a business activ-ity may be included in another one. Nested transactionsallow intercepting and handling errors that should notlead to a failure of the parent transaction. A popularexample for a nested structure is the supply of prod-uct components. Consider, components are urgentlyneeded. A nested transaction is initiated to contact thecontractor delivering at the lowest price. If the contrac-tor is not able to deliver in time, the nested transactiondoes not necessarily fail, since another contractor maybe able to supply the components in time.

WS-AtomicTransaction is based on the classicACID properties. In contrast, WS-BusinessActivity hadto soften this classical transaction paradigm. It sup-ports so-called long running transactions that do notlock datasets. This allows e.g. waiting for user input orassembly of parts. In all these cases locks are not possi-ble because they would block other business processes.Therefore results and changes during business activitiesare immediately visible to the outside of a transaction.Locks on datasets are held as short as possible or, better,are not held at all. Since locks are sometimes criticalto the overall system, WS-BusinessActivity may be com-bined with nested atomic transactions.

WS-BusinessActivity specifies two coordinationtypes: (AtomicOutcome and MixedOutcome. Each ofthem may be use in the two coordination protocols de-scribed in the following subsections.

3.1. BusinessAgreementWithParticipantCom-pletion protocol (BAwPC)

We depict the lifecycle of a transaction for theBAwPC protocol in Figure 2 [1]. It shows the statesof the transaction and the messages that lead to statechanges. A participant registered for this protocol de-cides when he has done all work for an activity. Theparticipant informs the coordinator about finishing hiswork by means of a Completed message.

The coordinator may reply with a Close or with aCompensate message upon receipt of a Completed mes-sage. A Close message signals to the participant thatthe transaction is ended in a positive way. In case thecoordinator wants to undo work and to restore the ini-tial original conditions of data, he sends a Compensatemessage.

A problem concerning the message order is the factthat the coordinator may receive a message which is noteffective to the already reached state. In this case thecoordinator has to revert to its prior state and handlethe received message accordingly. Moreover a party, re-gardless whether coordinator or participant, has to be

prepared to receive duplicate protocol messages and hasto react according to the specification. The party has toeither resend a prior message or ignore the duplicate asdefined in Appendix A of the specification [1].

The participant signals an error by sending a Faultmessage to the coordinator. The coordinator acknowl-edges this message by a Faulted message. After send-ing this message the protocol instance is terminated andno more messages can be exchanged.

Figure 2. Lifecycle of the BusinessAgreement-WithParticipantCompletion protocol

The coordinator can end a transaction by sending aCancel message while the transaction is in Active state.However the specification does not illustrate how thecoordinator should decide to end the business activity.This task has to be handled by the business logic. Inany case, the participant has to answer with a Canceledmessage.

3.2. BusinessAgreementWithCoordinatorCom-pletion protocol (BAwCC)

In the BAwPC decribed before the participant doesdecide when the activity is terminated. The coordinatormakes this decision in the BAwCC. This difference be-comes obvious in Figure 3 which depicts the lifecycleof a transaction in the BAwCC protocol [1]. In this pro-tocol the coordinator sends a Complete message whichis followed by a Completed message of the participant.As a consequence, an additional state Completing is re-quired between the states Active and Completed. Oncehaving reached the state Completed the rest of the life-cycle is the same as for the BAwPC protocol describedbefore.

4. Motivation for the WS-BusinessActivity–Initiator protocol

The WS-BusinessActivity protocol specificationconcentrates on the interaction between the coordinatorand the participant roles. It does intentionally not spec-ify how the transaction can actually be managed by the

Figure 3. Lifecycle of the BusinessAgreement-WithCoordinatorCompletion protocol

corresponding business logic. The authors of the WS-BusinessActivity specification expect workflow enginesto provide proprietary interfaces for workflows to man-age their tasks with WS-BusinessActivity. While WS-AtomicTransaction’s CompletionProtocol also definesan interface between the initiator and coordinator roles,it does not have an equivalent in WS-BusinessActivity.

The tight coupling between coordinator and initia-tor violates common software architecture principles,since distinct roles always should have an explicit com-munications protocol defined between them. A clearseparation of concerns vastly enhances software modu-larity and reuseability.

The WS-BusinessActivity protocol also does notspecify how the initiator’s business logic may map busi-ness partners to transaction participants. Hence, the ini-tiator is not able to assess the meaning of a transaction’sstate to the business task he is performing.

As a solution, we propose the WS-BusinessActivity–Initiator protocol that defines the additional interface. Itis designed as a “pull” based protocol where the initia-tor frequently polls the coordinator for the context’s andhis participants states. The protocol design offers thefollowing advantages:

Firstly, it relieves the business logic’s container ofproviding a web service interface to participants and/orthe coordinator. Accordingly, even environments thatcannot provide SOAP endpoints may take on the initia-tor role.

Secondly, it does no more require that coordinatorand/or participants are able to actively contact the entitycontaining the business logic. The business logic maysit on a restricted, NAT- or firewalled network or evenbe temporarily disconnected.

Thirdly, it requires that every participant of a trans-action is individually “invited” by the business logic.Thereby it maintains a business-partner to transaction-participant relationship.

Fourthly, it allows independent, third parties to of-fer coordination-only services. The third party could

also reliably record the transaction’s progress for laterassessment.

In a nutshell, one could say the protocol “bringsWS-BusinessActivity to the desktop” since it allows cre-ating desktop applications that manage WS-BusinessAct-ivity transaction contexts.

In order to coordinate the transaction’s progress,the initiator role needs to be able to perform the fol-lowing tasks: (i) notify the coordinator when invitingnew participants; (ii) decide whether the context’s over-all goals can be achieved by querying the participants’states; (iii) send the Complete and Cancel commands toindividual participants; (iv) in mixed outcome contexts,direct each participant to either Close or Compensate;and (v), in atomic outcome contexts, decide whether toClose or to Cancel/Compensate all work.

The WS-BusinessActivity–Initiator protocol de-fines the interface that allows a business logic imple-mentation to perform those tasks by sending its deci-sions to the coordinator service. The coordinator ser-vice actually executes these decisions by sending theappropriate messages to the participants.

5. The WS-BusinessActivity–Initiator proto-col

In order to create a new transaction context the ini-tiator contacts the activation service. In our proposedextension the initiator shall immediately register itselffor the WS-BusinessActivity–Initiator protocol by con-tacting the registration service associated with the con-text. The coordinator will only allow one initiator percontext and will reject all further registration requestsfor that protocol.

When successfully registered, the initiator uses theWS-BusinessActivity–Initiator protocol service to com-municate with the transaction context. It enables theinitiator to perform the tasks necessary to manage thetransaction’s progress. The inititor may request coordi-nation context data for additional participants. Further-more, it may also query the current states of the enrolledparticipants. It may ask the coordinator to send WS-BusinessActivity messages to the participants directingthem through the WS-BusinessActivity protocol’s states.When the initiator is managing a subcontext, it may askthe coordinator to send messages to its supercontext.These concepts realized in our WS-BusinessActivity–Ini-tiator protocol are detailed in the following subsections.

5.1. Registration and Participant Identification

In a business activity, participants are invited by theinitiator to join the transaction by passing a WS-Coordi-

nation CoordinationContext object with an applicationmessage to them. The CoordinationContext object in-cludes the registration service’s endpoint address andthe transaction identifier.

The initiator must be able to map the business-levelpartners to transaction-level participants. In order tofacilitate the identification of participants, the methodcreateCoordinationContext opens a registra-tion ticket in the context that is bound to an initiator pro-vided “match code”. Thus, the “match code” extendsthe CoordinationContext object as defined in WS-Coor-dination (see [7]). The initiator passes this object includ-ing the “match code” on to the business partner, whoin turn registers using the data from the received Coor-dinationContext object. The registration service auto-matically associates the registering participant with thematch code. When issuing subsequent commands, theinitiator may now address individual participants withtheir match codes.

Although the WS-BusinessActivity specificationdoes not explicitly define whether a particular “invita-tion ticket” (CoordinationContext object) may be usedfor multiple registrations, this specification restricts reg-istrations to one single participant per “invitation”. The“identification” design goal implies that every partici-pant is assigned to a unique match code, so a partic-ular CoordinationContext object must not be used formultiple registrations. Should a business partner listedas a participant require in turn to enlist multiple partici-pants to complete his work, he may create a subcontext(which is presented as one single participant to its super-context) to manage those participants.

5.2. Transaction State Reporting

The initiator may at any time ask the coordinatorfor a complete list of participants enrolled in a trans-action. Each participant in this list is characterized asfollows:

• the participant’s match code

• the protocol the participant registered for

• the participant’s current state

• the participant’s result stateBased on this information the initiator application

may decide what commands to issue. The “participantresult” offers the initiator information about what out-come the participant has agreed on. When the partic-ipant has reached the Ended state, the result is eitherCanceling, Closing, Compensating, Faulting, Faulting/-Canceling or Faulting/Compensating depending on theprevious state the participant visited. When the partic-ipant has reached the Completed, Closing, Compensat-

ing or Faulting/Compensating state, the result is Com-pleted as the participant has not yet confirmed anythingelse. In all other states, the result is Active.

5.3. Commands sent to Participants

The set of available commands depends on the busi-ness activity’s outcome assertion:

• mixed outcome allows for the independent manage-ment of the participants.

• atomic outcome mandates that all participants aredirected to an equal target state: either they allclose, or they all Cancel or Compensate. Partici-pants who leave by sending Exit or Fault are notconsidered.1

The following sections describe the protocol com-mands available in each of the outcome models. Shouldthe initiator request a message to be sent to a partici-pant for whom the message is not appropriate in hiscurrent state (e.g. sending Complete to a non-Coordi-natorCompletion protocol participant) the coordinatorwill silently skip this participant. All operations exceptgetCoordinationContextWithMatchcode re-turn an updated participant list.

The following commands are valid for all businessactivities:

• listParticipants: retrieve a list of a transac-tion’s participants (see subsection 5.2).

• completeParticipants: ask the coordinatorto send a Complete message to the specified partic-ipants. This command only applies to participantswho registered for the CoordinatorCompletion pro-tocol.

• getCoordinationContextWithMatch-code: retrieve a new CoordinationContext objecta new participant can use for registration. Thematch code specified within the coordinationcontext is used to identify the participant through-out the transaction. The coordinator will alwaysinclude the match code when information abouta context is given. Furthermore, the coordinatoralways expects the match code when referring toa particular participant. The coordinator must en-sure that match codes are unique in their contextsand that each match code must exactly refer eitherto one participant or to a pending registration. In

1Although one could argue that Fault should generally drive com-pensation, handling the faulted participants as if they exited enablesthe initiator to invite other business partners who may replace thefailed participant.

atomic outcome contexts, this method cannot becalled after the initiator made its final decision.

5.3.1. Commands Valid in Business Activities withAtomic Outcome. This protocol extension allows theinitiator to decide on the transaction’s final outcome andtell the coordinator to execute the final decision. Theinitiator may call only one of the following methods pertransaction.

• closeAllParticipants: decide to commitall work. This command is only valid when eachparticipant has reached either the Completed, Ex-iting or Exited state. The coordinator will tell allCompleted participants to close.

• cancelOrCompensateAllParticipants:decide that all work shall be aborted. The coor-dinator will direct participants to either Cancelor Compensate, depending on their state. Thereis a small chance that a participant being in theCompleting state is sent a Cancel command atthe same time as he completes his work andreports Completed. According to the specification,the coordinator must discard his last messagesent and accept the participant’s message. Toenforce the already made decision, the coordinatormust immediately issue a Compensate commandto this participant. Should the participant beunable to compensate and send Fault, the overalltransaction result is undefined and requires humanintervention.

Once the final decision is made, the coordinatorwill refuse to register new match codes and will also re-ject participants who try to register for an already openmatch code. Subsequent calls are rejected with an In-valid_State_Fault.

If the initiator invokes one of those methods whilehis preconditions are not met, the coordinator silentlyignores the request and returns the current participantlist.

5.3.2. Commands Valid in Business Activities withMixed Outcome. The mixed outcome assertion allowsfor the independent management of a transaction’s par-ticipants. The initiator is required to tell the coordi-nator what command to give to the participants at anyprotocol state where more than one command is appro-priate or the timing of the message is important (e.g.Complete). The coordinator will handle simple request-response type message flows automatically, e.g. uponreceipt of an Exit notification the coordinator automati-cally replies with Exited.

Each of the following commands takes a list ofparticipant match codes as argument. The coordinatormakes sure that the requested command is valid in theparticipant’s current state and silently discards inappro-priate commands. Once the coordinator has completedhis task, he returns a list of the participants includingtheir current states.

• cancelParticipants: tells the coordinatorto send Cancel to the specified participants.

• closeParticipants: tells the coordinator tosend Close to the specified participants.

• compensateParticipants: tells the coordi-nator to send Compensate to the specified partici-pants.

5.4. Managing Subcontexts

A subcontext encapsulates a whole transactionscope and presents it as a single participant to its par-ent transaction. This allows for the separation and par-allelization of tasks a business activity needs to performwithout loosing transactional semantics or control overthe progress the participants make.

The initiator of a subcontext requires business logicto translate commands from the supercontext into com-mands he may issue to his local participants. This spec-ification proposes that the subcontext coordinator regis-ters himself for the CoordinatorCompletion protocol2

in the super context and forwards any commands re-ceived to the subcontext initiator via a pull based queryprotocol.

Upon receipt of a valid message from the supercon-text, the subcoordinator performs the internal state tran-sition associated with the command and reliably liststhe message for the initiator to query:

• received Complete: store and transist to Complet-ing

• received Cancel: store and transist to Canceling• received Close: store and transist to Closing• received Compensate: store and transist to Com-

pensating• received Exited: store and transist to Ended

The initiator may instruct the subcoordinator tosend messages to the supercontext. Upon receipt ofsuch a command, the subcoordinator makes sure it isallowed in the current state and performs the state tran-sition associated with the outgoing message.

2The CoordinatorCompletion protocol is a superset of the Partici-pantCompletion protocol, hence one registration is sufficient.

• report Exit and transist to Exiting• report Completed and transist to Completed• report Compensated and transist to Compensated• report Fault and transist to Faulting

In atomic outcome subcontexts, the coordinator au-tomatically handles the following events:

• when receiving Close from the supercontext, all lo-cal Completed participants are directed to close.When all of those participants reported Closed,also report Closed to the supercontext.

• when receiving Compensate from the supercontext,all local Completed participants are directed tocompensate. When all participants reported Com-pensated, also report Compensated to the super-context; if one or more participants fail, also reportFailed to the supercontext.

• when receiving Cancel from the supercontextwhile in state Active, reject new participants anddirect all existing participants to cancel. Whenall participants reported Canceled, also report Can-celed to the supercontext.

In the following we consider special cases for can-celling and compensation in subcontexts. In the Com-pleting state, the WS-BusinessActivity protocol allowsboth coordinator and participant to initiate a state transi-tion: the coordinator may send Cancel, and the partici-pant may send Exit, Completed or Fault. If both partiessend contradicting messages at the same time, the co-ordinator must discard its own message and accept theparticipant’s one.

If the participant reported Completed, it is requiredto run compensation, but - unlike cancellation - compen-sation is allowed to fail. This race condition allows asituation to occur where the coordinator (from its pointof view) sent a timely Cancel command, but the partic-ipant completed anyways and later failed on compensa-tion, leaving the requested work permanently done in-stead of canceled.

This is especially bad in a subcontext. Becausewhen the coordinator of the subcontext is told to can-cel and forwards this command to the local participants,some may successfully cancel while others already havecompleted. It cannot report Completed since some partsof its work have successfully been canceled, and onthe other hand cannot report Canceled since some workhas actually been performed. The subcoordinator musthence immediatly try to compensate the Completed par-ticipants, and if they all successfully Compensated, mayreport Canceled to the supercontext. If one single partic-ipant fails during compensation, the whole subcontext

must report Fault to the supercontext to further escalatethe issue.

The WS-BusinessActivity specification does notspecify how subcontexts should handle other situations.In order to keep the time window for such critical statesat a minimum length, a subcontext should invite Partici-pantCompletion protocol participants only after receiv-ing the Complete command from its supercontext. Thisensures that a ParticipantCompletion protocol partici-pant cannot report Completed when the supercontexthas not told the subcontext to Complete. Registeringfor the ParticipantCompletion protocol itself is not anoption for the subcontext, since it must not report Com-pleted before all required participants themselves reachCompleted.

In most cases an application will not know the pro-tocol a particular business partner will register for in ad-vance. In order to be on the safe side, all participantsshould be enrolled only after receiving the Completemessage from the supercontext.

This convention keeps the time window for a colli-sion short, but does not avoid the problem at all. Remov-ing the possibility to issue a Cancel command in Com-pleting would be a way to permanently fix the specifica-tion and better reflect the actual semantics: in general,a Completing participant will already have some workdone and hence cancelling requires some kind of com-pensation to be executed. With the Cancel commandremoved, the initiator could not tell a Completing par-ticipant to stop processing. Instead he has to wait untilthey finish and then issue Compensate.

5.5. A Sample WS-BusinessActivity–Initia-tor Transaction

Figure 4 illustrates a sample transaction with mixedoutcome in which the initiator decides on the outcome.The initiator-object is instantiated by the applicationand creates a CoordinationContext for the transaction.After having registered for the WS-BA–I protocol, theinitiator is able to send CreateCoordinationContext mes-sages to the coordinator which contain a different matchcode for each participant. It is the applications task toforward the returned CoordinationContext within an ap-plication message to its business partners.

After receiving an application message containinga CoordinationContext the business partner may regis-ter for the transaction as a participant using the receivedCoordinationContext. As shown in Figure 4, the initi-ating application repeatedly sends listParticipants mes-sages to the coordinator to learn how many participantsare already enrolled and in which states they currentlyare.

Figure 4. A sample WS-BusinessActivity–Initi-ator transaction

If the application decides to completethe transaction it tells the initiator to send acompleteParticipants message to the coor-dinator, who in turn sends Complete messages tothe specified participants. After having sent out theComplete messages the coordinator immediatly returnsa CompleteParticipantsResponse to the initiator. Itcontains a participantList element that includes theupdated participant states.

Since the coordinator does not actively inform theinitiator about state changes, they must re-query currentstates by invoking the listParticipants method from timeto time. If all participants are in the correct state theymay call for closure of certain participants (in case of atransaction with atomic outcome this can only be donefor all of them). This call behaves like the completioncall: a response is generated immediately after all Close

messages were sent to the participants, and the initia-tor has to query for state changes. As soon as all par-ticipants have replied with Closed and, thus, reach theEnded state, all involved parties may forget about thetransaction after the configured timeout.

6. Summary and Conclusion

Although WS-BusinessActivity was introduced in2001, it is still expensive for software developers tomake their products benefit from it. This is also due tothe fact that in WS-BusinessActivity a workflow engineor extensive custom programming are needed to im-plement the coordinator role. The approach presentedin this paper - which is also implemented as part ofthe Apache Kandula project [2] - significantly reducesthe overhead involved when implementing WS-BA. Fur-thermore, the vendor-independent specification allowsinitiators to interoperate with any WS-BA–I compliantcoordinator. It thereby creates an open environment.

With the clear distinction between business logicand transactional logic not only on the participant butalso the initiator side, WS-BA–I vastly increases soft-ware modularity.

The clear separation of the initiator and coordinatorroles enables initiators to select independent third par-ties who perform a transaction’s coordination. We ex-pect third-party coordination services to be offered andlater to be certified. Thereby, both initiators and par-ticipants are assured of a correct coordination. Futureextensions of WS-BusinessActivity–Initiator may offerimproved reliability, security or performance.

References

[1] L. Cabrera, G. Copeland, W. Cox, T. Freund,J. Klein, D. Langworthy, I. Robinson, T. Storey, andS. Thatte, Web Services Business Activity Framework(WS-BusinessActivity), version 2005-08 ed., Aug. 2005.[Online]. Available: ftp://www6.software.ibm.com/software/developer/library/WS-BusinessActivity.pdf

[2] Apache “Kandula”, http://ws.apache.org/kandula, Jan.2007.

[3] H. Erven and G. Hicker, WSDL Description Filefor the WS-BusinessActivity–Initiator Protocol, Feb.2007. [Online]. Available: http://www.big.tuwien.ac.at/projects/WS-BAI/InitiatorProtocol.wsdl

[4] J. Gray and A. Reuter, Transaction Processing: Con-cepts and Techniques. Morgan Kaufmann Publishers,Inc., October 1993.

[5] OMG, “Object transaction service specification,”in CORBAservices: Common Object ServicesSpecification. Object Management Group, Sep.2003, version 1.4. [Online]. Available: http:

//www.omg.org/cgi-bin/doc?formal/2003-09-02[6] L. Cabrera, G. Copeland, W. Cox, M. Feingold,

T. Freund, J. Johnson, C. Kaler, J. Klein, D. Lang-worthy, A. Nadalin, I. Robinson, T. Storey, andS. Thatte, Web Services Atomic Transaction (WS-AtomicTransaction), version 2005-08 ed., Aug. 2005.[Online]. Available: ftp://www6.software.ibm.com/software/developer/library/WS-AtomicTransaction.pdf

[7] L. Cabrera, G. Copeland, W. Cox, M. Feingold,T. Freund, J. Johnson, C. Kaler, J. Klein, D. Lang-worthy, A. Nadalin, D. Orchard, I. Robinson,J. Shewchuk, and T. Storey, Web Services Coordi-nation (WS-Coordination), version 2005-08 ed., Aug.2005. [Online]. Available: ftp://www6.software.ibm.com/software/developer/library/WS-Coordination.pdf

[8] M. Papazoglou, A. Tsalgatidou, and J. Yang, “TheRole of eServices and Transactions for Integrated ValueChains,” Business to business electronic commerce, pp.207–241, 2003.

[9] J. Yang and M. Papazoglou, “Interoperation support forelectronic business,” Commun. ACM, vol. 43, no. 6, pp.39–47, 2000.

[10] G. Weikum and H.-J. Schek, “Concepts and applicationsof multilevel transactions and open nested transactions,”in Database Transaction Models for Advanced Applica-tions. San Francisco, CA, USA: Morgan KaufmannPublishers Inc., 1992, pp. 515–553.

[11] M. Papazoglou, “Web services and business trans-actions,” World Wide Web, vol. 6, no. 1, pp.49–91, Mar. 2003. [Online]. Available: http://www.springerlink.com/content/h4635u5r9m67t305

[12] Business Process Execution Language for WebServices, Version 1.1 ed., BEA, IBM, Mi-crosoft, SAP AG and Siebel Systems, May 2003.[Online]. Available: ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf

[13] Business Transaction Protocol, Version 1.0 committeespecification ed., Organization for the Advancement ofStructured Information Systems (OASIS), Jun. 2002.

[14] UN/CEFACT - ebXML Business Process SpecificationSchema, Version 1.11 ed., UN/CEFACT TMG, 2003.

[15] RosettaNet Implementation Framework: Core Specifica-tion, Version 02.00.01 ed., RosettaNet, December 2002.[Online]. Available: http://www.rosettanet.org/rnif

[16] ebXML - Technical Architecture Specification, Version1.4 ed., OASIS, UN/CEFACT, Feb. 2001. [Online].Available: http://www.ebXML.org/specs/ebTA.pdf

[17] F. Vogt, S. Zambrovski, B. Gruschko, P. Furniss, andA. Green, “Implementing web service protocols in soa:Ws-coordination and ws-businessactivity,” in CECW’05: Proceedings of the Seventh IEEE International Con-ference on E-Commerce Technology Workshops. Wash-ington, DC, USA: IEEE Computer Society, 2005, pp.21–28.

[18] P. Sauter and I. Melzer, “A comparison of ws-businessactivity and bpel4ws long-running transaction,”in Kommunikation in Verteilten Systemen (KiVS), ser. In-formatik Aktuell. Springer, 2005, pp. 115–125.