Yes. How else would the server know this is the same connection? Each call is a new connection. Unless the client passes something the server has no way to link the calls back to being in the same "session."
-----Original Message----- From: David Peterson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 3:48 PM To: [EMAIL PROTECTED] Subject: Re: Stateful Web Services Hi Steve, But in the simplest possible case, where I just want to persist data between *invocations* (i.e. separate calls), do I still need session info to be propogated client side? e.g. Call 1: deposit(100); Call 2: deposit(200); Call 3: getBalance() -> 300 Call 4: withdrawl(50); Call 5: getBalance() -> 250 Where Call 1 - Call 5 are 5 separate invocations (maybe from the same client, but maybe not). Regards, David Steve Loughran wrote: >----- Original Message ----- >From: "David Peterson" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Wednesday, January 15, 2003 12:02 >Subject: Re: Stateful Web Services > > > > >>Thanks Barry, >> >>This was the kind of "statefulness" and "persistence" that I am >>interested in (though I was also interested to hear what was said re >>SOAP and sessions by Anne et al., as this was another question I had). >> >>Can you tell me, why does the client need to set "maintain sessions" to >>TRUE (Axis) (or use the cookie container in .NET). I would have thought >>that for the example (bank account) that you and I describe, >>preservation of state would be an entirely server-side consideration, >>with no client-side requirements other than a valid SOAP invocation? >> >> > >the client needs to provide some means of identifying the call, so as to >bind it to a session, otherwise the server doesnt know which session to >associate with a call. > >All the session data can live server side, or you can send it back >serialized and encrypted inside soap headers, if you so desire. > > > > > >
