Hi Srinath;
I agree with you that we need to introduce new context to store session
information , currently we have class called session context and which use
for managing transport session for example , in HTTP case if user send
cookie back axis2 will find the correct session context and that session
context may contains multiple ServiceGroupContext init. So that if services
author want he can manage transport session nice way across multiple service
group as well.
But in SOAP session scope and application session scope we have no way to
manage session across multiple service group , so my idea is to use above
SessionContext to mange each level of session scope and send the session id
wsa headers , so if some one want to manage session then its upto the user
to send those reference parameter back , then he will get full support of
session.
and really I don't like to get ride of service context and service group
context , since that has two thing
1. Consistent description and context hierarchy
2. Share data across multiple operations across a service or share data
across multiple services in a service group
Thanks,
Deepal
................................................................
~Future is Open~
----- Original Message -----
From: "Srinath Perera" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, January 23, 2006 8:19 AM
Subject: Re: [Axis2] Transport independent Session Mgt [Proposal] Now in
Wiki for comments
Hi Rajith;
A)
I agree on principally having a protocol independent layer and define
a session representation on the context hierachy is the way to go! and
we have it abstractly with ServiceContext and ServiceGroupContexts.
But I do not like idea of including that without at least ONE
implementations as that will not help anyone other than few intersting
emails.
What I thought was if we are going to invent some header that is our
own, we as well better use WS-Context ones.
B)
I belive we need to define clearly does sessions span over multiple
ServiceGroups
1) If YES we need a new context, and I belive both the ServiceContext
as well as ServiceGroup context are REDUNDENT and we can provide all
functionality we expect with new context only. (Design is complete
when there is nothing to taken out)
2) If NO how we handle a Service which want to share in number of
sessions?, there will be senarios we can not handle
Thanks
Srinath
On 1/22/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
Srinath,
Thanks a lot for posting the links to those articles.
I agree that WS-Context maybe more sesion oriented and we currently
support
only WS-Addressing.
So supporting WS-Context could be done in the future if thats the way to
go.
Unfortunately there is no standard and the direction to take is a
difficult
decesion when it comes to session with web services.
However Srinath thats more protocol level and this proposal deals at the
Axis2 layer.
So in short wether we use WS-Context or WS-Addressing we still has to make
sure we bridge the gap between service group contexts if we need a session
to continue over multiple Service Groups.
Part of the Axis2 objectives is to hide the complexicity of the protocol
layer and provide only a higer-level abstraction to the service author so
that he can concentrate on the business logic.
So I still belive a proper abstraction of a session & management should be
provided thats also indepedent of the protocol layer.
Actually it will be part of the dispatcher or something like that to pick
up
the session id from the handlers or what ever and retrive the session for
that client.
So maybe we have different handler that picks up the session id from the
soap header in WS-Addressing or is it's WS-Context it will be from the
context header where session id is provided explicitly.
Did I answer your concern ?? Also check the other thread on session mgt
for
the answer to your question about multiple services.
Regards,
Rajith
On 1/20/06, Srinath Perera <[EMAIL PROTECTED]> wrote:
> 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?
>
> Thanks
> Srinath
>
>
>
>
> On 1/20/06, Srinath Perera <[EMAIL PROTECTED]> wrote:
> > Guys find these two links .. I think we should read this
> > 1) The Session Concept and Web Services
> >
http://www.idealliance.org/proceedings/xml05/ship/54/xml2005-wssessions.HTML
> > 2) Session Modeling for Web Services,
http://wscc.info/p51561/files/57-hal.pdf
> >
> > Thanks
> > Srinath
> >
> > On 1/20/06, Rajith Attapattu <[EMAIL PROTECTED] > wrote:
> > >
> > > Hi All,
> > >
> > > The proposal for session mgt is now in wiki
> > >
http://wiki.apache.org/ws/FrontPage/Axis2/SessionMgmtProposal
> > >
> > > Please do submit your comments on this and once everybody
reviewed/modified
> > > the proposal then we can take a vote on this.
> > >
> > > Regards,
> > >
> > > Rajith.
> >
> >
> > --
> > ============================
> > Srinath Perera:
> > http://www.cs.indiana.edu/~hperera/
> > http://www.bloglines.com/blog/hemapani
> >
>
>
> --
> ============================
> Srinath Perera:
> http://www.cs.indiana.edu/~hperera/
> http://www.bloglines.com/blog/hemapani
>
--
============================
Srinath Perera:
http://www.cs.indiana.edu/~hperera/
http://www.bloglines.com/blog/hemapani
