The WS-Coordination Context Management Framework
by Thomas Erl

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.


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.

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 coordinator's 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.

SOA Design Patterns by Thomas Erl
Foreword by Grady Booch
With contributions from David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy, Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky, and others.
Web Service Contract Design & Versioning for SOA by Thomas Erl, Anish Karmarkar, Priscilla Walmsley, Hugo Haas, Umit Yalcinalp, Canyang Kevin Liu, David Orchard, Andre Tost, James Pasley
SOA Principles of Service Design by Thomas Erl
Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services by Thomas Erl
Service-Oriented Infrastructure:On-Premise and in the Cloud by Raj Balasubramanian, Benjamin Carlyle, Thomas Erl, Cesare Pautasso
Next Generation SOA:A Real-World Guide to Modern Service-Oriented Computing by Pethuru Cheliah, Thomas Erl, Clive Gee, Robert Laird, Berthold Maier, Hajo Normann, Leo Shuster, Bernd Trops, Clemens Utschig, Torsten Winterberg
SOA with .NET & Windows Azure: Realizing Service-Orientation with the Microsoft Platform by David Chou, John deVadoss, Thomas Erl, Nitin Gandhi, Hanu Kommalapati, Brian Loesgen, Christoph Schittko, Herbjorn Wilhelmsen, Mickey Williams
SOA Governance:
Governing Shared Services On-Premise & in the Cloud
by Stephen Bennett, Thomas Erl, Clive Gee, Anne Thomas Manes, Robert Schneider, Leo Shuster, Andre Tost, Chris Venable
SOA with Java by Raj Balasubramanian, David Chou, Thomas Erl, Thomas Plunkett, Satadru Roy, Philip Thomas, Andre Tost
Modern SOA Methodology: Methods for Applying Service-Orientation On-Premise & in the Cloud by Raj Balasubramanian, David Chou, Thomas Erl, Thomas Plunkett, Satadru Roy, Philip Thomas, Andre Tost
Cloud Computing: Concepts, Technology & Architecture by Thomas Erl, Zaigham Mahmood, Ricardo Puttini
Cloud Computing Design Patterns by Thomas Erl, Amin Naserpour

For more information about these books, visit: www.servicetechbooks.com


Arcitura Education Inc.
Arcitura Education Inc. is a leading global provider of progressive, vendor-neutral training and certification programs, providing industry-recognized certification programs for a range of certifications.
For more information:
www.arcitura.com
SOA Certified Professional (SOACP)
The books in this series are part of the official curriculum for the SOA Certified Professional program.
For more information:
www.soaschool.com
Cloud Certified Professional (CCP)
The books in this series are part of the official curriculum for the Cloud Certified Professional program.
For more information:
www.cloudschool.com
Big Data Science Certified Professional (BDSCP)
The books in this series are part of the official curriculum for the Big Data Science Certified Professional program.
For more information:
www.bigdatascienceschool.com/