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

Yes, that's one good reason why non-trivial Web applications tend to
maintain state (using the word in the sense you illustrate) -- we don't
want to keep logging in over and over, partly for performance reasons
and partly because the login interface requires special handling because
of security concerns.  I think that tends to be what one means by
"state" if one is thinking of Web services with the RPC mindset.  If,
however, you are in the document exchange mode I think you tend, at the
least, to have a slightly different style of expressing it.  Whether the
concepts are the same or similar on an underlying level is more than I
understand at the moment.  But from a document transfer viewpoint I
think of the "state" as some information that keeps track of what stage
of the process we are in.  That is, A has sent an invoice to B, B has
acknowledged the receipt but has not yet returned any payment
information or whatever other branch of the transaction B might choose
to follow.  If you are in the grid computing mode it seems that you have
yet another mindset, but I am still unclear what it is.  I myself would
have thought that it would not be something that characterizes the
service for it's entire lifetime but rather information that
characterizes the stage at which this particular overall computation is
at.  As in, "We are now engaged at simulating the state of the reservoir
at time = 20".  Or perhaps, "This component of the grid computing
machinery is currently engaged at simulating the Ooga field reservoir at
position 34,12,69 and time 20".  Not, "This component of the grid
computing machinery calculates fluid flow through a reservoir at some
position and time".  The latter would be, I would think, part of the
description.

It seems to me that there may be two somewhat different usages of
"state" but not three.  That is, it seems to me that the last one is
service description, not state.  But, of course, I don't know much about
grid computing.  Maybe there really is a mismatch between how that
community uses the word and how I think we tend to.

-----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:56:30 UTC