WebServices dot org

Next stop .... the Twilight Zone!

“There is a fifth dimension beyond that which is known to man. It is a dimension as vast as space and as timeless as infinity. It is the middle ground between light and shadow, between science and imagination, and it lies between the pit of man's fears and the summit of his knowledge. This is the dimension of imagination. It is an area which we call the Twilight Zone” .

Picture this ... the story you are about to hear takes place in a parallel universe, where darkness has descended on the world of Web Services. In this reality, the idealised aspects of Service Oriented Architecture have been crippled by old fashioned thinking, and Web Services have devolved into a close cousin of technologies such as CORBA and DCOM. The few people who can remember the once bright future that was heralded by the wise men Gartner, Burton and Forrester, cling to the slim hope that some new technology will arise and loosely coupled, agile systems will arise once again.

OK, so let's switch back to the real world and bid farewell to Rod Serling for now. Two events happened recently that got me thinking that we do stand at a crossroads in the evolution of Web Services: firstly, the OASIS WS-Context specification has passed its final vote on the road to becoming a standard and secondly, the OASIS Web Services Resource Framework (WS-RF) is close to standardisation too. At first it may seem that these two things are unrelated, but in fact they share a common goal in defining how applications refer to services and state. I believe that the ways in which they attempt to do this are so diametrically opposed that if we make the wrong choice, the important principles of SOA that underly good Web Services development could be at risk, and Mr. Serling's vision of the future could be a reality.

I've blogged before about the work that has been going on in the OASIS Web Services Composite Application Framework technical committee , of which WS-Context is part. Although the committee started out looking to develop an entire stack of specifications building up to transactionality, it has turned out that the specification at the bottom of the stack (WS-Context) has had the most impact outside the committee. WS-Context defines a lightweight framework for simple context management that can be used by arbitrary Web services to form composite applications. Contexts are first-class elements, i.e., the context information is represented as a Web resource, accessible via its URI. Contexts may flow implicitly (transparently to the application) with normal messages sent to participants/endpoints during Web service execution.

