Welcome!

Microservices Expo Authors: Liz McMillan, Todd Matters, Pat Romanski, Elizabeth White, Stefana Muller

Related Topics: Microservices Expo

Microservices Expo: Article

Stateful Interactions in Web Services

A comparison of WS-Context and WS-Resource Framework

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.
WS-RF promotes implicit contextualization as a mechanism for stateful interactions between consumers and resources exposed outside the boundaries of a service (it does not model context as an external entity as does WS-Context). Such resources, logical or physical, are identified through WS-Addressing constructs. In addition to information about service endpoints, these constructs also contain information specific to resources, which are placed in the <wsa:ReferenceProperty/> element of a WS-Addressing construct.

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

  • OASIS(WS-CAF), Web services Context (WS-CTX): www.iona.com/devcenter/standards/WS-CAF/WSCTX.pdf
  • Web services Resource Framework (WS-RF). 2004: www.globus.org/wsrf
  • Parastatidis, S., et al. (2003). "A Grid Application Framework Based on Web Services Specifications and Practices. www.neresc.ac.uk/ws-gaf
  • Tuecke, S., et al. (2003). "Open Grid Services Infrastructure (OGSI) - Version 1.0". https://forge.gridforum.org/projects/ogsi-wg
  • Frey, J., et al. (2004) "Modeling Stateful Resources with Web Services."
  • Web Services Addressing (WS-Addressing): http://msdn.microsoft.com/ws/2003/03/ws-addressing.
  • More Stories By Mark Little

    Mark Little was Chief Architect, Transactions for Arjuna Technologies Ltd, a UK-based company specialising in the development of reliable middleware that was recently acquired by JBoss, Inc. Before Arjuna, Mark was a Distinguished Engineer/Architect within HP Arjuna Labs in Newcastle upon Tyne, England, where he led the HP-TS and HP-WST teams, developing J2EE and Web services transactions products respectively. He is one of the primary authors of the OMG Activity Service specification and is on the expert group for the same work in J2EE (JSR 95). He is also the specification lead for JSR 156: Java API for XML Transactions. He's on the OTS Revision Task Force and the OASIS Business Transactions Protocol specification. Before joining HP he was for over 10 years a member of the Arjuna team within the University of Newcastle upon Tyne (where he continues to have a Visiting Fellowship). His research within the Arjuna team included replication and transactions support, which include the construction of an OTS/JTS compliant transaction processing system. Mark has published extensively in the Web Services Journal, Java Developer's Journal and other journals and magazines. He is also the co-author of several books including “Java and Transactions for Systems Professionals” and “The J2EE 1.4 Bible.”

    More Stories By Jim Webber

    Dr. Jim Webber is a senior researcher from the University of Newcastle
    upon Tyne, currently working in the convergence of Web Services and Grid
    technologies at the University of Sydney, Australia. Jim was previously
    Web Services architect with Arjuna Technologies where he worked on Web
    Services transactioning technology, including being one of the original
    authors of the WS-CAF specification. Prior to Arjuna, Jim was the lead
    developer with Hewlett-Packard on the industry's first Web Services
    Transaction solution. Co-author of "Developing Enterprise Web Services -
    An Architect's Guide," Jim is an active speaker and author in the Web
    Services space. Jim's home on the web is http://jim.webber.name

    More Stories By Savas Parastatidis

    Dr. Savas Parastatidis is the chief software architect at the North-East Regional e-Science Center (NEReSC), Newcastle, UK. He is NEReSC's expert in Grid Computing technologies and standards. Previously, he co-led an R&D team at HP's middleware division that produced the world's first XML-based transactioning system and represented HP during the early stages of the OASIS BTP standardization effort.

    Comments (2) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    Gottfried Luef 06/14/04 04:28:25 AM EDT

    As I understood your point, you are saying that for single consumer-server interactions WS-RF is a valid choice, but that for interactions spanning multiple web services WS-Context is better.

    Imagine a scenario where several servers serve the same message queue which has an identical WS-RF network pointer on each of the servers. Then a client can go to each of the servers with the same WS-RF context and push messages on that queue. So there are multiple web services and WS-RF scales well.

    I would reformulate your conclusion and say that for interactions spanning mulitple web services with different resources, WS-Context ist the right context protocol. For interactions that span multiple web services but on the same resource, WS-RF is still a good because lightweight choice.

    Lewis Stevens 05/13/04 05:30:09 AM EDT

    Nice article. I''ve had my doubts about WS-RF for a while and this brings into clarity some of them: it''s just not going to scale in the area of state management. SOAs don''t necessarily scale because they''re SOAs, but they facilitate the creation of scaleable architectures. But add WS-RF into the picture and scaleability becomes a nightmare - am I really supposed to figure out where all my state instance ids (aka object keys) are stored and how they match up to create a consistent cut across N services?! WS-Context looks like a nice, simple and SOA-compatible approach. I need to go and read that spec now.

    @MicroservicesExpo Stories
    New competitors, disruptive technologies, and growing expectations are pushing every business to both adopt and deliver new digital services. This ‘Digital Transformation’ demands rapid delivery and continuous iteration of new competitive services via multiple channels, which in turn demands new service delivery techniques – including DevOps. In this power panel at @DevOpsSummit 20th Cloud Expo, moderated by DevOps Conference Co-Chair Andi Mann, panelists examined how DevOps helps to meet the de...
    For most organizations, the move to hybrid cloud is now a question of when, not if. Fully 82% of enterprises plan to have a hybrid cloud strategy this year, according to Infoholic Research. The worldwide hybrid cloud computing market is expected to grow about 34% annually over the next five years, reaching $241.13 billion by 2022. Companies are embracing hybrid cloud because of the many advantages it offers compared to relying on a single provider for all of their cloud needs. Hybrid offers bala...
    "When we talk about cloud without compromise what we're talking about is that when people think about 'I need the flexibility of the cloud' - it's the ability to create applications and run them in a cloud environment that's far more flexible,” explained Matthew Finnie, CTO of Interoute, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
    @DevOpsSummit at Cloud Expo taking place Oct 31 - Nov 2, 2017, at the Santa Clara Convention Center, Santa Clara, CA, is co-located with the 21st International Cloud Expo and will feature technical sessions from a rock star conference faculty and the leading industry players in the world. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is ...
    What's the role of an IT self-service portal when you get to continuous delivery and Infrastructure as Code? This general session showed how to create the continuous delivery culture and eight accelerators for leading the change. Don Demcsak is a DevOps and Cloud Native Modernization Principal for Dell EMC based out of New Jersey. He is a former, long time, Microsoft Most Valuable Professional, specializing in building and architecting Application Delivery Pipelines for hybrid legacy, and cloud ...
    Containers, microservices and DevOps are all the rage lately. You can read about how great they are and how they’ll change your life and the industry everywhere. So naturally when we started a new company and were deciding how to architect our app, we went with microservices, containers and DevOps. About now you’re expecting a story of how everything went so smoothly, we’re now pushing out code ten times a day, but the reality is quite different.
    There's a lot to gain from cloud computing, but success requires a thoughtful and enterprise focused approach. Cloud computing decouples data and information from the infrastructure on which it lies. A process that is a LOT more involved than dragging some folders from your desktop to a shared drive. Cloud computing as a mission transformation activity, not a technological one. As an organization moves from local information hosting to the cloud, one of the most important challenges is addressi...
    For organizations that have amassed large sums of software complexity, taking a microservices approach is the first step toward DevOps and continuous improvement / development. Integrating system-level analysis with microservices makes it easier to change and add functionality to applications at any time without the increase of risk. Before you start big transformation projects or a cloud migration, make sure these changes won’t take down your entire organization.
    21st International Cloud Expo, taking place October 31 - November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA, will feature technical sessions from a rock star conference faculty and the leading industry players in the world. Cloud computing is now being embraced by a majority of enterprises of all sizes. Yesterday's debate about public vs. private has transformed into the reality of hybrid cloud: a recent survey shows that 74% of enterprises have a hybrid cloud strategy. Me...
    "We are a monitoring company. We work with Salesforce, BBC, and quite a few other big logos. We basically provide monitoring for them, structure for their cloud services and we fit into the DevOps world" explained David Gildeh, Co-founder and CEO of Outlyer, in this SYS-CON.tv interview at DevOps Summit at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
    Microservices are increasingly used in the development world as developers work to create larger, more complex applications that are better developed and managed as a combination of smaller services that work cohesively together for larger, application-wide functionality. Tools such as Service Fabric are rising to meet the need to think about and build apps using a piece-by-piece methodology that is, frankly, less mind-boggling than considering the whole of the application at once. Today, we'll ...
    Cloud Expo, Inc. has announced today that Andi Mann and Aruna Ravichandran have been named Co-Chairs of @DevOpsSummit at Cloud Expo Silicon Valley which will take place Oct. 31-Nov. 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. "DevOps is at the intersection of technology and business-optimizing tools, organizations and processes to bring measurable improvements in productivity and profitability," said Aruna Ravichandran, vice president, DevOps product and solutions marketing...
    In his session at Cloud Expo, Alan Winters, an entertainment executive/TV producer turned serial entrepreneur, presented a success story of an entrepreneur who has both suffered through and benefited from offshore development across multiple businesses: The smart choice, or how to select the right offshore development partner Warning signs, or how to minimize chances of making the wrong choice Collaboration, or how to establish the most effective work processes Budget control, or how to ma...
    SYS-CON Events announced today that CA Technologies has been named "Platinum Sponsor" of SYS-CON's 21st International Cloud Expo®, which will take place October 31-November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. CA Technologies helps customers succeed in a future where every business - from apparel to energy - is being rewritten by software. From planning to development to management to security, CA creates software that fuels transformation for companies in the applic...
    In the decade following his article, cloud computing further cemented Carr’s perspective. Compute, storage, and network resources have become simple utilities, available at the proverbial turn of the faucet. The value they provide is immense, but the cloud playing field is amazingly level. Carr’s quote above presaged the cloud to a T. Today, however, we’re in the digital era. Mark Andreesen’s ‘software is eating the world’ prognostication is coming to pass, as enterprises realize they must be...
    A common misconception about the cloud is that one size fits all. Companies expecting to run all of their operations using one cloud solution or service must realize that doing so is akin to forcing the totality of their business functionality into a straightjacket. Unlocking the full potential of the cloud means embracing the multi-cloud future where businesses use their own cloud, and/or clouds from different vendors, to support separate functions or product groups. There is no single cloud so...
    Both SaaS vendors and SaaS buyers are going “all-in” to hyperscale IaaS platforms such as AWS, which is disrupting the SaaS value proposition. Why should the enterprise SaaS consumer pay for the SaaS service if their data is resident in adjacent AWS S3 buckets? If both SaaS sellers and buyers are using the same cloud tools, automation and pay-per-transaction model offered by IaaS platforms, then why not host the “shrink-wrapped” software in the customers’ cloud? Further, serverless computing, cl...
    Hybrid IT is today’s reality, and while its implementation may seem daunting at times, more and more organizations are migrating to the cloud. In fact, according to SolarWinds 2017 IT Trends Index: Portrait of a Hybrid IT Organization 95 percent of organizations have migrated crucial applications to the cloud in the past year. As such, it’s in every IT professional’s best interest to know what to expect.
    The taxi industry never saw Uber coming. Startups are a threat to incumbents like never before, and a major enabler for startups is that they are instantly “cloud ready.” If innovation moves at the pace of IT, then your company is in trouble. Why? Because your data center will not keep up with frenetic pace AWS, Microsoft and Google are rolling out new capabilities. In his session at 20th Cloud Expo, Don Browning, VP of Cloud Architecture at Turner, posited that disruption is inevitable for comp...
    Companies have always been concerned that traditional enterprise software is slow and complex to install, often disrupting critical and time-sensitive operations during roll-out. With the growing need to integrate new digital technologies into the enterprise to transform business processes, this concern has become even more pressing. A 2016 Panorama Consulting Solutions study revealed that enterprise resource planning (ERP) projects took an average of 21 months to install, with 57 percent of th...