Distributed transactions with WS-AtomicTransaction and JTA

The aim of this article is to introduce Web Services Transaction (WS-Transaction) concepts and its interaction with transaction services, specifically the J2EE transactional model, Java Transaction API (JTA). It references WebSphere Application Server in its examples and describes an interoperability scenario recently shown at a technology demo hosted by Steve Mills and Bill Gates.

Introduction
Web services have become increasingly pervasive in the development of today's enterprise applications, and yet traditionally they have not had the same level of support services that enterprises depend upon when building J2EE applications, in particular, transaction services. This article outlines how a transaction service can seamlessly interface with Web services with the help of Web Service Transactions in a J2EE environment using the Java Transaction API.

This article briefly outlines both this new Web services technology and the proven traditional transaction technology. It explains how they can inter-operate across a distributed J2EE environment and even across different transaction architectures and implementations.

This article assumes that you have an intermediate understanding of transaction service concepts (such as ACID properties, commits/rollbacks, transaction demarcation, etc.). For further information on transaction services, specifically the JTS, please reference the article Java theory and practice: Understanding JTS -- An introduction to transactions also found on developerWorks (see Resources). A good book which I would also recommend for more general information on transactions is Principles of Transaction Processing by Philip Bernstein and Eric Newcomer (see Resources).

What is the Java Transaction API (JTA)?
JTA is the J2EE solution to transaction services. Essentially it is part of the J2EE model that describes transactional interfaces, such as the UserTransaction interface used directly by the developer or via the J2EE container to ensure that business logic can run reliably running.

The three main interfaces the JTA has are the UserTransaction interface, the TransactionManager interface and the Transaction interface. These interfaces share common transactional operators, such as commit() and rollback(), but also contain specific transactional operators, such as suspend(), resume() and enlist(), that only appear on particular interfaces to allow a level of access control in the implementation. For example, the UserTransaction can perform transaction demarcation and basic transaction manipulation, while the TransactionManager can perform context management. This article only requires you to have a basic understanding of the JTA.

Advantages of the JTA?
The JTA is a well-defined transaction service that provides J2EE application developers with a service they can use directly. Alternatively, an application can be deployed such that the container will manage the transactional behaviour on behalf of the developer. In the latter case, the developer can concentrate on the business logic of their application and have the transactional logic taken care of by the J2EE container.

The advantage of a well-modelled transaction service is that the four ACID properties are always maintained for every single transaction. Although this is an implementation-specific issue, WebSphere Application Server offers the ability to preserve these ACID properties for every transaction, imported or otherwise, regardless of the number of concurrent transactions.

Limitations of the JTA?
As experienced by all transactional architectures, it is very difficult to effectively propagate one set of transactions to other transaction services that do not share the same model, while retaining the atomic units of work. In our case, the JTA is modelled to run on top of the Java Transaction Service (JTS) that deals with the propagation of inbound and outbound transaction requests.

As the JTS is a Java implementation of the Object Transaction Service (OTS) defined by CORBA, it can only interface with another OTS model. Therefore a transaction can only be propagated to another OTS-compliant target which typically is another J2EE implementation. As the JTA and JTS specifications do not place restrictions on the underlying implementation of these interfaces (as long as they conform to the model), transactions can be safely propagated between two J2EE-compliant application servers without risk of losing their ACID properties. However, J2EE servers are not required to deal with non-J2EE invocations.

There are some J2EE servers that can make exceptions; for instance, the WebSphere Application Server will correctly deal with an inbound CORBA request with an associated CORBA compliant transaction, propagating this transaction onto the thread and performing transactional work under its context. In most cases, however, you have to look beyond JTA and JTS when trying to move between transactional models, which is where Web services come in.

