Skip to main content

A session & context concept for Web Services

Posted by marklittle on May 7, 2005 at 2:44 PM PDT

One of the common features of all middleware systems is support for the session concept. You don't have to look far to see this: J2EE, CORBA and going back further to systems such as Emerald, Argus and Camelot. A session is a mechanism for correlating multiple messages in order to achieve some application-visible semantic. But strange as it may sound, until recently there wasn't such a concept for Web Services.

In August 2003, Sun, Oracle, Arjuna Technologies, IONA Technologies and Fujitsu, released the Web Services Composite Application Framework family of specifications. Shortly afterwards, these specifications were given to OASIS to form the OASIS WS-CAF technical committee.

In future entries I may look at the other specifications, but the one I'd like to concentrate on now is WS-Context.You might think that sessions are something so fundamental that you simply can't live without them, so why were Web Services special? Why didn't such a capability exist until 2003? The answer is that it did, but it was done on an ad hoc basis by pretty much every specification or implementation that needed it. What Sun, Oracle et al set out to do with WS-Context was to standardise this for interoperability and re-useability.

Then of course there was the infamous ReferenceProperties in WS-Addressing. This allowed additional information within an address to be encoded in an opaque manner, but which could (and was) used to create sessions. The problems with this have been discussed many times elsewhere, but I recommend checking out this paper for a summary. Fortunately ReferenceProperties were removed, though ReferenceParameters still exist.

WS-Context provides a more lightweight, generalized session model, somewhat akin to that of a Web Services cookie. The Web Services architecture is not prescriptive about what happens behind service endpoints. This gives flexibility of implementation, allowing systems to adapt to changes in requirements, technology etc. without directly affecting users. It also means that issues such as whether or not a service maintains state on behalf of users or their (temporally bounded) interactions, has been an implementation choice not typically exposed to users. The WS-Context session model encourages loose coupling of services and their users and keeps any implementation specific choices about state where they belong: behind the service endpoint.

Related Topics >>