Introduction
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.
Architecture
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.
WS-AtomicTransaction
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
Conclusion
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.