What is a Web Service?
A Web Service is an object that can be deployed on an accessible server as part of an application for use by internal or external clients. A Web Service is described by its Web Service Definition Language (WSDL). This defines the input and output parameter usage of a Web Service using XML-based invocations, typically using the SOAP protocol. For example, a client can view the WSDL that has been published by the server and create client code to invoke the Web Service. Once this has been done, it can invoke a method of the Web Service by passing it a SOAP message containing information such as the method name, including any parameters it requires. The return value will be passed back in another SOAP message and extracted by the client.

Advantages of using a Web Service?
It is not important which language a Web Service is written in, as the WSDL does not define language or programming model-specific details (Java and J2EE technologies, for example). This gives the author of both the Web Service and the client the flexibility to choose his preferred solution.

Let's compare a Web Service with an Enterprise JavaBean (EJB) component. An EJB component requires RMI-compiled code to be accessible to the client so it can create local stub objects as its proxies. This will therefore require a redistribution of stubs to all clients every time they change. With Web services however, you use WSDL, so the clients are able to create their own client invocation code and need no server classes on the local classpath in order to perform an invocation. This model provides a much neater method invocation process. EJBs, being part of the J2EE model, have to be invoked using a Java client, preferably a J2EE managed client. Web services on the other hand can be invoked by any client code which can create a well-formed SOAP request. Thus, for example, a Web Service deployed on a J2EE server can be invoked using a C++ client.

Limitations of a Web Service?
As the nature of a Web Service request (SOAP over HTTP) is very different to other method invocations (for example, an EJB invocation using RMI over IIOP), the supporting code to perform distributed transactions has not been available until recently. This has been a major problem when using Web services as part of a distributed transactional enterprise application. Essentially, it has not been possible for a Web Service to operate in a transaction context started prior to the Web Service invocation, nor has it been possible for the Web Service to propagate a transaction context to another component.

So what's the problem?
If Web services are to be used in industry, it is imperative that they can be trusted to work in a reliable and predictable way when working in a transactional environment. Until now Web services have only been capable of using transactions independantly of other components -- demarcated within the Web Service method scope and subject to the rules of its underlying transaction implementation -- and have not been physically able to leave the Web Service or enter another Web Service. Enterprise applications have transactions flowing between enterprise components all the time. This needs to be the standard for Web services to ensure they are used correctly to avoid altering your programming style by taking advantage of the Web Service functionality only to neglect the transactional support you have come to rely on and use in all our rigid enterprise applications.

So what's the solution?
The solution is a new technology called Web Services Transaction (WS-Transaction). This technology is the bridge between Web services and transactions. It is able to coordinate a transactional context that can be used by Web Services, other J2EE components such as EJB components and even other non-J2EE transaction services which support WS-Transaction.

WS-Transaction is a specification which extends the Web Services Coordination (WS-Coordination) specification to define a coordination that supports atomic transactions.

What is WS-Coordination
WS-Coordination is a coordination framework to enable distributed participants to agree on a universal outcome over their individual activities.

Essentially this means that when distributed participants (two application servers on different machines for example), that would otherwise be unable to complete in a controlled manner, would be able to use WS-Coordination to group the actions of each participant together, and further manage them by ensuring that they all agree to a singular outcome for all the actions that they have individually performed under this coordination context.

A coordination context can be considered as an identifier under which activities are performed. To draw a parallel, the concept is very similar to a transaction context. When transactional work is done, it is managed under the transaction context and completed when this context is called to commit or rollback. Additional information which the coordination context contains are a coordination identifier, details about the coordination type and coordination protocols including port information so the coordination service can be accessed. These terms are defined below.

The coordination service, or Coordinator, consists of three further services: the activation service, the registration service and the coordination protocol services. The activation service supports the CreateCoodinationContext operation to allow new coordination contexts to exist. The registration service supports a Register operation to allow participants to perform work under the coordination context. The coordination protocol services support the use of coordination protocols that define the behaviour and the communication between the Coordinator and the participants.

