Of course.

Thanks to Chris, Barry and others that have replied. It is all a lot clearer to me now.

I think it's time to start playing around with an implementation, then I may return with some more questions ;)

Regards

David



Chris Forbis wrote:

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.












Reply via email to