Transactions in the world of Web services, Part 2

An overview of WS-Transaction and WS-Coordination

This paper presents and illustrates a high-level overview of the Web service specifications for WS-Coordination and WS-Transaction. The new specifications outline the mechanisms required when creating reliable applications by connecting together Web services. These Web services need to participate and cooperate on the agreement of the overall application outcome. The WS-Coordination specification provides a generic foundation for Web services coordination. It provides support for standard transaction mechanisms that exist in today's marketplace. The WS-Transaction specification includes a definition of atomic and business transaction protocols. It is anticipated that additional patterns and protocols will emerge and be based on an extensible coordination framework defined in the specification. These specifications tackle the growing need for consistent support of transactions and addresses the more general requirement to guarantee the reliable coordination of operations across Web services.

Thomas Freund (tjfreund@us.ibm.com), Senior Technical Staff Member, IBM, Software Group

You can contact Tom at tjfreund@us.ibm.com.



Tony Storey (tony_storey@uk.ibm.com)IBM, Software Group

You can contact Tony at tony_storey@us.ibm.com.



01 August 2002

Background

In the paper Transactions in a world of Web services, Part 1 (see Resources), we introduced the technical concepts behind the distributed transaction model designed for Web services, as defined in the WS-Coordination and WS-Transaction specifications. This paper focuses on specific scenarios of business transactions that can apply to the Web services model.

The two main types discussed in this article are Atomic transactions that are individual transactional calls to a specific service operation, and Business transactions that generally consist of one or more atomic transactions


Atomic transactions

The scenario in Figure 1 provides an illustration of an implementation of a standard Transaction Service (that is, a Two-Phase commitment (2PC) transaction protocol commonly used in database systems) using WS-Coordination and WS-Transaction. It shows a simple application operating with a database where the database operations are published as Web services. A similar scenario is contained in the IBM Web Services Toolkit (WSTK; see Resources) and shows how the AddressBook demo was converted to support WS-Coordination and WS-Transaction.

Figure 1. A scenario of Atomic transactions
Figure 1. A scenario of Atomic transactions

This example scenario is broken down by each phase of the transaction with details of the steps within each phase. These phases are in turn: Activation, Registration, and Completion/Coordination.

Activation

Step 1: An application creates a transactional activity using the WS-Coordination framework's Activation Service.

The CreateCoordinationContext request is sent from application to the Activation Service as shown in Listing 1.

Listing 1. CreateCoordinationContext request sent
<soapenv>
 <soapbody>
  <wscoor:CreateCoordinationContext>
    <ActivationService>
        <Address>
             http://myActiviationService 
        </Address>      
    </ActiviationService>
    <RequesterReference>
        <Address>
             http://myApplicationProgram
        </Address>
    </RequesterReference>
    <CoordinationType>
         http://xml-soap.org/2002/xx/AtomicTransaction
    </CoordinationType>
   </wscoor:CreateCoordinationContext>
 </soapbody>
<soapenv>

The Coordination Service returns a CoordinationContext that is used to uniquely identify the transaction (and includes the address of the Registration) as shown in Listing 2. The CoordinationContext is used on subsequent calls to the Web service, and uniquely identifies which activity the request is on behalf of.

Listing 2. Coordination Service returns a context
<soapenv>
 <soapbody>
   <wscoor:CreateCoordinationContextResponse>
    <RequesterReference>
        <Address>
             http://myApplicationProgram
        </Address>
    </RequesterReference>
    <CoordinationContext>
        <Identifier>
             http://myCoordinationService/ts/activity1
        </Identifier>
        <CoordinationType>
             http://xml-soap.org/2002/xx/AtomicTransaction
        </CoordinationType>
        <RegistrationService>
             <Address>
                  http://myCoordinationService/tm/myRegistrationService
             <Address>             
        </RegistrationService>
    </CoordinationContext>
  </wscoor:CreateCoordinationContextResponse>
 </soapbody>
</soapenv>

Step 2: The application registers using the Registration Service specified in the CoordinationContext as shown in Listing 3.

  • The application defines itself as the artifact responsible driving the Completion protocol to complete the activity.
  • The role of coordinator is defined within the Coordination Service (the CoordinatorRef is returned on the call -- which the application uses later to invoke the Completion protocol).
Listing 3. The application sends a registration request to the Registration service
<soapenv>
 <soapbody>
  <wscoor:Register>
    <RegistrationService>
        <Address>http://myRegistrationService</Address>
    </RegistrationService>
    <RequesterReference>
        <Address>http://myApplicationProgram</Address>
    </RequesterReference>
    <ProtocolIdentifier>
        http://xml-soap.org/2002/xx/AtomicTransaction/Completion
    </ProtocolIdentifier>
    <ParticipantProtocolService>
        <Address>http://myApplicationProgram</Address>
    </ParticipantProtocolService>
  </wscoor:Register>
 </soapbody>
