WS-Coordination

In a typical business scenario, web services may be required to share information, such as security context, transaction context, and so on while participating in a composite business process. The WS-Coordination specification defines a framework for this purpose. This is an extensible framework and allows existing applications to hide their proprietary protocols while coordinating with other applications in a heterogeneous environment. It is used in conjunction with other specifications and does not provide a complete solution on its own. WS-Coordination is used whenever coordination between applications developed using different vendor specifications is desired. Such applications obviously run under different trust domains and so appropriate access control must be implemented.

The Framework

The framework defines a coordinator and a set of coordination protocols. The coordinator consists of the following three components:

• Activation service
• Registration service
• Set of coordination protocols

A service that decides to coordinate its activity with another service first creates a coordination context for the activity. This is done with the help of the activation service component. This context is then dispatched to the service with which coordination is desired. The receiving service uses the coordination context to register into the activity. This is done with the help of the registration service component. The receiving application may use the registration service component provided by the sender to register the activity. Alternatively, it may use the registration service component of any interposing, trusted coordinator. The context itself contains sufficient information that describes the behavior that the sender application will follow.

Scenario

To understand the model used by the WS-Coordination framework, we will now discuss a scenario in which two applications having their own coordinators collaborate with each other. Each application has its own coordinator, as depicted in the following figure:

The steps involved in the coordination are as follows:

1. Application A creates a coordination context by calling the CreateCoordinationContext operation on the ActivationService provided by coordinator A.
2. The coordinator returns a coordination context to application A.
3. The coordination context contains:
   • Activity identifier
   • Coordination type
   • Endpoint reference to the registration service of coordinator A
4. Application A sends a message to Application B containing the above coordination context.
5. Application B calls the CreateCoordinationContext operation on coordinator B by passing the received coordination context as input.
6. Coordinator B returns a new coordination context to application B.
7. The coordination context contains following:
   • The same activity identifier as above
   • The same coordination type as above
   • Endpoint reference to the registration service of coordinator B
8. Application B determines the coordination protocol from the coordination context.
9. Application B registers the protocol with coordinator B, thereby exchanging the endpoint references between application B and the protocol service B.
10. Coordinator B now forwards the registration to Coordinator A’s registration service, exchanging the endpoint references between the protocol services A and B.
11. The two applications now use the protocol defined in the coordination type to collaborate with each other.

The entire process is depicted in the following figure:

Note: The numbered arrows indicate the respective steps outlined above.

Having seen the coordination operation between two applications, let’s now look at the various elements provided in the schema definition.

CoordinationContext

CoordinationContext is a Context type as defined in the wscoor.xsd schema definition. The Context type defines two elements, Identifier and Expires. The Expires element specifies the expiration time for the context.

The application sends the CreateCoordinationContext message to the activation service by passing the above CoordinataionContext.

CreateCoordinationContext

The CreateCoordinationContext message defines the coordination type, the expiry time, and the current context.

CreateCoordinationContextResponse

The application receives a message from the coordinator containing the coordination response. The response structure is shown below:

<CreateCoordinationContextResponse>
  <CoordinationContext>
    <wsu:Identifier> ... </wsu:Identifier>
    <CoordinationType> ... </CoordinationType>
    <RegistrationService>
      <wsa:Address> ... </wsa:Address>
    </RegistrationService>
  </CoordinationContext>
</CreateCoordinationContextResponse>

Note that the response contains the coordination context containing the identifier, the type, and the endpoint for the registration service.

The application registers the coordination context with the registration service by sending a Register message to it.

Register

The message contains the identifier obtained from the coordinator and the address of the protocol service. The application receives a RegisterResponse in response to the Register message.

RegisterResponse

The response contains the endpoint for the protocol service provided by the coordinator.

Faults

During message communication, errors could be generated. The specification defines the following error codes:

• wscoor:InvalidState: Generated by coordinator or a participant to indicate that the endpoint has entered an invalid state
• wscoor:InvalidProtocol: Indicates that a message from an invalid protocol has been received
• wscoor:InvalidParameters: Indicates that invalid parameters have been received within a message
• wscoor:NoActivity: Sent by the coordinator to indicate that the participant has presumably ended communication
• wscoor:ContextRefused: Indicates that the received context is unacceptable
• wscoor:AlreadyRegistered: Indicates that the same protocol with the same activity is already registered

The coordinating applications receive one or more of these faults in the case of any failures. These applications are responsible for processing them and taking an appropriate action.

The WS-Coordination specifications are used along with other specifications to achieve an end-to-end solution. One of the most significant applications of this specification is to share a transaction context between multiple applications running on different platforms and developed using different vendor technologies. In the next section, we will discuss the Web Services Transaction specifications that are used along with WS-Coordination for achieving a consistent agreement on the outcome of distributed processing.