One of the biggest challenges to service-oriented delivery of composite applications is the lack of an interoperable mechanism to support state and context. This is particularly challenging when considering that composite applications may be composed from heterogeneous services, i.e. .NET, JavaEE, or platform X.

To provide interoperability between service implementations, OASIS began working on a set of standards to address the stateless nature of SOA and provide context for composite applications. Recently, WS-Context was adopted as a standard into the WS-* family.

A good example of WS-Context used to provide stateful transactions can be found over at SOA World Magazine.

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.

In a nutshell you can think of WS-Context sort of like "WS-Cookie", at least that's the word according to one of its core authors, Eric Newcomer of IONA.

The passage of WS-Context to standard status does not come without some trepidation. Mark Little of JBoss offers his view on the superiority of WS-Context over competing standard Web Services Resource Framework (WS-RF).

Disconcerting is the lack of support for WS-Context by IBM and Microsoft, something that is mentioned numerous times by those watching the passage of the two specifications through the standardization process.

So what does F5 have to offer to WS-Context? Good question. One of the application services the BIG-IP has offered for many years is the ability to offload session management from applications. The ability to maintain and understand session is necessarily important to application delivery networking products, as there are many scenarios in which session must be maintained by the intermediary in order to maintain transaction integrity. This is partially what WS-Context intends to enable via a WS-Context service.

Using iRules and the inherent persistence capabilities of BIG-IP you can implement a simple WS-Context service as well as support external WS-Context services. This is in addition to BIG-IP's existing capabilities to handle session management regardless of the environment - SOA or legacy. In fact, this is one of the distinct advantages of BIG-IP over SOA gateways which do not support state at all. The ability to extract, insert, and maintain state via session id, transaction context, cookies, or some other custom piece of data should be required of any intermediary that may be involved in a WS-Context aware transaction.

Even if you aren't interested in adding your BIG-IP as a first-class citizen in your SOA ecosystem by either implementing a WS-Context service via iRules or including a call to an external WS-Context service within an iRule to support stateful transactions, you still need to be concerned about the ability of your application delivery networking solution to recognize and act appropriately upon discovering a WS-Context header, lest your chosen solution chooses to deliver statefully bounded requests to the wrong server, or maintain a session after the WS-Context header specifies it should expire, or vice-versa.

While all application delivery networking products are capable of directing traffic based on session information (often referred to as session-based persistence), not all of them are capable of digging into a SOAP header and finding session (a.k.a. context) data on which to base its decisions. A lack of attention to whether your application delivery solution can support this model could be costly in terms of time spent on root-cause analysis and both time/money spent on addressing the problem once its discovered.

Imbibing: Mountain Dew