</soapenv>

The Registration Service returns the address of the Coordination Service.

Listing 4. The Registration service returns the address
<soapenv>
 <soapbody>
  <wscoor:RegisterResponse>
     <RequesterReference>
          <Address>
               http://myApplicationProgram
          </Address>
     </RequesterReference>
	 <CoordinatorProtocolService>
	     <Address>
		  http://myCoordinator
	     </Address>	
	 </CoordinatorProtocolService>
  </wscoor:RegisterResponse>
 </soapbody>
</soapenv>

Step 3: The application performs some operation on a Web service

The message includes an CoordinationContext SOAP Header that will be used by the Resource to uniquely identify the specific activity issuing the request.

Listing 5. Application performs an operation on the Web service
URL:http//myhost/myBank
<soapenv>
 <soapheader>
    <wscoor:CoordinationContext 
       <wsme:Identifier>
             http://myCoordinationService/ts/activity1
       </wsme:Identifier>
       <wsme:Expires>
              2002-06-30T13:20:00.000-05:00
       </wsme:Expires>
       <wscoor:CoordinationType>
               http://xml-soap.org/2002/06/AtomicTransaction 
       </wscoor:CoordinationType>
       <wscoor:RegistrationService>
               <Address>
                    http://myRegistrationService   
                </Address>
        </wscoor:RegistrationService>
 </soapheader>
 <soapbody>
     <debitAccount ... />
 </soapbody>
</soapenv>

Registration

Step 4: Register a Resource with the Registration Service for processing.
The first time a Resource processes an CoordinationContext it registers with the WS-Coordination Registration Service (using the RegistrationRef previously given when the activity was first created ) as shown in Listing 5.

Listing 6. Registering the resource with the Registration service
<soapenv>
 <soapbody>
  <wscoor:Register>
    <RegistrationService>
        <Address>http://myRegistrationService</Address>
    </RegistrationService>
    <RequesterReference>
        <Address>http://myDatabaseWebService</Address>
    </RequesterReference>
    <ProtocolIdentifier>
        http://xml-soap.org/2002/xx/AtomicTransaction/2PC
    </ProtocolIdentifier>
    <ParticipantProtocolService>
        <Address>http://myResource</Address>
    </ParticipantProtocolService>
  </wscoor:Register>
 </soapbody>
</soapenv>

Step 5: Registration Service acknowledges
The Registration Service acknowledges the registration and returns the Coordinator reference (CoordinatorRef) as shown in Listing 6, which is used to notify the Coordinator in the event of a fault or recovery condition.

Alternatively, the target can choose to create a subordinate coordinator (using a create operation specifying a coordination context of the superior coordinator). The subordinator coordinator registers with the coordinator specified on the received coordination context and the resource registers with the subordinate coordinator.

Listing 7. Registration service sends Coordinator reference
<soapenv>
 <soapbody>
  <wscoor:RegisterResponse>
     <RequesterReference>
          <Address>
               http://myDatabaseWebService
          </Address>
     </RequesterReference>
	 <CoordinatorProtocolService>
	     <Address>
		  http://myCoordinator
	     </Address>	
	 </CoordinatorProtocolService>
  </wscoor:RegisterResponse>
 </soapbody>
</soapenv>

Step 6: The Web service performs the operation and returns results (see Listing 7)

Listing 8. The service performs the operation
<soapenv>
 <soapheader>
   <wscoor:CoordinationContext/>
 </soapheader>
 <soapbody>
    <debitAccountResult ... />
 </soapbody>
</soapenv>

Note: The CoordinationContext is included on the response to allow information to be returned in the extension element -- certain transaction implementations exploit the ability to return implementation specific information.

The application sends additional messages to the current Web service or different Web services as required.

Completion/Coordination

Listing 8. The application performs a CommitCoordinatorRefCreateCoordinationContext

<soapenv>
 <soapheader>
   <CoordinatorProtocolService>
	     <Address>
		  http://myCoordinator
	     </Address>	
   </CoordinatorProtocolService>
 </soapheader>
   <wstx:Notification>
      type=AtomicTransaction
      portType=Completion
      message=Commit
  </wstx:Notification>
 </soapbody>
</soapenv>

