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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED] > 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" <[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 > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > ============================ > > > > Srinath Perera: > > > > http://www.cs.indiana.edu/~hperera/ > > > > http://www.bloglines.com/blog/hemapani > > > > > > > > > > > > > > > >
