In addition to session scope, there is application scope. With
(Bapplication scope, one and only one instance of a class is created.
(B
(BIf you where to use application scope, you would not need to set
(Bmaintain sessions to be true.
(B
(BHowever, in the example of a bank account, you would want each customer
(Bto have their own bank account. The customer would need to hold onto a
(Bcookie to have the server remember their account. Multiple customers
(Bmight be using the same server at the same time, each with their own
(Bcookie, each with their own account.
(B
(BWithout the cookies (or some other session identifier), all the
(Bcustomers would have to share one account. Probably ok writing checks,
(Bbut not ok for deposits :)
(B
(B--Barry
(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>
