Web Services Atomic Transaction support in WebSphere Application Server

The Web Services Atomic Transaction (WS-AT) support in WebSphere Application Server provides transactional quality of service to the Web services environment. This enables distributed Web service applications, and the resources they use, to take part in distributed global transactions.

The Web Services Atomic Transaction (WS-AT) support is an implementation of the following specifications on WebSphere Application Server. These specifications define a set of Web services that enable Web service applications to participate in global transactions distributed across the heterogeneous Web service environment.

The WS-AT specification is an interoperability protocol that introduces no new programming interfaces for transactional support. Global transaction demarcation is provided by standard J2EE use of the JTA UserTransaction interface. If a Web service request is made by an application component running under a global transaction, then a WS-AT CoordinationContext is implicitly propagated to the target Web service, but only if the appropriate application deployment descriptors have been set as described in Configuring transactional deployment attributes.

If WebSphere Application Server is the system hosting the target endpoint for a Web service request that contains a WS-AT CoordinationContext, then WebSphere automatically establishes a subordinate JTA transaction in the target runtime environment that becomes the transactional context under which the target Web service application executes.

The following figure, Transaction context shared between two WebSphere application servers., shows a transaction context shared between two WebSphere application servers for a Web service request that contains a WS-AT CoordinationContext.

Figure 1. Transaction context shared between two WebSphere application servers.

For transitioning users [z/OS] For transitioning users: You no longer need to create new Web container transport chains to use the WS-AT support. WebSphere Application Server is already configured to enable WS-AT, and no further configuration is required.trns

WS-AT support restrictions

In this version of WebSphere Application Server, WS-AT contexts cannot be started from a non-recoverable client process.

[z/OS] Work requests for the same WS-AT transaction sent to a server cluster are not guaranteed to be assigned to the same cluster member every time. In such cases, the work for a transaction might be handled by multiple cluster members. If transactional work of multiple cluster members contends over the same transactional resource then a deadlock condition can result.

Application design

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

Because the purpose of an atomic transaction is to coordinate resource managers that isolate transactional updates by holding transactional locks on resources, it is generally not recommended that WS-AT transactions be distributed across enterprise domains. Inter-enterprise transactions typically require a looser semantic than two-phase commit, and in such scenarios, it can be more appropriate to use a compensating business transaction, for example, as part of a Business Process Execution Language (BPEL) process, or by using Web Services Business Activity (WS-BA).

WS-AT is most appropriate for distributing transaction context across Web services deployed within a single enterprise. Only request-response message exchange patterns carry transaction context since the originator (application or container) of a transaction needs to be sure that all business tasks executed under that transaction have finished before requesting the completion of a transaction. Web services invoked 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 EJB application exceptions on transactions, as described in the EJB specification. If a service that is running under a requester's WS-AT transaction returns a fault, WebSphere Application Server does not automatically mark the transaction rollback-only. The requester's exception handler decides whether the transaction can progress and chooses whether to mark the transaction rollback-only. If the requester is running in WebSphere 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. WebSphere Application Server containers automatically mark any received transaction context rollback-only when handling a system exception that is generated by a service implementation.

Application development

There are no specific development tasks required for Web service applications to take advantage of WS-AT. For JAX-RPC applications, there are some application deployment descriptors that need to be set appropriately, as described in Configuring transactional deployment attributes. For JAX-WS applications, enable WS-AT support by creating a policy set, adding the WS-Transaction policy type to the policy set, and attaching the policy set to the services or clients that will be exploiting the WS-AT functionality.

Application developers do not need to explicitly register WS-AT participants. The WebSphere Application Server runtime takes responsibility for the registration of WS-AT participants, in the same way as the registration of XAResources in the JTA transaction to which the WS-AT transaction is federated. At transaction completion time, all XAResources and WS-AT participants are atomically coordinated by the WebSphere Application Server transaction service.

If a JTA transaction is active on the thread when a Web service Application request is made, the transaction is propagated across on the Web service request and established in the target environment. This is analogous to the distribution of transaction context over IIOP as described in the EJB specification. Any transactional work performed in the target environment becomes part of the same global transaction.

Application server administration

By default, heuristics do not flow across Web Services Atomic Transaction (WS-AT) flows. If you require heuristics to flow across WS-AT flows, you must enable this by setting the DISABLE_WSTX_HEURISTICS custom property for each application server that is involved in the distributed global transaction.

[z/OS] [AIX HP-UX Linux Solaris Windows] [Fix Pack 33 or later] If you want to preserve the global transaction id when transactions are distributed across WS-AT flows, you must set the PRESERVE_GTID_OVER_WSAT custom property for each application server that is involved in the distributed global transaction.




Related tasks
Configuring Web services transaction support in a secure environment
Enabling the flow of heuristics across Web Services Atomic Transaction flows
[z/OS] [AIX HP-UX Linux Solaris Windows] [Fix Pack 33 or later] Preserving the global transaction ID across Web Services Atomic Transaction flows
Using WS-Transaction to coordinate transactions or business activities for Web services
Related information
Creating policy sets using the administrative console
Attaching a policy set to a service artifact
Concept topic Concept topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 1:23:07 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-dist&topic=cjta_wstran
File name: cjta_wstran.html