Coordinating Web Service Transactions | Understanding Web Services Specifications and the WSE (Pro Developer)

Since one of the main goals of XML-based Web services is to enable interoperability between processes, across domains, and on different platforms, Web services introduced an ideal mechanism for implementing enterprise-level transaction-enabled applications and coordinated business processes. Since the communication between the DTC and the resource managers is already message-oriented, it makes sense to simply use SOAP messages and XML-based transaction protocols. Of course, existing enterprise applications already use platform-specific services, such as MSDTC, to coordinate transactions and long- running business processes. However, when integrating applications from disparate platforms into a single business coordination process, interoperability can become a major challenge.

To overcome these interoperability issues, object-based standards such as the X/OPEN protocol have been created to enable product-specific resource coordinators to coordinate in distributed transactions. Of course, Web services provide an ideal method for exposing existing processes so that they can participate in a coordination framework that leverages standard Web service protocols in a service-oriented architecture. And to make things even better, this coordination framework will be able to support both atomic transactions and long-running business processes, as well as support multiple coordination protocols in a single coordination.

Defining a Coordination Framework

The WS-Coordination specification proposes just this sort of flexible, extensible framework for exposing proprietary coordination processes as a service-oriented architecture. This framework enables Web service applications to participate in both atomic transactions and coordinated business processes and to be informed of the outcome of these coordinations. As in traditional distributed transactions, at the core of the WS-Coordination specification is the coordination service. This coordinator , which provides the traditional services of the DTC, includes the following Web service components :

Activation service Enables applications to request a coordination context that is used to coordinate multiple Web services in a single distributed transaction or coordinated business process
Registration service Enables Web service applications to register into a coordinated transaction or coordinated business process
Protocol Service Implements the supported coordination protocols used to carry out the coordination

Coordination Context

The coordination context contains all of the coordination- related information for a coordinated process and is defined in a SOAP message by the CoordinationContext element in the SOAP message header. This header element is derived from the more general Context element type, which is defined in WS- Coordination and used to track the contexts of messages. When Web service messages are exchanged during the execution of a coordinated process, each message must include a CoordinationContext element, which can contain the following information:

Timestamp As defined by the WS-Security addendum specification. The timestamp can be used to verify the freshness of the information.
Identifier As defined by the WS-Security addendum specification. The identifier can be a GUID or other identifier used to reference a particular coordination context.
Coordination type Defines the type of coordination process that the coordination context has been defined for.
Registration service Address of the service from which another Web service can request entry into the coordinated process.
Other coordination-specific information The CoordinationContext element is extensible and can be used to carry other application-specific information relating to the coordinated process.

The following is an example of a coordination context in a SOAP request 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:RegistrationService> 
 <wsu:Address 
 >http://example.com/mycoorservice/registration</wsu:Address> 
 </wscoor:RegistrationService> 
 </wscoor:CoordinationContext> 
   
 </soap:Header> 
 <soap:Body> 
   
 </soap:Body> 
 </soap:Envelope>

Notice that the CoordinationContext header element in this request message contains all of the information needed for the requesting service to register into the coordination, including the address of the registration service, the coordination type, and the identifier of the existing coordination context.

Coordination Service

As previously mentioned, the coordination service is responsible for creating the coordination context, registering other Web services into the coordinated process, and notifying each service as to the outcome of the process. While it would seem simpler to require each participant in the coordination process to use a single coordination service, this can lead to inefficiencies when coordinating between trust domains and heterogenous platforms. Rather than requiring each service to negotiate trust with a single coordination service, a better scenario can be obtained if we allow each participant to select its own coordination service to interact with where this trust relationship already exists. In this way, the only new trust relationships that must be negotiated are between the coordination services themselves . After this trust exists, the coordination services can interact with each other on the application s behalf . I will discuss how Web services establish and verify trust in Chapter 8.

Creating a Coordination Context

The first part of the coordination service is the activation service. The activation service responds to requests from Web services that want to initiate a coordination context for some coordinated process, which can be either a coordinated business process or a distributed transaction among a group of Web services. When requesting a new coordination context from the activation service, the Web service initiating the coordination must send a CreateCoordinationContext message. A CreateCoordinationContext request message looks like the following:

 <?xml version="1.0" encoding="utf-8"?> 
 <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"> 
 <soap:Header> 
   
 </soap:Header> 
 <soap:Body> 
 <wscoor:CreateCoordinationContext 
 xmlns:wscoor="http://schemas.xmlsoap.org/ws/2002/08/wscoor"> 
 <wscoor:ActivationService> 
 <wsu:Address 
 >http://example.com/mycoorservice/activation</wsu:Address> 
 </wscoor:ActivationService> 
 <wscoor:RequesterReference> 
 <wsu:Address>http://example.com/myapp1</wsu:Address> 
 </wscoor:RequesterReference> 
 <wscoor:CoordinationType> 
 http://schemas.xmlsoap.org/ws/2003/09/wsat 
 </wscoor:CoordinationType> 
 </wscoor:CreateCoordinationContext> 
 </soap:Body> 
 </soap:Envelope>

