Transport Independant Session Management Proposal

Introduction

In order to provide scalability and High Avaialability to Axis2 we have realized that there needs to be a session managment concept that goes beyond the notion of transport or service group context. Currently there is a Session Context which keeps transport level session info like Http cookie id. Also if a service is deployed as SOAP Session scope ServiceGroupContext provides the means of sharing information between Services within the same group.

Our idea is to introduce a concept of session management that goes beyond ServiceGroupContext and spans beyond several service groups during a session with a client.

For that I propose an independent lightweight session management module

Use Cases

Lets consider the following use case to better understand why we would need a notion of session and session mgt as web services typicaly tend to be stateless. We are also not advocating moving tons of data around a session as a means of sharing data amoung web services.

Company A has merged with Company B recently and wants to consolidate there computer systems to provide better service for the customers of both companies via a unified web interface.(Business requirment)

Company A sells Books/DVDs/Records online but has inadequate warehousing facilities and a poor distribution chain. Company B has excellent wherehousing capabilities and good distribution/shipping department. Hence the motivation for a merger.

Company A has a J2EE powered application for the online store and Company B has has shipping/distribution-chain management system powered by the .NET platform.

After the merger a, consulting company hired to integreate the 2 systems has decided to provide SOAP based interfaces to both system to provide a unified platform to communicate with both systems in a platform independent manner.

They have decided on the following architecture

Scenario1

Scenario2

It would be unresonable to ask the user to log into the shipping/distribution-chain system, which breaks the notion of a unified web interface, hence not satisfying the business requirment I specified above of providing a unified web interface.

Hence we propose a UserContext that spans over multiple services which will cary session information over the period of the session thus making the logical seperation of service groups transparent to the end user.

What Axis2 Currently Supports

As mentioned above the current Axis2 can only support Scenario1.

The Proposal

Based on Srinaths comments and disscussion threads the initial proposal of UserContext was discarded and an independent Session Management module was introduced. It's a layered architecture with 4 main interfaces.

  1. Session
  2. SessionManager

  3. SessionIdFactory

  4. SessionManagerFactory

Two handlers will intercept the in and out pipeline. The handler in the in pipeline will retrive or create a session based on the precense or absence of a session id. The handler in the out pipeline will denote end of request and will mark the session for passivation.

The idea was to enable the extention of the session model to support fail over and clustering There is a code and documentation patch provided in JIRA and discussions are going on in the mailling list.

Comments

Quoting from http://www.idealliance.org/proceedings/xml05/ship/54/xml2005-wssessions.HTML

" It is intended to be used as a building block by other specifications that require session constructs -- in fact, several specifications related to transaction protocols in OASIS are already building on WS-Context"

If this claim is true we will be best placed using the WS-Context approch. See 3.2. Web Services Sessions using WS-Context. RM WS-AT and WS-Coordination people can you verify?


The new proposed structure can easily add a layer to implement WS-Context