WS-Coordination overview

Note

Only element descriptions are provided in this section. Concepts relating to these elements are covered in Chapter 6. If you are not interested in learning about WS-Coordination syntax at this point, then feel free to skip ahead to the Service-oriented business process design process description. This section is not a prerequisite to continue with the remainder of the book.

Provided in this section is a brief look at WS-Coordination, which can be used to realize some of the underlying mechanics for WS-BPEL orchestrations. Specifically, we describe some of the elements from the WS-Coordination specification and look at how they are used to implement the supplementary specifications that provide coordination protocols (WS-BusinessActivity and WS-AtomicTransaction).

Note that a syntactical knowledge of these languages is generally not necessary to create WS-BPEL process definitions. We discuss these languages at this stage only to provide an insight as to how WS-Coordination can be positioned within a WS-BPEL orchestration model, and to get a glimpse at some of the syntax behind the specifications we first introduced only on a conceptual level in Chapter 6.

When we explained WS-Coordination earlier, we described the overall coordination mechanism that consists of the activation service, the registration service, a coordinator, and participants that implement specific protocols. It is likely that these underlying context management services will be automatically governed by the orchestration engine platform for which you are creating a WS-BPEL process definition.

In terms of the WS-Coordination language and its two protocol documents, what may be of interest to you is the actual CoordinationContext header that is inserted into SOAP messages. You may encounter this header if you are monitoring messages or if you need to perform custom development associated with the coordination context.

Also while this section briefly discusses the WS-Coordination specification within the context of the orchestration service layer, it is important to note that this specification is a standalone SOA extension in its own right. Its use is in no way dependent on WS-BPEL or an orchestration service layer.

16.2.1. The CoordinationContext element

This parent construct contains a series of child elements that each house a specific part of the context information being relayed by the header.

Example 16.13. A skeleton CoordinationContext construct.

CoordinationContext> ... ... ... ... CoordinationContext>

...

The activation service returns this CoordinationContext header upon the creation of a new activity. As described later, it is within the CoordinationType child construct that the activity protocol (WS-BusinessActivity, WS-AtomicTransaction) is carried. Vendor-specific implementations of WS-Coordination can insert additional elements within the CoordinationContext construct that represent values related to the execution environment.

16.2.2. The Identifier and Expires elements

These two elements originate from a utility schema used to provide reusable elements. WS-Coordination uses the Identifier element to associate a unique ID value with the current activity. The Expires element sets an expiry date that establishes the extent of the activity's possible lifespan.

Example 16.14. Identifier and Expires elements containing values relating to the header.

... Identifier> http://www.xmltc.com/ids/process/33342 Identifier> Expires> 2008-07-30T24:00:00.000 Expires> ...

16.2.3. The CoordinationType element

This element is described shortly in the WS-BusinessActivity and WS-AtomicTransaction coordination types section.

16.2.4. The RegistrationService element

The RegistrationService construct simply hosts the endpoint address of the registration service. It uses the Address element also provided by the utility schema.

Example 16.15. The RegistrationService element containing a URL pointing to the location of the registration service.

RegistrationService> http://www.xmltc.com/bpel/reg RegistrationService>

16.2.5. Designating the WS-BusinessActivity coordination type

The specific protocol(s) that establishes the rules and constraints of the activity are identified within the CoordinationType element. The URI values that are placed here are predefined within the WS-BusinessActivity and WS-AtomicTransaction specifications.

This first example shows the CoordinationType element containing the WS-BusinessActivity coordination type identifier. This would indicate that the activity for which the header is carrying context information is a potentially long-running activity.

Example 16.16. The CoordinationType element representing the WS-BusinessActivity protocol.

http://schemas.xmlsoap.org/ws/2004/01/wsba

16.2.6. Designating the WS-AtomicTransaction coordination type

In the next example, the CoordinationType element is assigned the WS-AtomicTransaction coordination type identifier, which communicates the fact that the header's context information is part of a short running transaction.

Example 16.17. The CoordinationType element representing the WS-AtomicTransaction protocol.

http://schemas.xmlsoap.org/ws/2003/09/wsat