RE: Web Service Description and stateful services - (on the 'www-ws@w3.org' list) Debating on a) Stateful Web Service Instances b) Stateful Interaction - OGSI

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org] 
Sent: Friday, June 20, 2003 9:22 AM
To: www-ws-arch@w3.org
Subject: Re: Web Service Description and stateful services - (on the
'www-ws@w3.org' list) Debating on a) Stateful Web Service Instances b)
Stateful Interaction - OGSI



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:40:50 UTC