In July 2003 a consortium of Web services vendors released the Web services Composite Application Framework (WS-CAF) to the community. WS-CAF is comprised of three specifications that together provide a means of reliably composing individual Web services into larger aggregate applications. The cornerstone of this suite is the management of stateful interactions between Web services that is the domain of the WS-Context specification. WS-CAF was subsequently submitted to OASIS and an effort to standardize the framework is currently underway.

In January 2004 a group of industry and academic practitioners from the Grid community released (the first parts of) the Web Services Resource Framework (WS-RF) specifications. WS-RF will support stateful interactions between consumers and resources hosted by Web services.

Clearly there is some overlap between the WS-Context and WS-RF approaches since both support stateful interactions on top of the stateless interaction model championed by Web Services Architecture (WSA). This article examines the different approaches taken by WS-Context and WS-RF, concentrating in particular on how each approach facilitates stateful interactions in composite Web services-based applications.

WS-Context
A composite application is a set of actions executing on a collection of Web services that executes in a specified sequence. The ability to scope arbitrary units of distributed work (known as activities) is a requirement in a variety of aspects of distributed applications, e.g., workflow, business-to-business interactions, automated business processes, and others. By scoping work, participants within an activity can determine unambiguously whether or not they are in the same activity.

In order to correlate the work of services participating within the same activity, it is necessary to propagate additional information, known as a context, to those participants. The context contains information like a unique ID and allows a series of actions to share a common outcome. In WS-Context, SOAP headers carry context information that is propagated with application-level messages. This context allows multiple participants to correlate SOAP message exchanges in order to create a larger abstraction such as a process flow, secure conversation, or other aggregation.

While context propagation is a fundamental requirement of many distributed systems, including Web services, the type of context information that is used may vary depending upon the circumstances. For example, in a transactional system it may be a URI for the coordinator, whereas for secure data interchange it may be the sender's public encryption key. Accordingly, WS-Context was developed as a standardized means of conveying context information to Web services.

The WS-Context specification also defines a context service that can be used by Web services to form composite applications. Since each requirement for context may require different information to be conveyed, WS-Context provides a minimalist (but extensible) context that allows services to register context affiliations and customize contexts on a per-activity basis.

WS-Resource Framework
The Web Services Resource Framework (WS-RF) was produced in response to input into the OGSI process by the Web services community (e.g., the WS-GAF proposal). Its authors, IBM and the Globus Alliance, proposed WS-RF as the "convergence point" between Web and Grid services, and WS-RF has been positioned as the natural evolution of the Open Grid Services Infrastructure specification (OGSI).

WS-RF follows the same conceptual model, which is based on resource sharing, that underpins OGSI, but without altering the underlying Web services specifications. WS-RF adopts many of those suggestions, especially in the areas of factorization, contextualization for modelling stateful interactions, clear separation between the concepts of a "service" and a "resource," and the unmodified use of existing Web services technologies.

The suite of specifications that makes up WS-RF has not yet been released in its entirety; only the specifications that describe resource state, resource lifetime, and notification have been made available, while those concerned with service groups, resource reference renewal, and faults will be released at a later date. Since the focus of this article is on stateful interactions, we will focus on that aspect.

In the WS-RF conceptual model, a Web service is a stateless entity "that acts upon, provides access to, or manipulates a set of logical stateful resources (documents) based on messages it sends and receives." The model encourages the explicit exposure of resources (logical or physical) across the boundaries of a service. The representation of the state of these exposed resources and the way in which consumers may interact directly with them is the primary goal of WS-RF.

Supporting Stateful Interactions
While there are similarities between the goals of WS-RF and WS-Context, the specifications opt for different approaches (resource manipulation versus service composition). In particular, they differ on how to deal with supporting stateful interactions across Web services, with WS-RF advocating a resource-oriented approach, while a service-oriented approach is advocated by WS-Context.

To demonstrate the use of WS-Context in supporting stateful interactions, we will examine the simplest use case, where a stateful interaction is held between a single service and a single consumer.

