January 21, 2021
Hot Topics:

A Transaction Model for Web Services

  • By McGovern, Tyagi, Stevens, and Mathew
  • Send Email »
  • More Articles »


WS-Transaction (WS-TX) and the related WS-Coordination specifications are relatively new (released in August 2002). They describe mechanisms to coordinate the executions of individual Web services into reliable applications. The two specifications, created jointly by Microsoft, IBM, and BEA, rely on or are built on existing Web services specifications of WSDL, SOAP, and WS-Security.

The execution of a Web service application is seen as a series of activities, each of which may be executed in a different Web service. WS-Coordination describes a general mechanism to create, register, and coordinate those activities across multiple Web services. When a participant Web service creates and registers the activity, it also identifies the coordination protocol—that is, the way collaboration occurs between activities. The specification does not describe protocols for coordination,. which can be achieved in many ways. Some coordination protocols may be transactional; some may not.

WS-Coordination provides a generalized framework that allows Web services to specify the coordination protocol. WS-Transaction describes protocols for two common transactional coordination patterns that may be used with the WS-Coordination framework: the atomic transaction coordination pattern and the business activity transaction pattern. Figure 11 shows the relationship between WS-Coordination and WS-Transaction.

Click here for a larger image.

Figure 11 Relationship between WS-Coordination and WS-Transaction

Before describing the WS-Transaction coordination protocols, a brief explanation of the coordination framework described in WS-Coordination is necessary. The latter describes a standard coordination framework, consisting of an activation service, which helps create a new activity; a registration service, to register an activity's participants; and a coordination service, to process an activity's completion.

An application contacts the activation service to create an activity, which is identified by a coordination context. The context is a container (defined by an XML schema) with elements for an ID, a context expiration time, the coordination type (the coordination protocols to be used), and other extensible elements. Web services that participate in the same activity receive application messages with the context attached. Web services then use the context to identify the registration service and register as participants to the original activity. The coordination service controls the completion of the activity, based on the selected coordination protocol.

A WS-TX atomic transaction coordination pattern preserves the ACID properties of transactions. The application requests that a new activity be created by the activity service. The activity service creates a coordination context that has the coordinationType element set to the URI http://schemas.xmlsoap.org/ws/2002/08/wstx. The coordination context allows for coordination-protocol-specific elements to be added to the context, using the extensibility mechanism (e.g., a context for an atomic transaction may also carry the isolation level value).

The Web service that created the transaction also registers with the registration service the coordination or completion pattern service for the completion protocol. The coordination service controls the completion of the activity, based on the registered completion protocol.

The BTP and WS-Transaction/WS-Coordination specifications provide for similar transactional needs. One important difference between them is that although BTP provides bindings for SOAP 1.1, it is independent of current de facto Web service standards, although WS-Transaction is built on or relies on SOAP, WSDL, and WS-Security.

Activity Service

Activity Service framework is a submission to OMG in response to OMG's call for additional structuring mechanisms for Object Transaction Service (OTS). OTS, you will recall, is the specification for the CORBA transaction manager. The Activity Service specification submission, like the BTP specification, addresses the transactional needs of complex, long-running transactions. The submission can be found at http://cgi.omg.org/cgi-bin/doc?orbos/20000619.

This specification, unlike BTP, is directly tied to and based on the OMG Object Request Broker (ORB) and OTS specifications. The lack of support for XML-based messages and Activity Service's tie to OTS may mean that Web services implemented in compliance to it may not transact transparently with services written on, say, the .NET platform. However, because most current Java transaction managers implement JTS (which is a Java mapping of OTS), Activity Service is likely to have a high impact on how Java transaction managers are implemented.

JSRs for Web Service Transaction Support

As described earlier, JTA- and JTS-based transaction managers are limited, in that they are meant to manage and coordinate distributed, ACID transactions. A new specification is needed to address the complex distributed transactions prevalent in Web service and workflow applications.

JSR-95, J2EE Activity Service for Extended Transactions, proposes a low-level API for J2EE containers and transaction managers. JSR-95 borrows from the OMG Activity Service submission and leverages concepts defined by JTA and EJB specifications.

JSR-156, XML Transactions for Java (JAXTX), also proposes support for extended transaction support in J2EE systems. Unlike JSR95, JSR-156 proposes a closer relationship to the BTP specification, using XML messaging for transaction management and coordination. This proposed Java API also has a loftier long-term goal: to isolate application programmers and application servers from the underlying transaction manager implementation (BTP, WS-Transaction, and Activity Service).

The acronym "JAXTX," in an attempt at consistency with other JAX* APIs, is, in our opinion, misleading. The other JAX* APIs (e.g., JAXM) are meant to be used primarily by application programmers. The J2EE specifications have tried to minimize programmatic transaction demarcation, making the UserTransaction interface the only JTA interface exposed to the application.

We recognize that coordinated, non-atomic transactions (e.g., cohesive BTP transactions and business transactions in the WS-Transaction specification) will require application logic to generate compensation transactions. We also recognize that in determining the subset of activities treated as atomic, the interface exposed to application programmers must be expanded beyond the current JTA UserTransaction interface. But the vast majority of transaction coordination messages are meant to be exchanged by components below the application layer. Therefore, we feel that "JAXTX" is misleading.


J2EE servers are required only to implement the flat transaction model. This model is sufficient in situations where the transactional resources are centralized and under the control of one party. The ACID properties of such transactions can be maintained without compromise. This transactional model is adequate for Web service applications with short-running transactions and those in which transactions do not span organizational boundaries.

The flat transaction mode is inadequate to address the transactional needs of some business transactions in Web services, which frequently involve the assembly of disparate services. These disparate services may have been written with their own, autonomous transaction boundaries and may control their own resources. Web services for business-to-business integration can also be long-running, causing inefficiency as a result of the locking mechanism used for achieving isolation in traditional transaction models.

Relaxing the isolation property of transactions and allowing subtransactions to make visible state-change effects before the larger transaction completes solves the problem of inefficient resource locking in long-running transactions. Allowing a transaction to complete even if only a subset of subtransactions completes (i.e., relaxing the atomic property) allows a business transaction to be composed based on application needs.

The BTP, WS-TX, and Activity Service specifications address the needs of coordinating long-running business transactions that span autonomous, loosely coupled services while accommodating the needs of short-running, centralized transactions. BTP specifies the working of atomic and cohesive transactions, and WS-TX describes the atomic and business activity patterns for coordination. The Activity Service submission to OMG also provides a specification for business transactions but does not reference XML-based messages specifically. (Because Activity Service is based on OMG OTS, it does provide IDL specifications.)

Two JSRs, JSR-95 and JSR-156 propose an extended transaction model for the J2EE platform. As of now, no implementations of BTP or Activity Service transaction managers work seamlessly with J2EE servers. It will be some time before the relevant JSRs are fleshed out and we see servers with embedded, standards-based transaction support for extended transaction models. Until then, our current JTA- and JTS-based flat transaction managers will have to suffice.

Source of this material

This is material from Chapter 14: Transaction Management from the book Java Web Services Architecture (ISBN: 1-55860-900-8) written by James McGovern, Sameer Tyagi, Michael Stevens, and Sunil Mathew, published by Morgan Kaufmann Publishers.

To access the full Table of Contents for the book

Page 5 of 5

This article was originally published on August 20, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date