Mike Grogan's Blog

WS-Reliable Messaging and Session Support (Part 2)

This is Part 2 in a series of articles on supporting sessions using WS-ReliableMessaging. In my talk at Java One, I showed a demo of a Web Service endpoint that needs Reliable Messaging to work properly. Like most endpoints that benefit from Reliable Messaging, this one maintains state between requests. In Part 1 of this series, Bhakti has written an article that describes the demo.

The endpoint in the demo uses Session Identifiers that happen to be implemented using Reliable Messaging. These Session Identifiers are exposed as an experimental feature in Tango. This is one way that the contents of SOAP Headers used by WS-* protocols can be used to generate Session Identifiers. Secure Conversation Tokens can also be used for this purpose. Microsoft uses both mechanisms in Microsoft's Windows Communication Foundation (WCF).

Like most demos, this one has problems that would prevent it from being used in real-life applications. Also, like most demos, there are ways to improve it by doing more work. In this article, I'll try to indicate some of the advantages and disadvantages of this approach to session management and compare the approach with one that is an established feature of JAX-WS.

This approach is the use of HttpSessions. This article in Rama's Blog illustrates the approach. Here are some comparisons of HttpSessions and Reliable Sessions

Transparency

The HttpSessions approach requires that client application programmers explicitly enable session support by setting the javax.xml.ws.session.maintain BindingProvider property to true. The Reliable Sessions approach is transparent to the client programmer.

Interoperability

The JAX-WS Specification requires that every JAX-WS implementation support HttpSessions. This means that in every implementation, an endpoint can be deployed so that it supports HttpSessions, and the session support will work correctly with JAX-WS clients whose session support has been enabled.

The Reliable Sessions approach requires that clients support implement the non-standard WS-RM specification and define RM Sequences so that all requests belonging to the same session belong to the same sequence. This will always be the case with a Tango or WCF client, but may not be the case with other Reliable Messaging implementations.

Protocol Independence

HttpSessions require the use of the HTTP Transport. Reliable Sessions do not. With most current Web Services, this is not a significant limitation. In the future, the increased use of other transports such as FastInfoset will make it more significant.

Security

Both approaches are subject to attacks that tamper with parts of Request messages on which Session Identifiers are based. For HttpSessions this entails tampering with HTTP headers. For Reliable Sessions it entails tampering with SOAP Headers. Both risks can be addressed using transport-level security. In cases where message-level security is required, HttpSessions are vulnerable. On the other hand, Reliable Sessions can offer some defense in these cases. In particular, in Tango or WCF, if a Reliable Messaging endpoint is configured to use Secure Conversations, the same Secure Conversation Token will be used to protect each request messaging belonging to a given sequence.

Resource Management

This is the biggest problem with the demo. The demo endpoint maintains state for each client, and does nothing to discard the state belonging to clients that are no longer using the endpoint. This means that the Hashtable that stores session state will grow uncontrollably. Of course, we could improve the program by recording the last time each key in the Hashtable is accessed, and periodically removing keys that have not been accessed lately, but that is inconvenient. It would be nice if there was another experimental feature in the infrastructure to help us manage session lifetimes.

This problem does not exist for the HttpSessions approach. This is because HTTP Sessions expire if they are not accessed within a specified interval.

Comments

This work is licensed under a Creative Commons License.