 by Thomas Erl |
WS-* Specifications |
 |
|
|
The WS-Coordination Context Management Framework |
|
| The loosely coupled nature of Web services requires an approach to maintaining a persistent activity context that differs from traditional distributed environments. In order to preserve the integrity of an activity, a context management service is required. To apply this context for the management of transactions, structured protocols are required to dictate behavioral aspects of services that participate in the activity. |
| For this reason, the WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity specifications were developed. The former provides a framework for context management, and the latter two supply specific transaction protocols that utilize this framework. In this paper we will explore the WS-Coordination context management framework. WS-AtomicTransaction and WS-BusinessActivity are described in separate papers. |
| When a group of Web services collectively interact to execute a unit of programming logic, it will often be required for these services to share a common context. By doing so, the task or activity receives an identity that is propagated to each participating service. This context not only defines the runtime existence of the activity, it also establishes a level of control over how the task being executed can be processed. |
| Every service 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. |
|
SOA: Principles of Service Design by Thomas Erl  An in-depth guide dedicated to service engineering with a thorough exploration of the design principles that comprise the service-orientation design paradigm (including a comparison with object-orientation). 
Service-Oriented Architecture:Concepts, Technology, and Design by Thomas Erl The first "how-to" guide to building SOA, providing coverage of WS-* specifications, .NET and J2EE platforms, and step-by-step processes for service-oriented analysis and design. 
Service-Oriented Architecture:A Field Guide to Integrating XML and Web Services by Thomas Erl The best-selling guide to service-oriented integration, providing hundreds of integration strategies and over sixty best practices. For more information about either book, visit: www.soabooks.com |
About SOA Systems
SOA Systems Inc. provides strategic SOA consulting services and offers a comprehensive SOA training program. For more information see: www.soasystems.com www.soatraining.com |
|
The coordinator composition |
| WS-Coordination establishes a framework that introduces a generic service based on the coordinator service model. This service controls a composition of three other services that each play a specific part in the management of context data. |
|
| 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 coordinators coordination type. (This is further explained below.) |
| Coordinator The controller service of this composition, also known as the coordination service. |
|
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 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. |
|
Coordination contexts and coordination participants |
| A context created by the activation service is referred 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 can then 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. |
|
The activation and registration process |
| The coordination service composition is instantiated when an application service contacts the activation service. 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 can now invite other services to participate in the coordination. This invitation consists of the context information the application service originally received from the activation service. |
| 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 activity 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. |
|
|
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. |
|
| To learn more about the WS-AtomicTransaction and WS-BusinessActivity specifications that provide protocols for WS-Coordination, visit the WS-Standards.com home page and locate the corresponding papers. |
|
|
|
|
|
|
| Home | Copyright © 2003-2007 SOA Systems Inc. |