axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <>
Subject [Axis2] Session Management
Date Tue, 04 Apr 2006 13:09:21 GMT
Hi Deepal,

You have raised some very good questions. So I thought of bringing it to the
list and answering them there so others could also joing the disscussion or
raise their concerns

My answers are inline
>Deepal Jayasinghe commented on AXIS2-532:
>I went though the patch and understood that you have done a great job , thx
for doing all those. I have few question to clarify.
Thank you very much for taking your time to verify the patch

> We have transport independent session management called SOAP session , so
if you deploy a service in a SOAP session scope then >service will have
transport independent session management. So there what will happen is ;
> when you deploy a service in SOAP session , when a service get a request
it will send a serviceGroupID (which is the session ID) > back , so if user
send that back (in the next request) then user will be able to come back to
the same session.

> In the meantime we have transport dependent session as well , both in
simple HTTP server case and AxisServlet case we do support >transport
dependent session management.
> I think I am missing something please explain to me , the difference
between what we have right now and what you have done.

This is an excellent question, thank you for raising it.
Following is the difference btw what we have right now and the what I have
done within the new implementation.
(Please do not think I am trying to critizie the current impl in any way. I
am simply pointing out the differences and the advantages the new system
brings in)

The main difference from an Web Services POV is that the new impl that I
have proposed is one of the standard ways of handling session mgt in Web
Services. Currently there is 2 (Please refer to the previous threads on
session mgt, Srinath has posted some research papers on this topic)
1.) WS-Context
2.) Using WS-Addressing EPR's

Implementing WS-Context on top of this is going to be trivial as it has a
clearly defined session model.

The current impl.

   - Has distinctly 2 different ways of managing session (one is service
   grp id, other is the transport session)
   - Which means we have two distinct models for session.
   - Also the service group id is tightly coupled with the Context
   - They have no common interface to control management aspects (like
   timeout, max_no_of sessions ...etc)
   - It's very difficult to replicate those sessions (from scalability
   and HA)
   - Even if we try to replicate sessions we need two approaches as they
   are 2 distinct models.
   - Service Group concept is limited to session mgt within the group, a
   service outside the group is unable to acces the session.
   - If somebody wants to customise the session mgt, there is no visible
   or distinct API to do so

The new impl

   - One lightweight model across all transports.
   - Easy to replicate in a clustered environment.
   - No distinction btw service groups, so the session goes beyond a
   service group.
   - Standard way of doing session mgt from a web services POV.
   - One single management interface to control session mgt
   - There is a standard API and people can easily extend or customize
   the existing behaviour.
   - The session model is independent so it can evolve without any impact
   on the CORE

If you need further clarification on this points I am more than happy to
explain. Deepal if you feel we have overlapping features can we slowly phase
out the current impl provided that we all agree the benifits of the new

>One other thing I understood from your path is that  you can achieve the
same goal by adding an axis2 module (.mar) , since what you >have done is
getting the session at the in handler and adding session id into outgoing
message. So the best thing you should do is get >the session by In handler
and populate MessageContext using that.

Totaly agree on this. I spoke with Srinath before this and we discussed this
and he mentioned that moving back and forth btw the 2 approached is not that
I think the module (.mar) approach is a clean way to add handlers

However I have a question on where to put the config? Can I still keep that
in axis2.xml? I prefer to keep it there.
But I like to hear everybodys suggestions on this



View raw message