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.

WS-AT support restrictions

In this version of WebSphere Application Server, WS-AT contexts cannot be propagated through firewalls and 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.

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. There are some application deployment descriptors that need to be set appropriately, as described in Configuring transactional deployment attributes.

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 [Version 6.0.2]

The SOAP messages that are used to control the WS-AT and WS-COOR protocols are normally communicated using the default web container transport chains. When global security is enabled, the default secure chain, usually WCInboundDefaultSecure, is used, otherwise the default non-secure chain, usually WCInboundDefault, is used.

If you are interoperating with servers other than WebSphere Application Server, you might need to configure an alternative chain for these protocol messages in order to control, for example, the port or the SSL repertoire used. For example, if the system with which you are interoperating requires that protocol messages use HTTP over SSL with client certificate authentication, configure a chain with an appropriate SSL repertoire for inbound protocol messages, and configure WebSphere Application Server to use the same SSL repertoire for outbound web service requests.




Subtopics
[z/OS] Enabling Web Services Atomic Transaction support
Related concepts
Transaction support in WebSphere Application Server
Related tasks
Configuring Web Services Atomic Transaction support in a secure environment
Concept topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 9:31:45 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-mp&topic=cjta_wstran
File name: cjta_wstran.html