- 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