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

Reply via email to