Welcome!

Microservices Expo Authors: Elizabeth White, Pat Romanski, Liz McMillan, Yeshim Deniz, Carmen Gonzalez

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
    The Software Defined Data Center (SDDC), which enables organizations to seamlessly run in a hybrid cloud model (public + private cloud), is here to stay. IDC estimates that the software-defined networking market will be valued at $3.7 billion by 2016. Security is a key component and benefit of the SDDC, and offers an opportunity to build security 'from the ground up' and weave it into the environment from day one. In his session at 16th Cloud Expo, Reuven Harrison, CTO and Co-Founder of Tufin, ...
    By now, every company in the world is on the lookout for the digital disruption that will threaten their existence. In study after study, executives believe that technology has either already disrupted their industry, is in the process of disrupting it or will disrupt it in the near future. As a result, every organization is taking steps to prepare for or mitigate unforeseen disruptions. Yet in almost every industry, the disruption trend continues unabated.
    SYS-CON Events announced today that HTBase will exhibit at SYS-CON's 20th International Cloud Expo®, which will take place on June 6-8, 2017, at the Javits Center in New York City, NY. HTBase (Gartner 2016 Cool Vendor) delivers a Composable IT infrastructure solution architected for agility and increased efficiency. It turns compute, storage, and fabric into fluid pools of resources that are easily composed and re-composed to meet each application’s needs. With HTBase, companies can quickly prov...
    Building custom add-ons does not need to be limited to the ideas you see on a marketplace. In his session at 20th Cloud Expo, Sukhbir Dhillon, CEO and founder of Addteq, will go over some adventures they faced in developing integrations using Atlassian SDK and other technologies/platforms and how it has enabled development teams to experiment with newer paradigms like Serverless and newer features of Atlassian SDKs. In this presentation, you will be taken on a journey of Add-On and Integration ...
    Culture is the most important ingredient of DevOps. The challenge for most organizations is defining and communicating a vision of beneficial DevOps culture for their organizations, and then facilitating the changes needed to achieve that. Often this comes down to an ability to provide true leadership. As a CIO, are your direct reports IT managers or are they IT leaders? The hard truth is that many IT managers have risen through the ranks based on their technical skills, not their leadership abi...
    The essence of cloud computing is that all consumable IT resources are delivered as services. In his session at 15th Cloud Expo, Yung Chou, Technology Evangelist at Microsoft, demonstrated the concepts and implementations of two important cloud computing deliveries: Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). He discussed from business and technical viewpoints what exactly they are, why we care, how they are different and in what ways, and the strategies for IT to transi...
    Without a clear strategy for cost control and an architecture designed with cloud services in mind, costs and operational performance can quickly get out of control. To avoid multiple architectural redesigns requires extensive thought and planning. Boundary (now part of BMC) launched a new public-facing multi-tenant high resolution monitoring service on Amazon AWS two years ago, facing challenges and learning best practices in the early days of the new service.
    All organizations that did not originate this moment have a pre-existing culture as well as legacy technology and processes that can be more or less amenable to DevOps implementation. That organizational culture is influenced by the personalities and management styles of Executive Management, the wider culture in which the organization is situated, and the personalities of key team members at all levels of the organization. This culture and entrenched interests usually throw a wrench in the work...
    DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm.
    As software becomes more and more complex, we, as software developers, have been splitting up our code into smaller and smaller components. This is also true for the environment in which we run our code: going from bare metal, to VMs to the modern-day Cloud Native world of containers, schedulers and micro services. While we have figured out how to run containerized applications in the cloud using schedulers, we've yet to come up with a good solution to bridge the gap between getting your contain...
    As organizations realize the scope of the Internet of Things, gaining key insights from Big Data, through the use of advanced analytics, becomes crucial. However, IoT also creates the need for petabyte scale storage of data from millions of devices. A new type of Storage is required which seamlessly integrates robust data analytics with massive scale. These storage systems will act as “smart systems” provide in-place analytics that speed discovery and enable businesses to quickly derive meaningf...
    DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In his Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, will explore t...
    DevOps has often been described in terms of CAMS: Culture, Automation, Measuring, Sharing. While we’ve seen a lot of focus on the “A” and even on the “M”, there are very few examples of why the “C" is equally important in the DevOps equation. In her session at @DevOps Summit, Lori MacVittie, of F5 Networks, explored HTTP/1 and HTTP/2 along with Microservices to illustrate why a collaborative culture between Dev, Ops, and the Network is critical to ensuring success.
    With major technology companies and startups seriously embracing Cloud strategies, now is the perfect time to attend @CloudExpo | @ThingsExpo, June 6-8, 2017, at the Javits Center in New York City, NY and October 31 - November 2, 2017, Santa Clara Convention Center, CA. Learn what is going on, contribute to the discussions, and ensure that your enterprise is on the right path to Digital Transformation.
    Everyone wants to use containers, but monitoring containers is hard. New ephemeral architecture introduces new challenges in how monitoring tools need to monitor and visualize containers, so your team can make sense of everything. In his session at @DevOpsSummit, David Gildeh, co-founder and CEO of Outlyer, will go through the challenges and show there is light at the end of the tunnel if you use the right tools and understand what you need to be monitoring to successfully use containers in your...
    What if you could build a web application that could support true web-scale traffic without having to ever provision or manage a single server? Sounds magical, and it is! In his session at 20th Cloud Expo, Chris Munns, Senior Developer Advocate for Serverless Applications at Amazon Web Services, will show how to build a serverless website that scales automatically using services like AWS Lambda, Amazon API Gateway, and Amazon S3. We will review several frameworks that can help you build serverle...
    The IT industry is undergoing a significant evolution to keep up with cloud application demand. We see this happening as a mindset shift, from traditional IT teams to more well-rounded, cloud-focused job roles. The IT industry has become so cloud-minded that Gartner predicts that by 2020, this cloud shift will impact more than $1 trillion of global IT spending. This shift, however, has left some IT professionals feeling a little anxious about what lies ahead. The good news is that cloud computin...
    An overall theme of Cloud computing and the specific practices within it is fundamentally one of automation. The core value of technology is to continually automate low level procedures to free up people to work on more value add activities, ultimately leading to the utopian goal of full Autonomic Computing. For example a great way to define your plan for DevOps tool chain adoption is through this lens. In this TechTarget article they outline a simple maturity model for planning this.
    While DevOps most critically and famously fosters collaboration, communication, and integration through cultural change, culture is more of an output than an input. In order to actively drive cultural evolution, organizations must make substantial organizational and process changes, and adopt new technologies, to encourage a DevOps culture. Moderated by Andi Mann, panelists discussed how to balance these three pillars of DevOps, where to focus attention (and resources), where organizations might...
    The rise of containers and microservices has skyrocketed the rate at which new applications are moved into production environments today. While developers have been deploying containers to speed up the development processes for some time, there still remain challenges with running microservices efficiently. Most existing IT monitoring tools don’t actually maintain visibility into the containers that make up microservices. As those container applications move into production, some IT operations t...