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.
WS-AT is a specific coordination type that defines protocols for atomic transactions.
WS-COOR specifies a CoordinationContext and a Registration service with which Participant web services may enlist to take part in the protocols offered by specific coordination types.
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.
In this version of WebSphere Application Server, WS-AT contexts cannot be started from a non-recoverable client process.
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.
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.
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.