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
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
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
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.
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.
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.
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.
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