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