Skip to Content

OASIS Members Form Committee to Advance Web Services Transaction (WS-TX) Standards


WS-TX is the third committee formed at OASIS that aims at developing the critically needed Web Services Transaction specification. The first was  the OASIS BTP (Business Transaction Protocol) committee and the second was OASIS WS-CAF (Composite Application Framework)  committee. This time all interested parties have joined the working group and it  is expected that this specification will be broadly adopted and enable full  interoperability between services running on any platform.

Transaction protocols specify a message interchange between the transaction coordinator and transaction participants to achieve a commonly agreed outcome for a particular unit of work. Distributed transaction protocols fall in one of the three following categories:

  • Provisional-Final: do the application work but mark it as provisional. If told to confirm, mark the provisional work as final. If told to cancel, delete the provisional work or mark it cancelled. ACID is just a version of Provisional-Final where the Provisional effects are invisible
  • Validate-Do: validate that the application work could be done, and do it if told to confirm. If told to cancel, no application work has been done anyway.
  • Do-Compensate: immediately do the application work as if it is final, and later undo if told to cancel. If told to confirm, the application work has already been done.

A transaction protocol can be decomposed in two elements:

  • A state alignment protocol
  • A transaction scenario

One of the key requirements of a transaction protocol is that the state between the coordinator and all the participants be aligned, even when messages cannot be exchanged via the utilization of timeouts. A state alignment protocol is mandatory to monitor the execution of actions.

The input to the technical committee is the family of specification that Microsoft, IBM and BEA have been developing as the WS-Coordination,  WS-AtomicTransaction and WS-BusinessActivity specifications. This family of  specifications was designed such that more transaction protocols may be added in  the future if necessary. The AtomicTransaction protocol belongs to the  Provisional-Final category while the BusinessActivity protocol belongs to the  Do-Compensate category.


The transaction initiator creates a transaction context with the coordination  service. As the initiator invokes operations on other services that participate in this  transaction, they in turn self-register with the coordination service  and provide the end-point that implements the transaction protocol. When the  initiator informs the coordinator that the transaction is  complete, the coordinator propagates the completion notification to  all participants and either confirms or roll-back of the transaction based on  potential errors that occurred during the invocation phase (AtomicTransaction)  or based on some business logic (BusinessActivity).

The Coordinator service is a composite service which  provides activation, registration and protocol specific services (Figure 1).



Figure 1 WS-Coordination Coordinator Service

Different coordination topologies are allowed, where communications can be local or crossing trust boundaries, including being in a federated trust scenarios.

The WS-TX protocols can be composed with the WS-Security specification to  ensure authenticated and authorized message exchanges. The  WS-TX does not require the use of a reliable transport as it provides a state  alignment protocol as part of the transaction protocol (via the confirmation of  the protocol notifications).

WS-BusinessActivity Protocol

The business activity coordination typed should be used to  coordinate activities that apply business logic to handle business exceptions.  Actions are applied immediately and permanent, so it belongs to the  Do-Compensate category. Compensating actions may be invoked in the case of an  error, as defined by the business logic.

Business activities have the following characteristics:

  • run over a long duration and consume many resources
  • many atomic transactions may be involved
  • the results of individual tasks within the activity are visible prior to  the completion of the activity
  • responding to a request might take a very long time
  • when a business exception occurs, the activity needs to be logically  undone, abort is not sufficient
  • exception handling mechanism may require business logic
  • participants may be in different domain of trusts

A business application may be partitioned into business  activity scopes which is a task consisting of general purpose computation  carried out as a set of operations invocations that require a mutually agreed  outcome. There can be any number of hierarchical nesting levels.

The specification provides two Coordination Types (Atomic  Outcome, Mixed Outcome) and two protocol types. Either protocol can be used with  either protocol type.

For an AtomicOutcome, all participants must be directed to  “close” or “compensate”.

Figure 2 represents the protocol for the BusinessAgreementWithCoordinatorCompletion type, i.e. when the coordinator tells participants when they have received all requests to perform work within the business activity



Figure 2. Coordinator Completion Protocol

The notation used here to represent the transaction protocol is an ad hoc notation which represents the steps of the protocol. Each step corresponds to a  message exchange between a participant (P) and the coordinator (C). This message  is always followed by a confirmation represented on the transition to the next  step. The forks represented here all have an “XOR” semantic.        


Atomic transactions happen in an all-or-nothing fashion.  The actions taken prior to commit are only tentative (i.e. not persistent, not visible to other activities). When an application finishes, it requires that the coordinator to determine the outcome by asking the participants to vote. If all participants vote positively, the transaction has reached a positive outcome and the coordinator commits the changes, otherwise, it issues a rollback. The corresponding protocol is represented figure 3.



Figure 3. Two Phase Commit Protocol


This specification has been long waited for. With all the work that has been accomplished in the prior years  by many companies and the broad supports this committee enjoys, we should see a stable specification within less than a year. Michael Bechauf, Vice President of Industry Standards, SAP says “This specification is critical to the Enterprise Services Architecture (ESA) because it makes it easier for our customers to use services to compose innovative B2B solutions that run on SAP NetWeaver.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.