Web Services Atomic Transaction support


 

+

Search Tips   |   Advanced Search

 

Web Services Atomic Transaction (WS-AT) support provides transactional quality of service to the Web services environment for distributed global transactions.

Global transaction demarcation is provided by standard enterprise application use of the 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 service if the appropriate application deployment descriptors have been set.

If the appserver is the system hosting the target endpoint for a Web services request that contains a WS-AT CoordinationContext, the application server automatically establishes a subordinate JTA transaction in the target runtime environment that becomes the transactional context under which the target Web services application runs.


To ensure that a client always sends WS-AtomicTransaction context when it makes an outbound service request, associate a policy set with the client, where...

Alternatively, if we know that the client always invokes remote endpoints that include the WS-AtomicTransaction ATAssertion policy type attribute, configure the client to apply the WS-Policy configuration of the provider so that the client adopts the mandatory policy of the provider automatically.

To ensure that any requests that a Web services provider receives include a WS-AtomicTransaction context, associate a policy set with the provider, where...

To ensure that a client or provider never use WS-AtomicTransaction context, associate a policy set with the client or provider, where...

If there is no policy set associated with a client or provider, or the WS-Transaction policy type is not included in the policy set, the default WS-Transaction behavior is used.

In WAS v7, WS-AT contexts cannot be started from a non-recoverable client process.

 

Application design considerations

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

An atomic transaction coordinates resource managers that isolate transactional updates by holding transactional locks on resources. Therefore, it is generally not recommended that WS-AT transactions are 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...

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 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.

If a service that is running under a requester's WS-AT transaction returns a fault, the exception handler of the requester decides whether the transaction can progress and chooses whether to mark the transaction rollback-only. If the requester is running in the appserver, 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.

For JAX-RPC applications, there are some application descriptors that need to be set

The JAX-RPC run time supports WS-AT 1.0.

WAS v7 supports...

We can configure the default WS-Transaction spec level to use for outbound requests if the spec level that the server requires cannot be determined from the provider policy. This applies to outbound requests that include a WS-AT or WS-BA coordination context

For JAX-WS applications, enable WS-AT support by...

The JAX-WS run time supports...

When the JAX-WS runtime receives an inbound request, both WS-Transaction 1.0 and WS-Transaction 1.1 spec levels are supported.

When an outbound JAX-WS request is sent, only one spec level can be used. If WS-Transaction WS-Policy assertions are available, either from the WSDL of the target Web service, or from the WS-Transaction policy type of the client, the spec level that is applicable to the client and the target Web service is used. For example, if the hosting environment of the target Web service supports only WS-Transaction 1.0, WS-AT 1.0 is used. If both spec levels are applicable, or if no WS-Transaction WS-Policy assertions are available, the default WS-Transaction spec level that is set in the Transaction service settings is used.

To move a JAX-WS application that was using WS-AT 1.0 to use WS-AT 1.1, alter the policy set that is attached to the application; you do not have to change the application.

The default behavior when there is no effective policy set, or when the WS-Transaction policy type is not included in the effective policy set, is as follows:

Application developers do not have to explicitly register WS-AT participants. The appserver run time 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 coordinated atomically by the transaction service.

If a JTA transaction is active on the thread when a Web services application request is made, the transaction is propagated across on the Web services request and established in the target environment. This process is similar to the distribution of transaction context over IIOP.

Any transactional work performed in the target environment becomes part of the same global transaction.

 

WS-Transaction policy assertions

If we configure the policies for the WS-Transaction protocol for a provider, this configuration affects the assertions that are included in any WSDL generated for the Web service with which the policy type is associated. The WS-Policy assertion used to describe the transactional requirements of a client or provider that uses WS-AtomicTransaction is ATAssertion. If the WS-Transaction policy type has a WS-AtomicTransaction setting of Mandatory or Supports, a policy assertion is included in the WSDL.

The appserver can also parse, understand, and apply such assertions that are in WSDL that it parses.

The following example shows WSDL where the WS-AtomicTransaction ATAssertion indicates that an endpoint must be invoked with WS-AT context included in the request message, and that the context can be in WS-Transaction 1.0 or 1.1 format.

There are two namespaces and there are two assertions; one for each WS-Transaction spec level, using the WS-Policy ExactlyOne operator to show that the client must choose which spec level to use. 

<wsdl:definitions targetNamespace="bank.example.com"
                  xmlns:tns="bank.example.com"
                  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
                  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
                  xmlns:wsat11="http://docs.oasis-open.org/ws-tx/wsat/2006/06" 
                  xmlns:wsat10="http://schemas.xmlsoap.org/ws/2004/10/wsat" 
                  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
                  oasis-200401-wss-wssecurity-utility-1.0.xsd">

     <wsp:Policy wsu:Id="ATPolicy">

         <wsp:ExactlyOne>
             <wsat11:ATAssertion />
             <wsat10:ATAssertion />
             <!-- omitted assertions -->
         </wsp:ExactlyOne />

     </wsp:Policy>

     <!-- omitted elements -->

     <wsdl:binding name="BankBinding" type="tns:BankPortType">

          <!-- omitted elements -->
          <wsdl:operation name="TransferFunds">
               <wsp:PolicyReference URI="#ATPolicy" wsdl:required="true"/>
               <!-- omitted elements -->
          </wsdl:operation>

     </wsdl:binding>

</wsdl:definitions>



 

Related concepts

Use WS-Transaction policy to coordinate transactions or business activities for Web services
Web Services Business Activity support in the appserver
Learn about WS-Transaction

 

Related tasks

Set the WS-Transaction policy
Set Web Services Transaction support in a secure environment

 

Related


WS-Transaction policy settings

 

Related information

Create policy sets
Attach a policy set to a service artifact