Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The following page has been changed by RajithAttapattu: http://wiki.apache.org/ws/FrontPage/Axis2/SessionMgmtProposal ------------------------------------------------------------------------------ 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 ideas is to introduce a concept of session management that goes beyond ServiceGroupContext and spans beyond several service groups during a session with a client. + 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 we introduce UserContext. @@ -17, +17 @@ 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 wherehousing facilities and a poor distribution chain. + 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. @@ -27, +27 @@ They have decided on the following architecture - ` Company A System(Exposed via SOAP) Company B System(Exposed via SOAP) ` + ` Company A System(J2EE) Company B System(.NET) ` ` \ / ` - \_______________________________________/ + ` \_______________________________________/ ` - | | - | Web Services Deployed on Axis2 | - | that act as middleware | - |_______________________________________| - | - | - _______________V________________ - | | - | website that's deployed on | - | tomcat that has a soap cleint | - |________________________________| - + ` | | ` + ` | 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 === + We would like to propose a UserContext that would be able to bridge the gap between different 2..n seperate service groups. A UserContext would hold one or more ServiceGroupContexts and WebServices that is deployed in User Scope (The name can be changed if it doesn't suit :) ) will have accessed to the UserContext to share the info. + We are only proposing the concept/design and not the implementation details. The implementation will be done in a manner that is consistent with the existing Axis2 architecture to accomodate the above proposal. + + For soap client we will provide a SOAP header in the form of a session id. + This session id will be mapped to ServiceGroupContext id if it's Session Scope and UserContext id if it's User Scope. + + We also think of providing a Unified Interface to the Service Authors wehether the services are deployed in Session Scoped or User Scoped. This is a nice to have from an Architectural point of view. Bcos if the Service Author decides to switch between the two then he can do it with minimal code change. +
