Hi Deepal; When server respond with the reference properties the session works If and only if client choose to send the reference properties back. But unlike the cases client manages the session client is under no obligation to send the reference properties back. I think we both agree to this so far .. then server can not maintain a session transparent to the client. There must be a header that is accepted by the both sides.
I had a chat with Eran, we kind of agreed on this. Ask him I am skeptical on Implementing things that that work with only Axis2 at both ends. Because the user loose whole point of using web services, as the service is NOT interoperable. I am ok to have them as long as they do not get in the way of the architecture or there is a reasonable hope it would be standardized (e.g. WS-Context I purposed).But architectural compromises in fervour of Axis2 to Axis2 things are unacceptable (At least to me) Thanks Srinath On 1/21/06, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: > Hi Srinath and all; > > Well , in the very first request you do not need to send anything , since > server is the one who know about the session and who creates sessions , as > an example client does not know in which session scope the service has > deployed. Say that service is deploy in request scope and user send some > reference parameters in the second request , in that case user does not get > any session stuff. > > Back to the topic :) > After the second request in axis2 if the service is deploy in soap session > or application session then server response with serviceGroupID (I really > like to rename that to sessionID) as reference parameters in the wsa:replyTo > headers, so its up to the client to send that back to server in the next > request if he think that he want to manage session. If server wants to > manage sessions and if user does not send the reference parameters then > server might throw exceptions. > > I am very happy with our current client approach , there user can say > options.setManageSession(true); , then if server send any reference > parameters then those will be stored in the ServiceContext and , when user > send next request those reference parameters will be send automatically. > > And if some one wants to manage sessions across several serviceClient he can > also do that (use case : in the stub case , for each stub it has its own > ServiceClient in it , so if some one want to manage session across several > stub , if they are in same service group) , the way is after you creating > service client you can set its targetEPR , and that will set that as > ServiceConetxt target EPR , and if you set manage session to true then when > you send any request to server all those reference parameters will be send > , and when its get the response back target EPR will be updated to new . > > > Thanks, > Deepal > ................................................................ > ~Future is Open~ > > ----- Original Message ----- > From: "Srinath Perera" <[EMAIL PROTECTED]> > To: <axis-dev@ws.apache.org> > Sent: Saturday, January 21, 2006 8:29 AM > Subject: Re: [Axis2] Transport independent Session Mgt [Proposal] > > > Sorry for interrupting, Let me ask a Q > > Let me take the inout MEP > When a server reply to a request reference property approach works! > because server uses reply to EPR. How can we make it work with the > request. > > How the client know the To EPR, is there any association to WSDL. How > first message on a interaction get a To EPR? Can you explain how in a > In-Out MEP, Service Provider (Server) keep a session across number of > In-Out Invocations? > > Thanks > Srinath > > On 1/20/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > > On Fri, 2006-01-20 at 20:10 -0500, Rajith Attapattu wrote: > > > > > > > > > So if a service is deployed in SOAP session scope we do that with > > > the understanding that any client that uses this service supports > > > WS-Addressing. > > > > > > If above assumption is wrong, How about the client that don' > > > support WS-Addressing ?? is this scenario something to be concerned or > > > not?? > > > > No- WS-Addressing is a core part of the foundation of Web services. If > > the client doesn't support WS-Addressing then its life is very boring > > because it can't participate in pretty much anything except message > > exchanges over a bi-directional protocol such as HTTP. > > > > Sanjiva. > > > > > > > > > > > -- > ============================ > 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