We have discussed how WS-Context defines the notion of an activity to which the context is bound. Activities ensure that all interactions on a WS-Context-aware service will be uniquely and unambiguously tied to that activity through the context. In the simple case, the context is used by the consumer to identify a particular stateful interaction, and by the service to identify a specific conversational state.

In WS-Context the context life cycle is as follows:

1. To initiate an activity, a service requests a new context from the WS-Context service via a begin message. The initiator may specify a time limit for the session, or it can be set to live until explicitly terminated. Depending on the application requirements, the context may be also created by a service automatically on receipt of the first request from a consumer.
2. The begin action will return a begun message plus a context.
3. Whenever the consumer interacts with a WS-Context-aware service, the context is propagated in a SOAP header block. The receiving service should manage any context-specific state that it requires in order to correlate messages.
4. The stateful interaction can be terminated either by timing out, or by explicitly instructing the context service to end the activity.

When a consumer engages in a stateful interaction with an identified resource, it has to include the contents of the <ReferenceProperty/> element as a header in each SOAP message sent to the service identified by the <EndpointReference/> of the same WS-Addressing construct. The service receiving the message will use that information to route invocations to the resource (see Figure 1).

WS-RF mandates that a WS-Addressing construct is opaque to its consumers and so they should not try to utilize that resource-specific information. The information about the resource is considered private to the service and should be used only by that service. In effect, WS-Addressing constructs are used by WS-RF as network-wide pointers to resources (see Listing 1). Each consumer is required to include the <example:DataSetId/> element in the header of each SOAP message, which results in some explicitly identified action to be taken on the resource (e.g., a message requesting that the identified dataset be sorted or deleted). This element is used by the recipient service to identify and delegate invocations to the correct back-end resource.

As a network pointer, a WS-Addressing construct with resource-specific information fulfills the same purpose as a CORBA IOR, DCOM OBJREF, Java RMI URL, etc.; it identifies a resource across the network. In an approach that is similar to existing object-based, distributed-computing technologies, WS-RF pushes the issue of resource identification down from the application layer and makes it part of the Web services stack.

By requiring the identity of the resource to be passed as a header in each SOAP message, WS-RF models stateful interactions with specific resources rather than services. In combination with the additional specifications that offer lifetime management of exposed resources and a mechanism to renew the references to those resources, the WS-RF shares many concepts with distributed-object models.

The Filestore Example
To represent the issues raised in the previous sections, we will explore a hypothetical implementation of a simple Web services-based filestore. (Note: The filestore example was used because it is both simple and has been a canonical example for demonstrating the pros and cons of both WS-RF and WS-CAF within both communities.) In this example, the filestore implementation is simplistic; for clarity we ignore issues such as policy and security, though in a real implementation both would be critical. An overview of the filestore implementation is shown in Figure 2.

Accessing the filestore using WS-RF is straightforward. A WS-Addressing endpoint reference to a specific resource is obtained (via some out-of-band mechanism like a registry or factory). This endpoint reference (extended with WS-RF-specific metadata) acts as a network-wide pointer to the resource hosted by the Web service. The endpoint reference obtained can be used as both an address to which messages can be sent, and as an implicit context for interacting with the back-end resource (using the contents of its <Reference Properties/> element).

In the case of the filestore, the file ID (or i-node or some other descriptor) can be used to provide the necessary metadata to enable the service to route invocations to the same resource for each message sent to the service (see Figure 3), where the consumer sends the message to the service endpoint identified by the WS-Address and the resource-related metadata is used to assist the service in routing to the correct back-end resource.

While the implementation of the WS-RF scheme is SOAP friendly (using the SOAP headers and WS-Addressing), developers should take care that they do not violate encapsulation by directly exposing private enterprise resources to the wider network. The main danger with WS-RF is that it encourages exactly this behavior. This in turn leads to applications that are brittle and difficult to maintain. The key weakness of this approach is that should the service wish to evolve (for example, if the filestore implementation migrates from a single file system to a database-driven configuration), the identity information captured in the endpoint reference metadata may become stale and thus the stateful session will fail. This is why additional mechanisms, like lifetime management and renewable references, are necessary parts of WS-RF. While it is possible to avoid such problems by using logical identifiers (which are resolved by the service into physical resources), it is not mandated by WS-RF. (Note: The WS-Context approach does not suffer this drawback since contexts are third-party entities entirely decoupled from the implementation of any service.)