The coordination type is a defined set of coordination behaviours that specifies sets of coordination protocols and how the Coordinator should drive completion. The WS-Transaction specification describes two coordination types - the Atomic Transaction (AT) and the Business Agreement (BA). Each of these coordination types contain coordination protocols. For example, the Atomic Transaction coordination type contains coordination protocols such as the two-phase commit protocol (Durable2PC) and the phaseZero protocol (Volatile2PC). These are both protocols that you might wish to use in an environment that supports atomic transactions.

The Business Agreement coordination type offers a different type of functionality. It is designed to be used over a much longer timeframe, unlike atomic transactions which you normally associate with having very short lifetime. An example Business Agreement protocol is itself called Business Agreement and is a compensation protocol.

What is the relationship between WS-Coordination and WS-Transaction?
WS-Coordination is the underlying framework which makes distributed outcome of activities between participants possible. WS-Transaction defines coordination types, such as Atomic Transaction, which use the WS-Coordination framework to define rules which both the Coordinator and participants must adhere to during their communications. It is important this distinction is made between the two.

The main coodination flows between two applications and a Coordinator can be seen below in Figure 1.

Figure 1. Basic Coordination Flows.

App1 makes a request to the activation service on a Coodinator.
The Coordinator begins a new activity and responds to App1 with its CoordinationContext (XML information of the Coordinator).
App1 makes a request to the registration service to register to use coordination protocol X.
App1 invokes App2 in whatever way it wishes, passing across the CoordinationContext for the Coordinator.
App2 makes a request to the registration service (using parameters such as port information found in the CoordinationContext passed by App1) to register to use coordination protocol Y.
App2 finishes its work and control returns back to App1, and the activity is called to complete.
The Coordinator responds to App1 using protocol X style messages.
The Coordinator responds to App2 using protocol Y style messages.

Coordinator interposition
In a real world situation, where Web services could be transactional and distributed, the originator (App1) of the Coordinator will pass the CoordinationContext to whomever they would like to be a participant (App2) in the activity. The receiver of this context has two options: They could use the Coordinator which has already been created (Ca), or if they wish they could create a new Coordinator passing in the original CoordinationContext. The second option would then make the new Coordinator (Cb) a proxy Coordinator for App2. It would contain the same activity identifier as Coordinator Ca, but when App2 registers for the Durable2PC protocol to its Coordinator, Cb, its request is forwarded directly to Coordinator Ca. Similarly on completion, the prepare and commit messages would be passed from Coordinator Ca to Coordinator Cb before finally arriving at App2, which has registered itself with the Durable2PC protocol.

Please refer to section 4.1 AT3.1 Example Atomic Transaction Message Flow in the WS-Transaction specification to see a very good example of WS-Coordination flows between Applications and interposed Coordinators (see Resources).

Web Services Transaction: AtomicTransaction (WS-AtomicTransaction)
WS-AtomicTransaction is a specific coordination type for atomic transactions which provides a set of coordination protocols. These coordination protocols are:

Completion
CompletionWithAck
Volatile2PC
Durable2PC
OutcomeNotification

The coordination type is specified when the coordination context is created, but the coordination protocol is not specified until registration. Any participant can register for any number of the coordination protocols and should send and receive appropriate messages defined by the protocol. For example, if a participant registered with the Coordinator for the Durable2PC protocol, upon completion a prepare message will be sent to this participant and they will be expected to vote in a similar fashion to a normal transactional resource. For information on each of these protocols and their state diagrams, please refer to the WS-Transaction specification, section 4. AT3 Coordination protocols (see Resources).

How can a JTA transaction and WS-AtomicTransaction be used together?
As the JTA and JTS are implementation-specific, the example I will use will be WebSphere Application Server V5.0.2 with the WS-Transaction Tech Preview. This scenario will have two machines, both with an application server running on each, as shown in Figure 2. Application server A has a Bean Managed Transaction (BMT) EJB component deployed and running. Application server B has a Web Service deployed and running. The EJB component starts a transaction using the UserTransaction interface provided by the JTA. It performs transactional work to an XA-compliant database (Step 1) and then makes a request to the Web Service on application server B using SOAP/HTTP (Step 2). The Web Service performs work to an XA-compliant database (Step 3) and then returns back to the EJB component (Step 4) which commits the transaction, again using the UserTransaction interface. All the transactional work performed by the EJB and Web Service to the databases has been contained within the scope of an activity created by the Coordinator just before the invocation to the Web Service (Step 2), and it has been committed preserving all ACID properties and as if it were a single unit of work.

