You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Rajith Attapattu <ra...@gmail.com> on 2006/04/04 15:09:21 UTC
[Axis2] Session Management
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
heirachy
- 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
system.
>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
hard.
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
Thanks,
Rajith
Re: [Axis2] Session Management
Posted by Rajith Attapattu <ra...@gmail.com>.
Hi Deepal,
On a general note I think I should explain the motivation behind my proposal
and then the implementation for an independent light weight session mgt
model. I started with implementing clustering, however I couldn't identify a
clear, distinguishable object model to replicate, hence I spent my energy on
getting that full filled.
So you have agreed on the following points.
A) No unified mgt interface for session mgt
B) No clear session model to replicate
C) No clear API to extend or customize.
I guess the above points are extremely useful for an enterprise application
developer to have in hand. There are couple of point an architect would
consider when choosing infrastructure. Some of the key points are
A) Manageability
B) Scalability and HA
C) Extendability to support future expansions
When I defined the session API I had those key points in mind.
Let me answer the other points
>the whole idea of service group is a session , I will tell u a simple
>use case. Say that we have three services
> 1. Login Service
> 2. Do smt Service
> 3. Logout Service
>So I think normal session when we loging we start the session , and when
>we logout we invalidate the session.
>So we came up with the idea of service group to support this. So
>assuming service group id as soap session is correct to me (may be I am
>wrong , I have this mind set since I am came up with the idea.)
Service Groups are good, however it's limited when considering the following
use cases.
Please check the use cases identified in the wiki proposal
http://wiki.apache.org/ws/FrontPage/Axis2/SessionMgmtProposal?action=show
>our transport session go beyond service group , I mean in the current
>impel . Only problem with axis2 features is we have 10000 of features
>but we dont have not document them any where.
I was aware of the transport session and the fact that it goes beyond the
service groups.
But the downside is it is only available for HTTP.
Thats why I think we really need to have a transport and service group
independent session mgt model thats light weight, easy to manage and easily
replicated.
However I think we should leave the transport session for some time as if
the client doesn't use WS-Addressing atleast they have an alternative. Also
I can try to add that as another stratergy for session mgt to be it into
this unified model.
So we can have
a) WS-Addressing end point references
b) WS-Conext
c) HTTP transport (propritery but good alternative if there is no WS-A on
client side)
However I think service groups are redundent. Srinath also had some posts on
why service groups are not really required.
I do see a value for service groups from a deployment perspective, but still
I am not convinced about it's usefullness if we adopt the new session model.
If you are also convinced maybe we can phase this out slowly.
Please feel free to keep discussing and I hope others will also express
there opinions.
Regards,
Rajith
On 4/5/06, Deepal Jayasinghe <de...@opensource.lk> wrote:
>
> Hi Rajitha;
>
> Rajith Attapattu wrote:
>
> > 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)
>
> hey not at all , which is called community process , otherwise how can
> we come up with best solutions.
>
> >
> > 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
> > heirachy
> >
> that is yes no answer :)
> The correct name of service group id should be soapSessionID
>
> > *
> > They have no common interface to control management aspects
> > (like timeout, max_no_of sessions ...etc)
> >
> yes , I agree with that you.
>
> > *
> > It's very difficult to replicate those sessions (from
> > scalability and HA)
> >
> yes :(
>
> > *
> > 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.
> >
> the whole idea of service group is a session , I will tell u a simple
> use case. Say that we have three services
> 1. Login Service
> 2. Do smt Service
> 3. Logout Service
>
> So I think normal session when we loging we start the session , and when
> we logout we invalidate the session.
>
> So we came up with the idea of service group to support this. So
> assuming service group id as soap session is correct to me (may be I am
> wrong , I have this mind set since I am came up with the idea.)
>
> > *
> > If somebody wants to customise the session mgt, there is no
> > visible or distinct API to do so
> >
> >
>
> agreed
>
> > 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.
> >
> our transport session go beyond service group , I mean in the current
> impel . Only problem with axis2 features is we have 10000 of features
> but we dont have not document them any where.
>
> > *
> > 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 system.
>
> yes I am happy to do that , that why I comment on the mail as well :)
>
> >
> > >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 hard.
> > I think the module (.mar) approach is a clean way to add handlers
>
> the advantage of that is if some one want session management then he
> can add the module, by default he wont get any session management stuff.
> And I think that would be the right scanario.
>
> >
> > 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
>
> if you going as module , then you can have the config in module.xml
>
> >
> >
> > Thanks,
> >
> > Rajith
>
>
> --
> Thanks,
> Deepal
> ................................................................
> ~Future is Open~
>
>
>
Re: [Axis2] Session Management
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi Rajitha;
Rajith Attapattu wrote:
> 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)
hey not at all , which is called community process , otherwise how can
we come up with best solutions.
>
> 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
> heirachy
>
that is yes no answer :)
The correct name of service group id should be soapSessionID
> *
> They have no common interface to control management aspects
> (like timeout, max_no_of sessions ...etc)
>
yes , I agree with that you.
> *
> It's very difficult to replicate those sessions (from
> scalability and HA)
>
yes :(
> *
> 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.
>
the whole idea of service group is a session , I will tell u a simple
use case. Say that we have three services
1. Login Service
2. Do smt Service
3. Logout Service
So I think normal session when we loging we start the session , and when
we logout we invalidate the session.
So we came up with the idea of service group to support this. So
assuming service group id as soap session is correct to me (may be I am
wrong , I have this mind set since I am came up with the idea.)
> *
> If somebody wants to customise the session mgt, there is no
> visible or distinct API to do so
>
>
agreed
> 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.
>
our transport session go beyond service group , I mean in the current
impel . Only problem with axis2 features is we have 10000 of features
but we dont have not document them any where.
> *
> 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 system.
yes I am happy to do that , that why I comment on the mail as well :)
>
> >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 hard.
> I think the module (.mar) approach is a clean way to add handlers
the advantage of that is if some one want session management then he
can add the module, by default he wont get any session management stuff.
And I think that would be the right scanario.
>
> 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
if you going as module , then you can have the config in module.xml
>
>
> Thanks,
>
> Rajith
--
Thanks,
Deepal
................................................................
~Future is Open~