Mark Little's Blog: A session & context concept for Web Services

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.

Bookmark blog post:

del.icio.us

Digg

DZone

Furl

Comments

Comments are listed in date ascending order (oldest first) | Post Comment

Great. But how do we USE it? Can you show me what the impact on the service really is?

Posted by: epesh on May 11, 2005 at 05:07 AM

Unlike WS-Addr, the session concept in WS-Context is wrapped into the context model: additional information that flows implicitly with your service messages. So, you don't have to change your service interface in order to actually make it WS-Context aware. The session information (e.g., a session id, transaction context, cookie, or whatever) flows in the SOAP header block. How the service then uses that information is a back-end implementation choice. So obviously the service implementation needs to be able to cope with what you send (MustUnderstand helps here), but the interface as seen by the external world remains the same.

Does that help? If not, check out http://www.sys-con.com/story/?storyid=44675 or I'll try and post something else here to help.

Posted by: marklittle on May 11, 2005 at 05:44 AM

BTW, I didn't mean to imply in my last comment that if you went the RefProp/RefParam route from WS-Addr that you have to change the service interface. That's not the case either, but there are disadvantages that I outlined in the original post.

Posted by: marklittle on May 11, 2005 at 05:47 AM

Powered by
Movable Type 3.01D

java.net RSS Feeds