axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <rajit...@gmail.com>
Subject Re: [Axis2] Transport independent Session Mgt [Proposal] Now in Wiki for comments
Date Tue, 24 Jan 2006 15:42:13 GMT
I agree that the current proposal is proposing a User Context tied to the
Context heirachy but after the disscussions I am thinking more and more that
the Session Model should be independent of the context heirachy or else it
want be able to scale effectively.

The way to identify a session would be

a) if WS-Addressing to use the special header

b) If WS-Context to use the session_id it defines

We can have a handler that retrive the session based on the above criteria
and inject it to the MessageContext.

I think this way is simple and cleaner and architecturaly sound than
confusing it with the context heirachy.

Regards,

Rajith.


On 1/24/06, Rajith Attapattu <rajith77@gmail.com> wrote:
>
> Hi All,
>
> >   2. Share data across multiple operations across a service or share
> data
> > across multiple services in a service group
> >To do that share them via the AxisService or ServiceGroup, no need to
> >have context. You need a context IFF you need a scope that is 1:M with
> >Service or ServiceGroup
>
> According to the architecture doc, the "context heirachy/ Descriptions" is
> the information model.
>
> a) I agree that some operational data global or unique to a service or
> group should be held here.
>
> b) but I disagree that session (user specific data) should be held here
>
> I argue that the Session Model should not be confused with the Information
> Model, and it should be independent of it as well from an Architectural
> point of view.
>
> We can't scale effectively if it's tied down to the information model. My
> motivation for the whole session thing is that we need to provide
> scalability and high-availability via session replication.
>
> For that to happen,
>
> a) The Session model should be lightweight and clearly defined with proper
> boundries.
>
> b) It should not be tied to any other model as it might be architecurally
> unstable as there want be a clear demarcation point.
>
> c) when things start to move across the wire (Session replication) having
> a clean, well defined session model is very very important.
>
> Right now the most critical shortcomming of Axis2 as I understand is that
> we don't have a clear picture of what a session is wrt to the current Axis2
> architecture.
> I gues Srinath mentioned that same thing to me.
>
> My suggestion is we should evolve the Session Model independently of
> anything else and inject it to the ServiceAuthor via the message context by
> way of a handler.
>
> If we do that we want have any limitation or complications of associating
> it with ServiceGroups or anything like that.
>
> Regards,
>
> Rajith.
>
> On 1/24/06, Srinath Perera <hemapani@gmail.com> wrote:
> >
> > Hi Deepal;
> > > 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.
> > We should match both HTTP and SOAP sessions to a one SOAP session,
> > AFAIK Axis does it
> >
> >
> > > 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.
> > I think we should use WS-Context or something, I think ppl are
> > converging on that idea.
> >
> > WS-Addressing can not provide a complete solution, it can provide a
> > partial sessions.  To support session there should be a header that
> > both side agrees on
> >
> >
> > > 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
> > It is a illusion, I know it is nice to have it architecturally .. but
> > in real world it do not exists, we are making it up. ( we have been
> > eliminating things that do not have real use cases all the way
> > down,.... but in this case we are adding huge potion to the
> > architecture based on weak use cases ...I argue it is YAGNI .. Had
> > sessions map in to the undefined XServiceContexts I would have agree
> > .. now it do not
> >
> > >   2. Share data across multiple operations across a service or share
> > data
> > > across multiple services in a service group
> > To do that share them via the AxisService or ServiceGroup, no need to
> > have context. You need a context IFF you need a scope that is 1:M with
> > Service or ServiceGroup
> >
> > Thanks
> > Srinath
> >
> > >
> > > Thanks,
> > >  Deepal
> > > ................................................................
> > > ~Future is Open~
> > >
> > > ----- Original Message -----
> > > From: "Srinath Perera" <hemapani@gmail.com>
> > > To: <axis-dev@ws.apache.org>
> > > 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 <rajith77@gmail.com> 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 <hemapani@gmail.com> 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 < hemapani@gmail.com> 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 <rajith77@gmail.com > 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
> > >
> > >
> > >
> >
> >
> > --
> > ============================
> > Srinath Perera:
> >   http://www.cs.indiana.edu/~hperera/
> >   http://www.bloglines.com/blog/hemapani
> >
>
>

Mime
View raw message