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:34:55 GMT
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