In my opinion we are now at a critical point in the evolution of the Web Services “architecture” (I use that word loosely because, since the demise of the W3C effort, there's no standard definition outside the control of individual companies). We all know that Web Services are just one concrete form of SOA, and that SOA allows us to develop loosely coupled applications; and loose coupling is good if you want to build agile and easily evolvable systems. However, just because something allows loose coupling does not mean that it's an inherent part of all applications developed using it: SOA is as much a way of designing and thinking about applications as it is in finally implementing them. Therefore, it's very easy to fall back into the old “bad habits” of closely-coupled systems. I'd better say at this point that I don't have a problem with closely-coupled applications; everything has a place in a good architect or developers toolkit: but that needs to be an option and not a core tenant of the architecture.

This is where WS-Context comes in: it's important in order to ensure that the development of loosely coupled Web Services continues. Although WS-Context is about to become an OASIS standard, without further adoption 2006 could easily go down in history as the turning point in Web Services: where the industry crippled loosely-coupled SOA. Unfortunately although it has the backing of companies such as Oracle and Sun, and has been taken up by other groups inside and outside of OASIS, WS-Context doesn't have IBM or Microsoft support, which in this field can often signal the death knell.

Why is context so important?

It has long been recognized that the World Wide Web is probably the most successful distributed system created. It is inherently loosely coupled (clients and servers frequently interact across the globe) and highly scaleable (many thousands of Web sites). There are a number of factors that can be attributed to the Web’s success, but two of the most important are:

• Sessions between clients and servers are maintained only long enough to transfer an HTML page and are dropped immediately afterward. This means that costly resources (e.g., TCP/IP connections, threads, processes) are not maintained for long durations, particularly when there are many users interacting with a service.

• Server interactions are either stateless, meaning that any instance of a Web server offering a particular service, e.g., airline reservation, can field the request, or information required to identify a previous user (and possibly state) is propagated with the invocation, e.g., the cookie.

However, a purely “stateless” protocol has limited applicability to certain kinds of applications. Therefore, how the Web supports sessions proved critical to its scalability: a session is a mechanism for correlating multiple messages in order to achieve some application-visible semantic. The Cookie model was introduced to allow Web-content applications to flexibly manage state. When a user accesses a Web site’s origin server, the session is communicated back to the user agent via a Cookie, which contains information necessary to reestablish the session state on a per-request basis. Importantly, the HTTP session has no predefined structural relationship with the server’s Web address or resources. Imagine the state of the World Wide Web today if Cookies hadn't come along. We'd all be working with session-encoded URI's today that would make some of today's Servlet or cgi URI's look simple by comparison!

Most proponents of Web Services agree that it is important the architecture is as scalable and flexible as the Web and how sessions are dealt with within the architecture will either make or break it. Right now, there are two primary models for the session concept that are being defined by companies participating in defining Web services: the WS-Addressing EndpointReference with ReferenceParameters and the WS-Context context structure. The WS-Addressing session model provides coupling between the web service endpoint information and the session data, which is analogous to object references in distributed object systems. WS-Context provides a session model that is an evolution of the session models found in HTTP servers, transaction, and MOM systems [ 1 ].

WS-Addressing is intended to provide a building block for higher level abstractions. In the specification itself, what exactly an EndpointReference including ReferenceParameters refers to is not defined. It could be an entity modeled by the service, or alternatively, a resource managed by the service. This is also where WS-RF comes in, because it builds on WS-Addressing to use the base EndpointReference as a building block to structure a model that resembles distributed object systems like CORBA. The WS-RF specifications provided an elaborate framework that attempts to cope with the brittleness problems created by the reference session model.

Because WS-Addressing is clearly based on the session reference model, a natural way to think about the ReferenceParameters is to compare them to the Object Key in the IOR found in CORBA systems. The ReferenceParameters provide a mechanism for reestablishing the execution context for the request message once it reaches the service network endpoint. Because WS-Addressing is a “building block” specification for protocols and product features, it is positioned to provide a fundamental session model for the Web services architecture moving forward.

On the other hand, WS-Context defines a basic (extensible) context structure that can be associated with an abstract activity: the lifetime of the activity is the lifetime of the context. The activity can then be used to model a session: all interactions on a session-oriented service in the scope of an activity will be uniquely and unambiguously tied to that activity through the context. Importantly, the context (and hence session) is not tied to the endpoint reference of the service: the same service can be addressed by multiple clients or services in the scope of different sessions concurrently. The session concept is therefore loosely coupled with respect to communication channels and service endpoints: the session may be used in conjunction with a service for a short period or even shared across multiple services. Late binding also means that protocols may use WS-Context to support either ephemeral or long-lived sessions associated with a fixed service endpoint definition as appropriate within an application.

Still unsure?

There are several good papers on why the context approach to session management is superior to the object-key, so I won't go into details here [ 2 ][ 3 ]. But suffice it to say that the context approach is more scalable and flexible. Fairly obviously WS-RF and WS-Addressing will become standards in the near future and although the former specification will have some adopters, the latter has already become an important part of the architecture. I'm not advocating that people ignore WS-Addressing; we've needed some form of addressing for Web Services for far too long and some standard is better than none. I am advocating that we are careful when using all of its capabilities and consider using it in conjunction with WS-Context (like URL's are to Cookies, so WS-Addressing should be to WS-Context).

References

[1] Hildebrand, H. et al, “The Session Concept and Web Services”, Proceedings of XML 2005, Atlanta, November 2005.

[2] Manes, Anne Thomas, (2001) “Enabling Open, Interoperable, and Smart Web Services (The Need for Shared Context)”, 12 March 2001, http://www.w3.org/2001/03/WSWS-popa/paper29

[3] Webber, J. et al (May 2004), “Stateful interactions in Web Services: a comparison of WS-Context and WS-Resource Framework”, Web Services Journal.