Mailing-List: contact axis-user-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-user@xml.apache.org
Message-ID: <8BE017CC8923D511A00A0008C78605EE037B7048@LMOXCH04>
From: Chris Forbis <chris.forbis@veritas.com>
To: "'axis-user@xml.apache.org'" <axis-user@xml.apache.org>
Subject: RE: Stateful Web Services
Date: Wed, 15 Jan 2003 15:51:27 -0500
MIME-Version: 1.0
Content-Type: text/plain

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:peterson@ee.usyd.edu.au] 
Sent: Wednesday, January 15, 2003 3:48 PM
To: axis-user@xml.apache.org
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" <peterson@ee.usyd.edu.au>
>To: <axis-user@xml.apache.org>
>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.
>
>
>
>
>  
>