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. + + ---- /!\ '''Edit conflict - other version:''' ---- 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. + + ---- /!\ '''Edit conflict - your version:''' ---- + 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. + + ---- /!\ '''End of edit conflict''' ---- For that we introduce UserContext. @@ -17, +24 @@ 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) + + ---- /!\ '''Edit conflict - other version:''' ---- Company A sells Books/DVDs/Records online but has inadequate warehousing facilities and a poor distribution chain. + + ---- /!\ '''Edit conflict - your version:''' ---- + Company A sells Books/DVDs/Records online but has inadequate warehousing facilities and a poor distribution chain. + + ---- /!\ '''End of edit conflict''' ---- Company B has excellent wherehousing capabilities and good distribution/shipping department. Hence the motivation for a merger. @@ -27, +41 @@ They have decided on the following architecture + + ---- /!\ '''Edit conflict - other version:''' ---- ` Company A System(J2EE) Company B System(.NET) ` ` \ / ` ` \_______________________________________/ ` @@ -62, +78 @@ 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. + ---- /!\ '''Edit conflict - your version:''' ---- + ` 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. + + ---- /!\ '''End of edit conflict''' ---- + === What Axis2 Currently Supports === + + ---- /!\ '''Edit conflict - other version:''' ---- As mentioned above the current Axis2 can only support Scenario1. + + ---- /!\ '''Edit conflict - your version:''' ---- + As mentioned above the current Axis2 can only support Scenario1. + + ---- /!\ '''End of edit conflict''' ---- === The Proposal === + + ---- /!\ '''Edit conflict - other version:''' ---- 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. @@ -77, +140 @@ 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. + ---- /!\ '''Edit conflict - your version:''' ---- + 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. + + ---- /!\ '''End of edit conflict''' ---- +
