Web Services Atomic Transaction overview

The Web Services Atomic Transaction (WS-AT) support in the application server provides transactional quality of service to the web services environment. Distributed web services applications, and the resources they use, can take part in distributed global transactions. Now WS-AT is also supported in Liberty.

Web services protocols provide standard ways of defining web services applications, and the applications can use it to operate independently of the product, platform, or programming language that is used. The WS-AT support is an implementation of the following specifications on the application server. These specifications define a set of web services that enable web services applications to participate in global transactions that are distributed across the heterogeneous web services environment.

WS-AT is a specific coordination type that defines protocols for atomic transactions. Liberty can only use the Web Services Atomic Transaction Version 1.2 specification.
Web Services Coordination (WS-COOR) specifies a CoordinationContext and a Registration service with which participant web services can enlist to take part in the protocols that are offered by specific coordination types. Liberty can only use the Web Services Coordination Version 1.2 specification.

The WS-AT support is an interoperability protocol that introduces no new programming interfaces for transactional support. Global transaction demarcation is provided by standard enterprise application use of the Java™ Transaction API (JTA) UserTransaction interface. If an application component that is running under a global transaction makes a web services request, a WS-AT CoordinationContext is implicitly propagated to the target web services, but only if the appropriate application deployment descriptors have been set, as described in the topic about configuring transactional deployment attributes.

If the application server is the system hosting the target endpoint for a web services request that contains a WS-AT Coordination Context, the application server automatically establishes a subordinate JTA transaction in the target run time environment that becomes the transactional context under which the target web services application runs.

The following figure, shows a transaction context shared between two application servers for a web services request that contains a WS-AT CoordinationContext. As the following diagram shows, the atomic transaction includes the web services client and its XA resources on application server 1 and the web services application and its XA resources on application server 2

transaction flowchart — Figure 1. Transaction context shared between two application servers

By default, if you enable WS-AT feature and begin transaction on the client side in Liberty, all the web services operations that are included in client transaction are added to the global transaction. However, if you would run any code outside the scope of the current global transaction, use the UOWManager with type UOWSynchronizationRegistry.UOW_TYPE_LOCAL_TRANSACTION. That would have the effect of suspending and resuming the global transaction around that code snippet.

Table 1. *Conditions that you can or can not use WS-AT global transaction in Liberty for client outbound*
Whether WS-AT feature is enabled	Whether transaction exists	Whether policy assertion exists in WSDL	Whether WS-AT global transaction is enabled
No	No	No	No
No	No	Yes	No with Liberty throwing an exception
No	Yes	No	No
No	Yes	Yes	No with Liberty throwing an exception
Yes	No	No	No
Yes	No	Yes (wsp: Optional="false")	No with Liberty throwing an exception
Yes	No	Yes (wsp: Optional="true")	No
Yes	Yes	No	Yes
Yes	Yes	Yes	Yes

Table 2. *Conditions that you can or can not use WS-AT global transaction in Liberty for server inbound*
Whether WS-AT feature is enabled	Whether coordination context exists in SOAP header	Whether policy assertion exists in WSDL	Whether WS-AT global transaction is enabled
No	No	No	No
No	No	Yes	No
No	Yes	No	No with Liberty throwing an exception
No	Yes	Yes	No with Liberty throwing an exception
Yes	No	No	No
Yes	No	Yes (wsp: Optional="false")	No with Liberty throwing an exception
Yes	No	Yes (wsp: Optional="true")	No
Yes	Yes	No	Yes
Yes	Yes	Yes	Yes

Application design

WS-AT is a two-phase commit transaction protocol and is suitable for short duration transactions only.

WS-AT is most appropriate for distributing transaction context across web services that are deployed in a single enterprise. Only request-response message exchange patterns carry transaction context because the originator (application or container) of a transaction must be sure that all business tasks that are run under that transaction have finished before requesting the completion of a transaction. Web services called by a one-way request never run under the transaction of the requesting client.

The effect of service faults on WS-AT transactions is similar to the effect of Enterprise JavaBeans (EJB) application exceptions on transactions, as described in the EJB specification. If a service that is running under a requester WS-AT transaction returns a fault, the application server does not automatically mark the transaction rollback-only. The exception handler of the requester chooses whether the transaction can progress and chooses whether to mark the transaction rollback-only. If the requester is running in the application server, the standard JTA or EJB APIs can be used to mark the transaction rollback-only. The service component that generates the fault might, itself, mark the transaction rollback-only before returning the fault. If the implementation of the service component encounters a system exception, it typically allows its container to handle the exception. Application server containers automatically mark any received transaction context rollback-only when handling a system exception that is generated by a service implementation.