Differences between revisions 17 and 18
Revision 17 as of 2006-06-01 20:20:13
Size: 7099
Comment:
Revision 18 as of 2009-09-20 22:48:05
Size: 7099
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

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

  •   Company A System(J2EE)                           Company B System(.NET)                              \                                         /                                            \_______________________________________/                                             |                                       |                                             |   Web Services Deployed on Axis2      |                                             |       that act as middleware          |                                             |_______________          ______________|                                             | ServiceGroupA |        | ServiceGrpB  |                                             |_______________|________|______________|                                                                |                                                                                     |                                                                      _______________V________________                                                     |                                |                                                    |  website that's deployed on    |                                                    |  tomcat that has a soap cleint |                                                    |  to access the web services    |                                                    |________________________________|                              

  • Service Group A represents the web services that interect with Company A's system Service Group B represents the web services that interect with Company B's system

    SrvGrp == ServiceGroup in the following section

Scenario1

  • A client logs in into the system checks his wish list to see if those items are available. Here the WebServices in SrvGrp A can work within the Group to querry information like user_profile and wish_list from Company A's sysetm by sharing info like user_id through the ServiceGroupContext. So the Current Axis2 architecture can support this scenario.

Scenario2

  • A Client Logs in to the system and selects 2 DVD's and wants to ship them to her brothers address. So WebServices within SrvGrp A can querry info like user_profile, product_info and hold the user_id and shopping cart item_id's within the ServiceGroupContext and share it among all services within SrvGrp A to check user authentication status, product availability ..etc. However when the Services within SrvGrp A tries to contact Services within SrvGrp B to schedule shipping and wearhouse holding information it has no way of passing the user information as there is no facility to pass information within one ServiceGroupContext to another. This is currently a limitation in the current Axis2 Architecture, which will expose the logical partition within service groups to the end user.

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

FrontPage/Axis2/SessionMgmtProposal (last edited 2009-09-20 22:48:05 by localhost)