- From: Mark Baker <distobj@acm.org>
- Date: Fri, 20 Jun 2003 10:21:44 -0400
- To: www-ws-arch@w3.org
That sounds more like b) state; stateful interaction to me, Roger. How about an example to explain the difference? interface Lightbulb { getState(); setState(); } This interface obviously deals in lightbulb state, which is what I thought was meant by a) state. Each service instance contains information which represents the state of the lightbulb. But, the interactions with each lightbulb are state*less*, because each message contains all the information necessary to process that message. This would be an example of how to make that interface state*ful*; interface Lightbulb2 { getState(); setState(); login(); logout(); } Now, a getState() message doesn't contain all the information necessary to process the message, because some of that information is held by the service itself; specifically, whether or not the user is logged in. In order to make that interaction stateless again, the login info needs to be in the message somewhere, ala; getState( userid, password ); MB On Fri, Jun 20, 2003 at 08:54:07AM -0500, Cutler, Roger (RogerCutler) wrote: > > This is certainly a different conception of maintaining state than what > I am familiar with. I think that the state maintenance I am familiar > with does not refer to the lifetime of the entire service (like what > geographic area a service supports), which I sort of thought would be > part of the description of the service itself as opposed to anything > about state. Instead I think of state as being a characteristic of a > series of invocations of services that are linked together into one > "transaction" (loosely interpreted -- I am not talking about rollbacks > and stuff here). The state is then the collection of information that > is necessary for a service somewhere in this chain to understand what > the context of the invocation is. > > Does that make sense? Am I somehow out in the weeds on this?
Received on Friday, 20 June 2003 10:17:07 UTC