Better late than never

WS-Context has gone to committee draft in OASIS WS-CAF, which is somewhat of a relief, as it means we can move on to the WS-Coordination Framework specification.

As I've said in an earlier post, WS-Context took me by surprise with its applicability in a wide area, despite the fact that it is probably conceptually the simplest of the 3 specifications we're looking at in the technical committee. IMO one of the most important areas where WS-Context can assist is in maintaining a scalable Web Services architecture for statefull Web Services. I agree with Jim Gray that truly stateless Web Services aren't of any real use, and hope to have a paper I've written on the subject published soon. State is a necessity, it's just what constitutes state that may be open for debate.

In this post I'll try to give a flavour of how I think WS-Context fits into this debate. The area I'll consider is that of stateful sessions, where a user wants to return to a specific state time and again over the course of hours, days, weeks etc. Now in Web Services there are essentially two proposed ways of doing this:

(i) WS-Addressing, which uses ReferenceProperties to explicitly bind a Web Services address to a specific session (and hence state).

(ii) WS-Context, which provides a more lightweight, generalized session model. One analogy that you could use, is that of a Web Services cookie, that isn't tied to a single Web server: I'm glad we didn't call the specificatoin WS-Cookie though.

Both models support stateful interactions over a period of time. The problem is that (i) encourages tightly coupled system design: the address is only good for a specific session, and it is tied to a single endpoint. If you've only got to manage a small number of these addresses, then you obviously could, but if the session spans hours or days then you're going to want to make them durable somehow. That's not necessarily a hardship, unless you have many of them.

However, if a client application interacts with multiple services within the same logical session, then it is often the case that the state of a service has relevance to the client only when used in conjunction with the associated states of the other services. This necessarily means that the client must remember each service reference and somehow associate them with a specific interaction; multiple interactions will obviously result in different reference sets that may be combined to represent each sessions.

For example, if there are N services used within the same application session, each maintaining m different states, the client application will have to maintain N*m reference endpoints. This obviously does not scale. However, an alternative approach is to use (ii). Each interaction with a set of services can be modeled as a session and this in turn can be modeled as a WS-Context activity with an associated context (at a minimum essentially just a URI). Whenever a client application interacts with a set of services within the same session, the same context (same URI) is propagated to the services and they map this context to the necessary states that the client interaction requires. How this mapping occurs is an implementation specific choice that doesn't need to be exposed to the client. Furthermore, since each service within a specific session gets the same context, upon later revisiting these services and providing the same context again, the client application can be sure to return to a consistent set of states. You only need to remember the context, no matter how many services your application uses in that activity. Thus, this model scales much better.

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.