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:
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.
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:
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:
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:
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 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.
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:
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
Part I: SOA and Web Services Fundamentals
The Evolution of SOA
Web Services and Primitive SOA
Part II: SOA and WS-* Extensions
Web Services and Contemporary SOA (Part I: Activity Management and Composition)
Web Services and Contemporary SOA (Part II: Advanced Messaging, Metadata, and Security)
Part III: SOA and Service-Orientation
Principles of Service-Orientation
Part IV: Building SOA (Planning and Analysis)
SOA Delivery Strategies
Service-Oriented Analysis (Part I: Introduction)
Service-Oriented Analysis (Part II: Service Modeling)
Part V: Building SOA (Technology and Design)
Service-Oriented Design (Part I: Introduction)
Service-Oriented Design (Part II: SOA Composition Guidelines)
Service-Oriented Design (Part III: Service Design)
Service-Oriented Design (Part IV: Business Process Design)
Fundamental WS-* Extensions
Appendix A. Case Studies: Conclusion