The activation service responds to the request for a new coordination context with a CreateCoordinationContextResponse message that contains both the identifier for this new coordination context and the address of the coordinator s registration service. The response message to this request looks like the following:

 <?xml version="1.0" encoding="utf-8"?> 
 <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"> 
 <soap:Header> 
   
 </soap:Header> 
 <soap:Body> 
 <wscoor:CreateCoordinationContextResponse 
 xmlns:wscoor="http://schemas.xmlsoap.org/ws/2002/08/wscoor"> 
 <wscoor:RequesterReference> 
 <wsu:Address>http://example.com/myapp1</wsu:Address> 
 </wscoor:RequesterReference> 
 <wscoor:CoordinationContext> 
 <wsu:Identifier> 
 uuid:09233523-345b-4351-b623-5dsf35sgs5d6 
 </wsu:Identifier> 
 <wscoor:CoordinationType> 
 http://schemas.xmlsoap.org/ws/2003/09/wsat 
 </wscoor:CoordinationType> 
 <wscoor:RegistrationService> 
 <wsu:Address 
 >http://example.com/mycoorservice/activation<wsu:Address> 
 </wscoor:RegistrationService> 
 </wscoor:CoordinationContext> 
 </wscoor:CreateCoordinationContextResponse> 
 </soap:Body> 
 </soap:Envelope>

After a coordination has been created between the Web service that initially requested the context and its chosen coordination service, that service can enlist a second Web service application into the coordinated transaction or business process, as long as the second Web service is able to handle the CoordinationContext header.

Enrolling in an Existing Coordination

After creating the coordination context, the Web service that initiated the context must then register into the coordination context by sending a Register request message to the registration service, the address of which was contained in the CreateCoordinationContextResponse message. This Register message looks like the following:

 <?xml version="1.0" encoding="utf-8"?> 
 <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"> 
 <soap:Header> 
   
 </soap:Header> 
 <soap:Body> 
 <wscoor:Register 
 xmlns:wscoor="http://schemas.xmlsoap.org/ws/2002/08/wscoor"> 
 <wscoor:RegistrationService> 
 <wsu:Address> 
 http://example.com/mycoorservice/registration 
 </wsu:Address> 
 </wscoor:RegistrationService> 
 <wscoor:RequesterReference> 
 <wsu:Address>http://example.com/myapp1</wsu:Address> 
 </wscoor:RequesterReference> 
 <wscoor:ProtocolIdentifier> 
 http://schemas.xmlsoap.org/ws/2003/09/wsat 
 </wscoor:ProtocolIdentifier> 
 <wscoor:ParticipantProtocolService> 
 <wsu:Address> 
 http://example.com/2PCservice 
 </wsu:Address> 
 </wscoor:ParticipantProtocolService> 
 </wscoor:Register> 
 </soap:Body> 
 </soap:Envelope>

After successfully enrolling the application into participating in the transaction using the requested protocol, the registration service sends the following response message back to the application:

 <?xml version="1.0" encoding="utf-8"?> 
 <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"> 
 <soap:Header> 
   
 </soap:Header> 
 <soap:Body> 
 <wscoor:RegisterResponse 
 xmlns:wscoor="http://schemas.xmlsoap.org/ws/2002/08/wscoor"> 
 <wscoor:RequesterReference> 
 <wsu:Address>http://example.com/myapp1</wsu:Address> 
 </wscoor:RequesterReference> 
 <wscoor:CoordinatorProtocolService> 
 <wsu:Address> 
 http://Business456.com/mycoordinationservice/coordinator 
 </wsu:Address> 
 </wscoor:CoordinatorProtocolService> 
 </wscoor:RegisterResponse> 
 </soap:Body> 
 </soap:Envelope>

Notice that this response message, using the requested coordination protocol, contains the address of the protocol service that will handle the actual coordination with the Web service.

When enrolling a second Web service into an existing coordination context, the initiating Web service sends a process-related SOAP request message to the second Web service; the SOAP header of this request message contains a CoordinationContext element. As I mentioned before, this CoordinationContext element contains information about the type of coordination operation being used as well as the registration service that should be used to enroll. To enroll in this existing coordination context, the second application also sends a Register request message to the registration service. In its Register request message, the second application can request to use a different coordination protocol than did the first application.