In this constrained scenario, the WS-Context approach is not entirely dissimilar from the WS-RF technique. A context is generated by some out-of-band means (such as a context service) and is embedded in a SOAP header block with every application-level message sent to the filestore. The filestore undertakes the action corresponding to the receipt of that message, using the context information to ensure the correct state and resources are used to serve the action.

Unlike the WS-RF approach, the context in Figure 4 is not an identifier for any back-end resources, but is an external entity that allows actions to be logically linked. WS-Context does not try to model service-side resources since this is considered out of scope, yet stateful interactions can still be supported. Because WS-Context takes the view that a service's implementation is private to that service, how context information is used to correlate messages into stateful interactions is left to the service architect. This means that while WS-Context-aware services are interoperable, no implementation choices are forced upon developers. As such, WS-Context respects the view of a Web service as independently evolvable and where no information (logical or otherwise) about the configuration of the service escapes from within its boundaries. Since context information exists independent of any context-aware service, those services can evolve as they see fit without jeopardizing the validity of future contextualized interactions.

Scaling WS-RF and WS-Context
If WS-RF is used judiciously, then it can support single-party interactions in a similar way to WS-Context, where the contents of the WS-RF endpoint <ReferenceProperties/> element is used in place of the WS-Context context. In certain constrained circumstances WS-RF is an even simpler solution since it requires no additional protocol actors, whereas most WS-Context- enabled services are designed to take part in distributed activities and thus require a context management service, or internal means of generating a context.

However, unlike WS-Context, which treats context as an externally shared entity, the WS-RF model does not scale well past the simple consumer-service interactions since resources are identified with service-specific information, which is used to contextualize interactions. To illustrate this, consider Figures 5 and 6.

In Figure 5 we are confident that the pointer-like mechanism that underpins WS-RF is valid when used to communicate with a resource hosted by a specific service. However, since that endpoint reference is service specific, the same resource-related metadata cannot be used when communicating with a second service.

Furthermore, since there is nothing to prevent the storage of WS-Addressing structures with resource-related metadata and service endpoint information, long-lived interdependencies between resources may be formed. Such interdependencies are difficult to maintain in large-scale systems and cause applications to be brittle.

In Figure 6, because context is modeled as a known, standardized, external entity, any WS-Context-aware service that receives it will be able to apply the context information to its own internal processes. Given that the context is explicitly managed and external to any individual service it is visible and valid to all services within the activity. On receipt of a context, the service can use the information to correlate messages to back-end resources, including the use of that information to discover the wider application context within which the action will be executed (i.e., the other services are participating), and thus stateful distributed activities are possible.

While distributed activities can be achieved after a fashion using WS-RF (by manually propagating all of the endpoint references in use to all services in use), scoping a distributed application by using collections of point-to-point addresses is inherently difficult, and leads very quickly to a combinatorial explosion of endpoint references that have to be managed, propagated, and kept up-to-date. Conversely, only a single entity, the context, is required in the WS-Context approach.

Conclusion
While both WS-Context and WS-RF can be used to enable stateful interactions between Web services and their consumers, the models they adopt to achieve this are very different, and as a consequence the scenarios in which they are best deployed are also different.

The WS-RF approach is based on an addressing scheme for back-end resources hosted by Web services. This addressing information can be used as a means of correlating and routing message exchanges with those back-end resources and thus as a means of achieving stateful communication.

WS-Context assumes that the back-end implementation details of a service are private. It is deliberately noninvasive and deals only with context management and propagation of contexts to services. What precisely is done to map a particular application level message plus context onto specific back-end resources is safely out of scope.

For single consumer-server interactions the WS-RF approach is certainly lightweight. However for interactions involving multiple services, the WS-Context approach scales readily to support distributed activities. Thus WS-RF might be suitable as a point-to-point solution for integrating two systems, but in the general case with systems composed from many Web services, WS-Context is the natural choice.

Acknowledgments
The authors would like to thank Professor Paul Watson (University of Newcastle upon Tyne) for his contributions to this article.

References