Coordination

Every activity introduces a level of context into an application runtime environment. Something that is happening or executing has meaning during its lifetime, and the description of its meaning (and other characteristics that relate to its existence) can be classified as context information.

The more complex an activity, the more context information it tends to bring with it. The complexity of an activity can relate to a number of factors, including:

• the amount of services that participate in the activity
• the duration of the activity
• the frequency with which the nature of the activity changes
• whether or not multiple instances of the activity can concurrently exist

A framework is required to provide a means for context information in complex activities to be managed, preserved and/or updated, and distributed to activity participants. Coordination establishes such a framework (Figure 6.14).

Figure 6.14. Coordination provides services that introduce controlled structure into activities.

Note

This section derives concepts from the WS-Coordination specification. Some examples of WS-Coordination SOAP headers are provided in the WS-Coordination overview section of Chapter 16.

In Plain English

I decide to get Chuck, Bob, and Jim to wash my car. When we're all ready to go, I assign each of them a simple task, as follows:

ChuckGather equipment.

BobPrepare the water.

JimWash the car.

You might recall each of these simple tasks consists of a series of steps. Chuck's task, for instance, is comprised of the following steps:

1.	Locate bucket.
2.	Locate sponge.
3.	Locate hose.

Completion of the first step is required before Bob can begin his task of preparing the water. Completion of Chuck's and Bob's tasks is required for Jim to start washing the car. However, allowing Bob to start on his task after Chuck completes only the first step of his task will allow both Chuck and Bob to complete their respective tasks at around the same time. The benefit here is that Jim can start his task sooner than if Bob had to wait for Chuck to fully complete all steps in his task.

To coordinate the complex activity of car washing in an efficient manner, Chuck needs to communicate to Bob when he has located the bucket. Because Bob may not be immediately available and because Chuck doesn't want to go looking for Bob to hand over the bucket, Chuck tells me that the bucket is ready. Chuck then continues with his other work, and when I see Bob next, I can relay the status of the bucket availability to him.

In this scenario, the bucket availability status is considered context information that I managed. Because a separate context manager (me) was in place, Chuck was alleviated of the responsibility of remembering and communicating the context information to Bob. This freed Chuck to continue with his other work. It also spared Bob from having to directly locate and communicate with Chuck to get the context information. Finally, my knowledge of who was doing what in this car washing process also would be classified as context information.

 

6.3.1. Coordinator composition

WS-Coordination establishes a framework that introduces a generic service based on the coordinator service model (Figure 6.15). This service controls a composition of three other services that each play a specific part in the management of context data.

Figure 6.15. The coordinator service composition.

The coordinator composition consists of the following services:

• Activation service Responsible for the creation of a new context and for associating this context to a particular activity.
• Registration service Allows participating services to use context information received from the activation service to register for a supported context protocol.
• Protocol-specific services These services represent the protocols supported by the coordinator's coordination type. (This is further explained in the next sections.)
• Coordinator The controller service of this composition, also known as the coordination service.

6.3.2. Coordination types and coordination protocols

Each coordinator is based on a coordination type, which specifies the nature and underlying logic of an activity for which context information is being managed. Coordination types are specified in separate specifications. The WS-Coordination framework is extensible and can be utilized by different coordination types, including custom variations. However, the two coordination types most commonly associated with WS-Coordination are WS-AtomicTransaction and WS-BusinessActivity. (Concepts relating to these specifications are explained in the upcoming Atomic transactions and Business activities sections.)

Coordination type extensions provide a set of coordination protocols, which represent unique variations of coordination types and consist of a collection of specific behaviors and rules. A protocol is best viewed as a set of rules that are imposed on activities and which all registered participants must follow.

6.3.3. Coordination contexts and coordination participants

A context created by the activation service is referred to as a coordination context. It contains a collection of information that represents the activity and various supplementary data.

Examples of the type of data held within a coordination context include:

• a unique identifier that represents the activity
• an expiration value
• coordination type information

A service that wants to take part in an activity managed by WS-Coordination must request the coordination context from the activation service. It then can use this context information to register for one or more coordination protocols. A service that has received a context and has completed registration is considered a participant in the coordinated activity.

6.3.5. The activation and registration process

The coordination service composition is instantiated when an application service contacts the activation service (Figure 6.16). Via a CreateCoordinationContext request message, it asks the activation service to generate a set of new context data. Once passed back with the ReturnContext message, the application service now can invite other services to participate in the coordination. This invitation consists of the context information the application service originally received from the activation service.

Figure 6.16. The WS-Coordination registration process.

Any Web service in possession of this context information may issue a registration request to the registration service. This allows the service to enlist in a coordination based on a specific protocol. (Protocols are provided by separate specifications and are discussed later in this chapter as part of the Atomic transaction and Business activities sections.) Upon a successful registration, a service is officially a participant. The registration service passes the service the location of the coordinator service, with which all participants are required to interact. At this time, the coordination service is also sent the address of the new participant.

6.3.5. The completion process

The application service can request that a coordination be completed by issuing a completion request message to the coordination service. The coordinator, in turn, then issues its own completion request messages to all coordination participants. Each participant service responds with a completion acknowledgement message (Figure 6.17).

Figure 6.17. The WS-Coordination completion process.

 

6.3.6. Coordination and SOA

A coordinator-based context management framework, as provided by WS-Coordination and its supporting coordination types, introduces a layer of composition control to SOAs (Figure 6.18). It standardizes the management and interchange of context information within a variety of key business protocols.

Figure 6.18. Coordination as it relates to other parts of SOA.

Coordination also alleviates the need for services to retain state. Statelessness is a key service-orientation principle applied to services for use within SOAs. Coordination reinforces this quality by assuming responsibility for the management of context information.

Case Study

In the previous case study example, we established the individual process steps that comprised a complex activity. Once the processing of this activity enters the TLS environment, TLS employs a context management system to coordinate the flow of the message through its internal services.

As shown in Figure 6.19, coordination is applied to the following steps:

3.	The Accounts Payable Service uses the Vendor Profile Service to validate the invoice header data. If the data is valid, the invoice document is attached to the vendor account.
4.	The Accounts Payable Service extracts taxes and shipping fees from the invoice document. These values, along with the invoice total, are submitted to the Ledger Service. The Ledger Service is responsible for updating the General Ledger and numerous sub-ledgers, such as the Accounts Payable Ledger.

Figure 6.19. The TLS Accounts Payable, Vendor Profile, and Ledger Services being managed by a coordination.

 

The atomic transaction coordination type is used to coordinate these processing steps, as explained in the next two case studies.

SUMMARY OF KEY POINTS

• Complex activities tend to introduce the requirement for context data and the subsequent need for this data to be managed and coordinated at runtime.
• WS-Coordination provides a context management framework using a standardized service composition spearheaded by a coordinator service.
• Specialized implementations of this framework are realized through the use of coordination types, such as WS-AtomicTransaction and WS-BusinessActivity.
• By introducing an activity management layer to SOA, coordination promotes service statelessness and supports the controlled composition of complex activities.