Step 8: Coordinator performs the agreement protocol
The Coordinator performs the agreement protocol (for example, 2PC protocol), which first solicits the resource status via Prepare followed by transmitting a final outcome which sends a Commit/Rollback (2PC protocol) message to each resource that registered. The ResourceRef that was sent during registration to locate the correct Resource instance that needs to be Commited/Aborted.

Listing 9. Sending a Prepare message
<soapenv>
 <soapheader>
   <ParticipantProtocolService>
	     <Address>
		  http://myResource
	     </Address>	
   </CoordinatorProtocolService>
 </soapheader>
   <wstx:Notification>
      type=AtomicTransaction
      portType=2PC
      message=Prepare
  </wstx:Notification>
 </soapbody>
</soapenv>

Step 9: The Resource sends a Prepared notice
The Resource votes positively for the two-phase commitment protocol and returns Prepared to the Coordinator (coordinatorRef)

Listing 10. Resource sends a Prepared notice
<soapenv>
 <soapheader>
   <CoordinatorProtocolService>
	     <Address>
		  http://myCoordinator
	     </Address>	
   </CoordinatorProtocolService>
 </soapheader>
   <wstx:Notification>
      type=AtomicTransaction
      portType=2PC
      message=Prepared
  </wstx:Notification>
 </soapbody>
</soapenv>

Step 10: Coordinator collects the votes
The coordinator collects all the votes and determines the transaction can be Committed (see Listing 11).

Listing 11. Coordinator sends a Commit message
<soapenv>
 <soapheader>
   <ParticipantProtocolService>
	     <Address>
		  http://myResource
	     </Address>	
   </CoordinatorProtocolService>
 </soapheader>
   <wstx:Notification>
      type=AtomicTransaction
      portType=2PC
      message=Commit
  </wstx:Notification>
 </soapbody>
</soapenv>

Step 11: Resource acknowledges the Commit
The resource acknowledges the Commit and returns a Committed message to the Coordinator (CoordinatorRef)

Listing 12. Resource sends Committed message
<soapenv>
 <soapheader>
   <CoordinatorProtocolService>
	     <Address>
		  http://myCoordinator
	     </Address>	
   </CoordinatorProtocolService>
 </soapheader>
   <wstx:Notification>
      type=AtomicTransaction
      portType=2PC
      message=Committed
  </wstx:Notification>
 </soapbody>
</soapenv>

Summary of Atomic transactions

The scenario infers several fundamental requirements on a Web service implementation:

  • The usage throughout the distributed environment of a 'universally' understood Activation Service definition (that is, a context that includes both an identifier and an coordinator reference)
  • The ability to establish and reference a coordinator (or coordinators), that is, an endpoint address understood though out the network
  • (Optional -- not shown) For efficiency through the reduction of network flows, the ability to construct a subordinate node that uses the Activation Service definition for the controlling the outcome of some part of distributed activity.
  • (Optional -- not shown) The ability to optimize flows by including protocol messages on the regular application message flow.
  • A defined relationship for context and endpoint association (that is, an agreed mechanism for exchanging context and establishing an execution environment for the target Web service.)

Business Transactions

The Business Transactions scenario (as shown in Figure 2) provides an illustration of an implementation a long-running Transaction (that is, a Business Activity protocol) using WS-Transaction. The task within a Business Transactions generally consist of a number of atomic transactions. The resources updated by the atomic transaction must be undone should the overall business transaction fail. Compensation is one common methodology for dealing with this and for implementing a business transaction protocol. The following text explains the differences in activation and registration from the steps needed for an atomic transaction protocol, and highlights actions required during completion processing to support a long running business transaction.

Figure 2. The Business Transactions scenario
Figure 2. The Business Transactions scenario

Activation

Step 1: Application creates a business activity
An application creates a business activity using the WS-Coordination framework's Activation Service. The CreateCoordinationContext request is sent from application to the Activation Service as shown in Listing 12.

Listing 12. Application sends a CreateCoordinationContext request
<soapenv>
 <soapbody>
  <wscoor:CreateCoordinationContext>
    <ActivationService>
        <Address>
             http://myActiviationService 
        </Address>      
    </ActiviationService>
    <RequesterReference>
        <Address>
             http://myApplicationProgram
        </Address>
    </RequesterReference>
    <CoordinationType>
         http://xml-soap.org/2002/xx/BusinessActivity
    </CoordinationType>
   </wscoor:CreateCoordinationContext>
 </soapbody>
<soapenv>

Step 2: Coordination Service returns a CoordinationContext
The Coordination Service returns an CoordinationContext that is used to uniquely identify the business. The CoordinationContext is used on subsequent calls to define a relationship to the subsequent atomic transactions.

