Coordination Protocols

Whereas WS-Coordination defines the framework for coordinating transactions and long-running business processes using Web services, the actual process that a coordinator uses to communicate with an application is defined by the coordination protocol chosen by the application. The coordination protocol defines a series of messages between the coordinator and each application that is participating in the coordination. In a single coordination, each participating Web service application can request to use a different protocol when communicating with the coordinator.

The same applies if multiple coordinators are involved in a single coordination. For example, if a Web service named Bettie wants to join in a coordinated process with a Web service named Anne, Bettie might want to use Joe as the coordination service, and Anne might want to use Tom as the coordinator. This can be further complicated by the fact that Bettie wants to use protocol A with Joe, and Anne wants to use protocol B with Tom. That means that Joe must register with Tom to use protocol A, and Tom must register with Joe to use protocol B. Figure 7-2 should make this message exchange a bit more clear.

Figure 7-2: Coordination context with multiple coordination services

When an application requests a new coordination context, it specifies in the CreateCoordinationContext request message the type of coordination that the application wants to create, which is the following for an atomic transaction:

• Atomic transaction Requested by the CoordinationType value http://schemas.xmlsoap.org/ws/2003/09/wsat

A single coordination type can support multiple coordination protocols, and each application can request a different protocol, as long they all belong to the same coordination type.

Atomic Transaction Protocols

The atomic transaction type includes what we typically think of in the enterprise as transactions, or processes that help to maintain the ACID properties of data. As I mentioned earlier, atomic transactions are relatively short running because they usually require resources to be locked for the duration of the process. WS-AtomicTransaction defines the following protocols for atomic transactions, and it explicitly defines the message exchanges for each of these protocols.

Completion

This protocol is used when an application wants the coordinator either to attempt to commit or to abort an atomic transaction. When an application wants to use the completion protocol, the Request message to the coordinator s registration service must reference http://schemas.xmlsoap.org/ws/2003/09/wsat#Completion in the ProtocolIdentifier element. The following summarizes the message exchange between the requesting application and the coordinator when the completion protocol is used:

1. The application registers with the coordinator to use the completion protocol in the current coordination.

2. The application sends either a Commit message to the coordinator to request that a transaction be committed or a Rollback message requesting a rollback of the current transaction.

3. The coordinator returns either a Committed message if the transaction was successfully committed or an Aborted message if the transaction was aborted.

Each message in this process must reference the coordination context for the transaction in the message and must contain the appropriate message element in the body of the message, as in the following excerpt from a Committed message:

 <?xml version="1.0" encoding="utf-8"?> 
 <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"> 
 <soap:Header> 
   
 <wscoor:CoordinationContext 
 xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility" 
 xmlns:wscoor="http://schemas.xmlsoap.org/ws/2002/08/wscoor"> 
 <wsu:Expires> 
 2003-10-31T13:20:00.000-05:00 
 </wsu:Expires> 
 <wsu:Identifier> 
 uuid:c38a0a61-50ff-4493-b200-b68b883ddcb4 
 </wsu:Identifier> 
 <wscoor:CoordinationType> 
 http://schemas.xmlsoap.org/ws/2003/09/wsat 
 </wscoor:CoordinationType> 
 </wscoor:CoordinationContext> 
 </soap:Header> 
 <soap:Body> 
 <wstx:Committed xmlns:wstx=http://schemas.xmlsoap.org/ws/2003/09/wsat /> 
 </soap:Body> 
 </soap:Envelope> 

Notice that the Committed element is qualified by the wstx prefix.

Two-Phase Commit

Two-phase commit is the main protocol used for completing transactions while maintaining the ACID properties of data since by requesting that data be written to disk it ensures that all participants in the transaction will be able to commit their part of the transaction, even if a hardware failure occurs during the transaction. AtomicTransaction specifies two versions of the two-phase commit protocol, known as volatile and durable. The volatile two-phase commit protocol is used for coordinating volatile resources, such as an in-memory cache, and the durable two-phase commit protocol is used for coordinating durable resources, such as a database, from which recovery is possible. The difference between the two is that the coordinator must receive a response from all participants using the volatile two-phase commit protocol before sending the Prepare message to any participants using the durable two-phase commit protocol. This is to avoid the extra expense of having the durable resources prepare their data when a volatile resource may no longer be available. When an application wants to use the volatile two-phase commit protocol, the Request message to the coordinator s registration service must reference http://schemas.xmlsoap.org/ws/2003/09/wsat#Volatile2PC in the ProtocolIdentifier element, and when an application wants to use the durable two-phase commit protocol, the Request message to the coordinator s registration service must reference http://schemas.xmlsoap.org/ws/2003/09/wsat#Durable2PC . The following summarizes the message exchange between the requesting application and the coordinator when the durable two- phase commit protocol is used:

1. The application registers with the coordinator to use the two-phase commit protocol in the current coordination.

2. The coordinator sends either a Prepare message telling the application to write the current transaction changes to disk in preparation for the transaction being committed or a Rollback message that tells the application to undo any changes in this transaction. At this stage, the application can send an Aborted message to the coordinator if a failure has occurred and the transaction must be aborted.

3. The application returns a Prepared message to the coordinator when it s in a state in which its changes have been made and it can commit, a ReadOnly message if the data is read-only and the changes cannot be committed, or an Aborted message if it decides that it cannot otherwise commit the transaction.

