axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruchith Fernando <ruchith.ferna...@gmail.com>
Subject Re: [Axis2] Transport independent Session Mgt [Proposal] Now in Wiki for comments
Date Thu, 26 Jan 2006 04:12:54 GMT
Hi Rajith,

A dir created for you in the scratch area:

https://svn.apache.org/repos/asf/webservices/axis2/trunk/archive/java/scratch/rajith

Thanks,
Ruchith

On 1/26/06, Rajith Attapattu <rajith77@gmail.com> wrote:
> Hi Guys,
>
> I will go ahead and implement the things we disscussed in the thread.
> Otherwise As Srinath pointed out it will only result in a few interesting
> emails.
>
> Besides if I have prototype then people can play around with it and get a
> better feel for it.
>
> I would appreciate if somebody can create a sandbox for me in the sractch
> area and  I can create a JIRA and submit patches from time to time so incase
> my laptop crashes all work is not lost. So somebody can apply those patches
> in the sandbox area and will not impact the main code base.
>
> Can somebody help me with this??
>
>
> Regards,
>
> Rajith.
>
> On 1/24/06, Rajith Attapattu <rajith77@gmail.com> wrote:
> >
> > 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