Bridging the JTA-Web Services gap using
|Average rating: (16 ratings) |
transactions with WS-AtomicTransaction and JTA)
WebSphere FVT Team
27 January 2004
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.
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
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 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
interface. These interfaces share common transactional operators, such as
rollback(), but also contain
specific transactional operators, such as
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
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
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
Limitations of the
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
What is a Web
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
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
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
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
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.
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
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
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
- The Coordinator begins a new activity and responds to App1
CoordinationContext (XML information of the
- App1 makes a request to the registration service to register
to use coordination protocol X.
- App1 invokes App2 in whatever way it wishes, passing
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
- The Coordinator responds to App2 using protocol Y style
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:
WS-AtomicTransaction is a specific
coordination type for atomic transactions which provides a set of
coordination protocols. These coordination protocols are:
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
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
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
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
Figure 2. Using a JTA transaction with a
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
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
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
Figure 3. Example topology of a WS-AtomicTransaction
scenario in the Steve Mills and Bill Gates Web services
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
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