Guidance for context management in SOA JWS?

[Peer Reynders]

Ideally every web service should be stateless however there are cases where service requests must be correlated. The temptation to use the well established and supported HTTP session is strong but ultimately leads to interoperability problems. Also handling of the session information outside of SOAP means that the messages cannot travel over any intermediaries as this would separate the session information from the message. The Java Blueprints suggest sending context information such as a correlation identifier within a SOAP header to avoid all these problems. However no mention is made how to best leverage the facilities of the J2EE platform to fully implement the requisite server side implementation of the necessary context management (like a web service version of HttpSession). The developer is basically left to implement a homegrown solution.

Does SOA Using Java� Web Services (amazon US) offer any additional guidance for the Java Web Service Developer who needs to implement the correlation of web service requests?

[Mark D. Hansen]

Good question

JAX-WS 2.0 supports HTTP based mechanisms for Session Management. I did not cover them in my book, because they seemed to me to be an "advanced topic". Maybe I will add something in the next version.

Here is a little information and some pointers where you can learn more.

The JAX-WS specification discusses HTTP based session support via cookies, URL rewriting, and SSL session ID. Only URL rewriting is required. As you point out, however, none of these are usable when you require sessions to be managed at the SOAP level, so that messages can travel over intermediaries.

For that purpose, JAX-WS 2.0/2.1 defines as a goal (in Section 1.3.9) the support of SOAP based sessions. However, the only SOAP-based sessions defined in the JAX-WS specifications are for the SOAP/HTTP binding. So, still, there is no real SOAP session implementation required in JAX-WS 2.0/2.1.

However, JAX-WS 2.1, which was only finalized in May 2007 (too late for my book), requires support for WS-Addressing. WS-Addressing provides a framework for SOAP sessions.

Although not required in JAX-WS 2.1, the Sun JAX-WS 2.1 reference implementation does support true SOAP sessions. One of the Sun developers, Kohsuke Kawaguchi, describes it in his blog

[Peer Reynders]

Thank You for Your valuable pointers.

I have to admit that I am a little surprised that HTTP-Session management has become an integral part of JAX-WS 2.0. It's adoption could be along the lines of the other "web services pixie dust" as features that are heavily requested by developers and fairly easy to implement even though these features are not necessarily the best solution in many cases. Or there may be the realization (resignation?) that in the vast majority of cases SOAP messages are only going to travel over HTTP between the initial sender and ultimate receiver, so that full-blown support of SOAP message paths isn't required.

This is especially interesting as the WS-I BP outlines that a service should not require the client to support cookies.
WS-I: Basic Profile Version 1.2

R1121 An INSTANCE SHOULD NOT require consumer support for Cookies in order to function correctly.

I seem to recall that support of intermediaries was a significant feature in Thomas Erl's vision of SOA in Service-Oriented Architecture (SOA): Concepts, Technology, and Design (amazon US) and Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services (amazon US).

This also raises the question if the lack of inherent support for message paths (and intermediaries) will hinder the adoption of RESTful SOAs or whether standardized solutions will emerge.

PS: I just noticed that Thomas Erl will have another SOA related book out in July: SOA: Principles of Service Design.
[ May 31, 2007: Message edited by: Peer Reynders ]

[Mark D. Hansen]

I think you (and Erl and the WS-I people) are right. SOAP level sessions and the support of intermediaries are important. That is one of the main problems solved by SOAP (vs. POX/HTTP and REST).

We'll see how all this shakes out over the next few years. My guess is that SOA fragments into 2 versions - (1) Basic SOA: that is tightly coupled with HTTP and is widely used for applications running over the public Internet. This is build on REST (and maybe WADL). (2) Enterprise SOA: that takes advantage of SOAP, WSDL, and the WS-* stack.