4. After all resources in the transaction have prepared to commit the transaction, the coordinator sends a Commit message, which tells the application to commit the transaction. If even one resource is not ready to commit the transaction, the coordinator must issue a Rollback message that tells the application to undo any changes in this transaction.

5. After committing the changes, the application returns a Committed message to the coordinator. At this point, the transaction is complete, and the coordinator might log the returned Committed messages for future reference.

Any Rollback commands issued by the coordinator must be replied to with an Aborted response message from the application. Each message in this process must reference the coordination context for the transaction in the message and must contain the appropriate message element in the body of the message, as in the following excerpt from a Prepared message:

 <?xml version="1.0" encoding="utf-8"?> 
 <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"> 
 <soap:Header> 
   
 <wscoor:CoordinationContext 
 xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility" 
 xmlns:wscoor="http://schemas.xmlsoap.org/ws/2002/08/wscoor"> 
 <wsu:Expires> 
 2003-10-31T13:20:00.000-05:00 
 </wsu:Expires> 
 <wsu:Identifier> 
 uuid:c38a0a61-50ff-4493-b200-b68b883ddcb4 
 </wsu:Identifier> 
 <wscoor:CoordinationType> 
 http://schemas.xmlsoap.org/ws/2003/09/wsat 
 </wscoor:CoordinationType> 
 </wscoor:CoordinationContext> 
 </soap:Header> 
 <soap:body> 
 <wstx:Prepared 
 xmlns:wstx=http://schemas.xmlsoap.org/ws/2003/09/wsat /> 
 </soap:Body> 
 </soap:Envelope> 

Returning Errors

If an error occurs during the coordination process using any of these protocols, an error message is returned, which might look like the following in the case of an error that occurs during the phase zero protocol:

 <?xml version="1.0" encoding="utf-8"?> 
 <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"> 
 <soap:Header> 
   
 <wscoor:CoordinationContext 
 xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility" 
 xmlns:wscoor="http://schemas.xmlsoap.org/ws/2002/08/wscoor"> 
 <wsu:Expires> 
 2003-10-31T13:20:00.000-05:00 
 </wsu:Expires> 
 <wsu:Identifier> 
 uuid:c38a0a61-50ff-4493-b200-b68b883ddcb4 
 </wsu:Identifier> 
 <wscoor:CoordinationType> 
 http://schemas.xmlsoap.org/ws/2003/09/wsat 
 </wscoor:CoordinationType> 
 </wscoor:CoordinationContext> 
 </soap:Header> 
 <soap:body> 
 <wstx:Error 
 xmlns:wstx=http://schemas.xmlsoap.org/ws/2003/09/wsat> 
 wstx:PhaseZeroFailure 
 </wstx:Error> 
 </soap:Body> 
 </soap:Envelope> 

Long-Running Business Activities

Atomic transactions are a critical foundation of any enterprise application, and they re often the building blocks of longer-running business processes or activities. Such coordinated business processes typically move through a workflow, in which steps along the way can involve individual atomic transactions. However, there may be considerable time between steps in the process. This length of time makes it impossible to use atomic transactions for these processes because locking the data throughout the duration of a transaction would prevent other transactions from running.

At the time that this book went to press, the only proposed specification designed to leverage the WS-Coordination framework was WS-AtomicTransaction. However, a white paper jointly published by Microsoft and IBM titled Secure, Reliable, Transacted Web Services: Architecture and Composition (available at http://msdn.microsoft.com/library/en-us/dnwebsrv/html/wsoverview.asp ), references a forthcoming specification named WS-Business-Activity that will describe a specific set of protocols that plug into the WS-Coordination model to implement long-running, compensation-based transaction protocols.

Since long-running business activities are often described as orchestrations, I need to briefly discuss the Business Process Execution Language for Web Services (BPEL4WS) specification ( http://msdn.microsoft.com/library/en-us/dnbiz2k2/html/bpel1-1.asp ). This specification, proposed by IBM, Microsoft, BEA Systems, SAP and Seibel Systems, defines a notation for specifying business process behavior based on Web Services and provides a language for the formal specification of business processes and business interaction protocols. In other words, BPEL4WS leverages WSDL and WS-Policy to describe the structure and behavior of a set of coordinated Web services that implement a single, integrated business function.

BPEL4WS is an extensive specification that deals with complex business- to-business (B2B) processes, which is really outside of the scope of this book. However, I will say that the role of BPEL4WS as it relates to WS-Coordination and the upcoming WS-BusinessActivity specification is described in the Microsoft-IBM white paper such that while BPEL4WS defines a transaction model for business processes, it is WS-BusinessActivity that specifies the corresponding protocol rendering. This means that while BPEL4WS dictates how Web services coordinate in a long-running business activity and how such a process is described, WS-BusinessActivity and WS-Coordination will define how a long-running business activity handles issues like compensating actions and enrolling participants.

Since Web service interactions that rely on BPEL4WS, WS-Coordination, and WS-BusinessActivity offer a promising direction in B2B Web services, we will certainly be hearing more about this from the industry. Even today, Web service “enabled products, like the upcoming 2004 release of Microsoft s BizTalk server, are beginning to leverage the BPEL4WS specification.