Web Services Business Activity support in the appserver


 

+

Search Tips   |   Advanced Search

 

With Web Services Business Activity (WS-BA) support in the appserver, Web services on different systems can coordinate activities that are more loosely coupled than atomic transactions. Such activities can be difficult or impossible to roll back atomically, and therefore require a compensation process if an error occurs.

Web Services protocols are defined by OASIS and provide standard ways of defining Web services applications, allowing the applications to operate independently of WAS ND, platform or programming language used.

WS-BA specifications define a set of protocols that enable Web services applications to participate in loosely coupled business processes that are distributed across the heterogeneous Web services environment, with the ability to compensate actions if an error occurs. For example, an application that sends an e-mail cannot retrieve that e-mail following a failure in the business task. However, the application can provide a business-level compensation handler that sends another e-mail advising of the new circumstances.

A business activity is a group of general tasks to link together so that the tasks have an agreed outcome.

WS-BA is a specific coordination type that defines protocols for business activities...

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

In addition to supporting the WS-BA interoperability protocol, the appserver provides a programming interface for creating business activities and compensation handlers. With this programming interface, we can specify compensation data and check or alter the status of a business activity.

We can also use this compensation facility with applications that are not Web services, as long as these applications involve communication between WASs only.

We can configure whether a client propagates, and a server receives, a WS-BA context. To ensure that a client always sends WS-BusinessActivity context when it makes an outbound service request, associate a policy set with the client, where the policy set must include the WS-Transaction policy type, and this policy type must have a WS-BusinessActivity setting of Mandatory.

Alternatively, if we know that the client always invokes remote endpoints that include the WS-BusinessActivity BAAtomicOutcomeAssertion policy type attribute, we can 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 includes a WS-BusinessActivity context, associate a policy set with the provider, where the policy set must include the WS-Transaction policy type, and this policy type must have a WS-BusinessActivity setting of Mandatory.

To ensure that a client or provider never use WS-BusinessActivity context, associate a policy set with the client or provider, where the policy set includes the WS-Transaction policy type, and this policy type must have a WS-BusinessActivity setting of Never. We might use this configuration for environments where you do not want Web services requests to create a tight coupling between a client and a provider, for example when there are requests between enterprises.

If no policy set is 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.

 

Application development considerations

No specific development tasks are required for Web services applications to take advantage of WS-BA.

For JAX-RPC applications, any EJB component configured to run under a BusinessActivity scope automatically propagates that scope when it makes an outbound JAX-RPC Web services request.

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

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

  1. creating a policy set
  2. adding the WS-Transaction policy type to the policy set
  3. optionally configuring the policy type
  4. attaching the policy set to the application or client that will be involved in the WS-BA communication.

The JAX-WS run time supports...

When the JAX-WS run time receives an inbound request, both WS-Transaction 1.0 and WS-Transaction 1.1 specification 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-BA 1.0 is used. If both specification 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.

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:

 

WS-Transaction policy assertions

If we configure the policies for the WS-BusinessActivity protocol for a provider, this affects the assertions that are includes in any WSDL that is generated for the Web service with which the policy type is associated. The WS-Policy assertion used to describe the compensation requirements of a client or provider that uses WS-BusinessActivity is BAAtomicOutcomeAssertion. If the WS-Transaction policy type has a WS-BusinessActivity 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-BusinessActivity BAAtomicOutcomeAssertion indicates that an endpoint must be invoked with WS-BA 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 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/wsba/2006/06" 
                  xmlns:wsat10="http://schemas.xmlsoap.org/ws/2004/10/wsba" 
                  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
                  oasis-200401-wss-wssecurity-utility-1.0.xsd">

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

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

     </wsp:Policy>

     <!-- omitted elements -->

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

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

     </wsdl:binding>

</wsdl:definitions>




 

Related concepts

Web Services transactions, high availability, firewalls and intermediary nodes
Use WS-Transaction policy to coordinate transactions or business activities for Web services
Transaction compensation and business activity support
Web Services Atomic Transaction support in the appserver
Learn about WS-Transaction

 

Related tasks


Create an application that uses the Web Services Business Activity support
Set a server to use business activity support
Set the WS-Transaction policy

 

Related

Business activity API
Local transaction containment considerations
WS-Transaction policy settings