Let's look at the following two domains -- the J2EE domain and the Web Service domain. While in the J2EE domain the transaction model used is the JTA. In the Web Service domain the transactional model used is WS-AtomicTransaction. WebSphere Application Server considers a Java Web Service to be a J2EE object, implying the implementation of the Web Service is therefore the J2EE domain, while the invocation is in the Web Service domain. In the WebSphere domain it is always the responsibility of the model being used (JTA or WS-AtomicTransaction) to drive the protocol correctly.

Figure 2 shows how easy it is to include Web services in a transactional enterprise application and also how seamless it is to the user who has not been put out by a single line of code running this Web Service in the imported transaction context.

Figure 2. Using a JTA transaction with a WS-AtomicTransaction transaction.

Please Note: The EJB component is running in a managed environment (EJB container) and the Web Service is JSR 109-compliant.

Does it only work with the JTA?
WS-Coordination capitalizes on the advantage that it is a Web Service itself by virtue of its XML-based invocation. As the protocol used to call WS-Coordination operations is SOAP, the message content is plain text in an XML format. This means that when passed across to the Web Service using HTTP, the client details, such as the programming language, could not possibly be determined just by the SOAP packet itself. Therefore WS-AtomicTransaction will be able to interface with any other transaction service coded using any programming language which supports WS-AtomicTransaction.

This inter-operability of WS-AtomicTransaction across transaction services and programming languages was shown at a recent Web services demo hosted by IBM and Microsoft. Figure 3 shows a scenario demonstrating this technology.

In Figure 3 there is a .NET server beginning a non-JTA transaction making Web Service invocations to two WebSphere Application Servers and another .NET server. Each of the application servers use their underlying transaction service to perform transactional work. Every time you invoke a Web Service you switch to using WS-Transaction. When the originator completes the transaction, you use the WS-Transaction technology to coordinate each of the participants to ensure that they all complete as if they were a single unit of work.

Figure 3. Example topology of a WS-AtomicTransaction scenario in the Steve Mills and Bill Gates Web services demonstration.

Summary
In this article you have learned about the basic concepts of WS-Coordination and WS-Transaction. Web services have not been able to use transactions in a distributed environment until now. WS-Transaction allows transactional work performed by a Web Service as part of a wider activity spanning components, application servers, and even implementations, as shown by the IBM and Microsoft Web services demo.

With the support of WS-Transaction we are able to reliably use Web services as part of our enterprise applications now that it has been brought in-line with other enterprise components for transactional support.

Resources

Download the WS-AtomicTransaction Tech Preview from alphaWorks.
Find the WS-Coordination Specification and the WS-Transaction Specification on developerWorks.
Find more information about the IBM and Microsoft Web services demo.
Read the related article, "Transactions in the world of Web services, Part 1" (developerWorks, August 2002).
Get more information in "Java theory and practice: Understanding JTS -- An introduction to transactions" (developerWorks, March 2002).
Principles of Transaction Processing, by Philip Bernstein and Eric Newcomer, gives a very good introduction to transaction concepts.

About the author
Author,

Simon Maple has been a Functional Verification Tester in WebSphere for over 2 years, concentrating his work on testing the WebSphere Application Server Transaction Service. He is the Functional Verification Testing team leader for transactions and activities in WebSphere based in Hursley, recently testing WS-AtomicTransaction (now downloadable on alphaworks) using WebSphere v5.0.2. You can reach Simon at Simon.Maple at uk.ibm.com.

developerWorks > Web services | Java technology

About IBM | Privacy | Terms of use | Contact