Listing 13. Coordination service returns a CoordinationContext
<soapenv>
 <soapbody>
   <wscoor:CreateCoordinationContextResponse>
    <RequesterReference>
        <Address>
             http://myApplicationProgram
        </Address>
    </RequesterReference>
    <CoordinationContext>
        <Identifier>
             http://myCoordinationService/ts/activity1
        </Identifier>
        <CoordinationType>
             http://xml-soap.org/2002/xx/BusinessActivity
        </CoordinationType>
        <RegistrationService>
             <Address>
                  http://myCoordinationService/tm/myRegistrationService
             <Address>             
        </RegistrationService>
    </CoordinationContext>
  </wscoor:CreateCoordinationContextResponse>
 </soapbody>
</soapenv>

Step 3: Application creates an activity
An application creates an activity for the business task using the Coordination Framework's Activation Service and uses an extension of create to indicate the NestedCreate option to specify the business task is related to the overall business activity (that is, the task is a child of the parent activity). The create specifies the CoordinationContext from steps 1 and 2. The CreateCoordinationContext request is sent from application to the Activation Service as shown in Listing 14.

Listing 14. Application sends CreateCoordinationContext
<soapenv>
 <soapbody>
  <wscoor:CreateCoordinationContext>
    <ActivationService>
        <Address>
             http://myActiviationService 
        </Address>      
    </ActiviationService>
    <RequesterReference>
        <Address>
             http://myApplicationProgram
        </Address>
    </RequesterReference>
    <CoordinationType>
         http://xml-soap.org/2002/xx/BusinessActivity
    </CoordinationType>
   </wscoor:CreateCoordinationContext>
   <CurrentContext>
        <Identifier>
             http://myCoordinationService/ts/activity1
        </Identifier>
        <CoordinationType>
             http://xml-soap.org/2002/xx/BusinessActivity
        </CoordinationType>
        <RegistrationService>
             <Address>
                  http://myCoordinationService/tm/myRegistrationService
             <Address>             
        </RegistrationService>
   </CurrentContext>
   <myActivationService:NestedCreate/>
 </soapbody>
<soapenv>

Step 4: Coordination Service returns a CoordinationContext
The Coordination Service returns a CoordinationContext that is used to uniquely identify the business task . The CoordinationContext is used on subsequent calls to the Web service for the business task .

Listing 15. Coordination Service returns a CoordinationContext
<soapenv>
 <soapbody>
   <wscoor:CreateCoordinationContextResponse>
    <RequesterReference>
        <Address>
             http://myApplicationProgram
        </Address>
    </RequesterReference>
    <CoordinationContext>
        <Identifier>
             http://myCoordinationService/ts/activity2
        </Identifier>
        <CoordinationType>
             http://xml-soap.org/2002/xx/BusinessActivity
        </CoordinationType>
        <RegistrationService>
             <Address>
                  http://myCoordinationService/tm/myRegistrationService
             <Address>             
        </RegistrationService>
    </CoordinationContext>
  </wscoor:CreateCoordinationContextResponse>
 </soapbody>
</soapenv>

Step 5: The application performs some operation on a Web service
The message includes an "CoordinationContext" SOAP Header for the business transaction that will be used by the Resource.

Listing 16. SOAP Header with CoordinationContext
URL:http//myhost/myBank
<soapenv>
 <soapheader>
    <wscoor:CoordinationContext
    <sequence>
       <CoordinationContext-Parent(Activity1)/>
       <CoordinationContext-Child (Activity2/> 
     </sequence>   
 </soapheader>
 <soapbody>
     <debitAccount ... />
 </soapbody>
</soapenv>

A task created within the scope of an activity forms a hierarchy. When a Web service is invoked the context information describing the relationship is included on the operation. The example shows the inclusion of the CoordinationContext sequence in the SOAP message.

Registration

Within the scope of the business task an atomic transaction is executed as described in previous section on Atomic transactions.

Step 6: Business task registers with the Business activity
After processing the status response to the Commit (from the Atomic transactions section, Step 11), the business task then registers with the business activity . The registration allows a compensation operation to be invoked should the overall business activity fail.

Listing 17. A compensation registration message when business activity fails
<soapenv>
 <soapbody>
  <wscoor:Register>
    <RegistrationService>
        <Address>http://myRegistrationService</Address>
    </RegistrationService>
    <RequesterReference>
        <Address>http://myBusinessTask</Address>
    </RequesterReference>
    <ProtocolIdentifier>
        http://xml-soap.org/2002/xx/BusinessActivity/2PC
    </ProtocolIdentifier>
    <ParticipantProtocolService>
        <Address>http://myResource</Address>
    </ParticipantProtocolService>
  </wscoor:Register>
 </soapbody>
</soapenv>

Step 7: Registration Service sends a response
The Registration Service returns the bpCoordinatorRef in the registration response

Listing 18. Registration services sends a bpCoordinatorRef reference
<soapenv>
 <soapbody>
  <wscoor:RegisterResponse>
     <RequesterReference>
          <Address>
               http://myBusinessTask
          </Address>
     </RequesterReference>
	 <CoordinatorProtocolService>
	     <Address>
		  http://myCoordinator
	     </Address>	
	 </CoordinatorProtocolService>
  </wscoor:RegisterResponse>
 </soapbody>
</soapenv>

Completion/Coordination

Step 8: Business Activity checks which tasks have completed
The Business Activity then determines which Business Tasks have been successful by issuing a Complete to determine the outcome.

Listing 19. Business activity issues a Complete message
<soapenv>
 <soapheader>
   <ParticipantProtocolService>
	     <Address>
		  http://myResource
	     </Address>	
   </ParticipantProtocolService>
 </soapheader>
   <wstx:Notification>
      type=BusinessActivity
      portType=BusinessAgreementwithComplete
      message=Complete
  </wstx:Notification>
 </soapbody>
</soapenv>

Step 9: The Business Task responds that it has Completed.

Listing 20. Business Task sends the Completed message
<soapenv>
 <soapheader>
   <CoordinatorProtocolService>
	     <Address>
		  http://myCoordinator
	     </Address>	
   </CoordinatorProtocolService>
 </soapheader>
   <wstx:Notification>
      type=BusinessActivity
      portType=BusinessAgreementwithComplete
      message=Completed
  </wstx:Notification>
 </soapbody>
</soapenv>

Step 10: (optional) Application determines to abandon transaction
Let us suppose in this case, the application determines the overall business activity should be abandoned and tells the coordinator to abandon the business transaction, we pick up the flow from the bpCoordinator.

Listing 21. Application abandons transaction
<soapenv>
 <soapheader>
   <ParticipantProtocolService>
	     <Address>
		  http://myResource
	     </Address>	
   </CoordinatorProtocolService>
 </soapheader>
   <wstx:Notification>
      type=BusinessActivity
      portType=BusinessAgreementwithComplete
      message=Compensate
  </wstx:Notification>
 </soapbody>
</soapenv>

Step 11: (optional) Business tasks performs a Compensation operation
The business task performs the Compensation by performing some recovery or fault handling to undo the affects of the atomic transaction and acknowledges the Compensate request and returns Compensated to the Coordinator (coordinatorRef)

Listing 22. Business Tasks sends Compensation message
<soapenv>
 <soapheader>
   <CoordinatorProtocolService>
	     <Address>
		  http://myCoordinator
	     </Address>	
   </CoordinatorProtocolService>
 </soapheader>
   <wstx:Notification>
      type=BusinessActivity
      portType=BusinessAgreementwithComplete
      message=Compensated
  </wstx:Notification>
 </soapbody>
</soapenv>

Summary

Transactions are one of the most fundamental concepts in delivering reliable application processing. Web services require a flexible and extensible mechanism for controlling requests and outcomes in addition to the behavior offered by traditional distributed and database transaction models. Additionally, specific requirements for a Web services environment are support for Collaborations, Long-duration tasks, and Cross-business applications.

The WS-Coordination specification provides a coordination framework offering services for activity creation, registration and coordination. The generalized framework offers the capability for specifying the operational context of a request (or series of requests), controlling the duration of the activity and defining the participants engaged in an outcome decision.

Additionally, WS-Transaction provides a number of coordination patterns typically used within the industry to accommodate differing application:

  • Atomic Transactions: application operations on web services occur completely or not at all.
  • Business Transactions: application operations on web services exhibit a loose unit of work where results are shared prior to completion of the overall activity. The semantics of a compensate is that each participant will undo the operations it has performed within the conversation.

These styles or behaviors mechanisms are by no means complete. However, they allow sites participating in Web services to supplement their existing implementations to support more complex processing and compensation models. The sites can build on their internal transaction and business logic environments to provide the increased flexibility. Additionally the coordination service framework would allow for additional operational patterns beyond the traditional transactional model.

The sole requirement we currently place on web services is the ability for two endpoints to agree on the outcome. Multiparty "transaction" processing occurs within enterprises that use their own internal transaction and workflow models to manage operations and conversations with multiple participants.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=11691
ArticleTitle=Transactions in the world of Web services, Part 2
publish-date=08012002