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

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?

-----Original Message-----
From: Allan Doyle [mailto:adoyle@intl-interfaces.com] 
Sent: Friday, June 20, 2003 8:24 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



On Friday, June 20 2003 at 11:35:41(+0200) marco wrote:
[...]
 > 
 > WSDL and SOAP don't support:
 > a) The concept of stateful service instance
 > b) Stateful interaction 
 > -  Object passing, neither by value nor by reference
 > 
 > I use the term "Stateful Web Service Instance" with a meaning
compatible  > with the following: "Grid services can maintain internal
state for the  > lifetime of the service. The existence of state
distinguishes one  > instance of a service from another that provides
the same interface. We  > use the term Grid service instance to refer to
a particular  > instantiation of a Grid service. " [6.1 The OGSA Service
Model] 
 > In this meaning, the relation between a web service and its stateful
> service instances vaguely resemble the one of a class and its objects.
> If Stateful Service Instances are supported, issues such as lifetime
> management and remote instance references must be taken into account.
In  > this meaning, "Stateful Web Service Instance" are today neither  >
pervasive nor standard.  > 
[...]

I think it might help to look at an example. I think I understand what
Marco is trying to describe, but I'd like to make sure.

In the spatial community, (specifically in the Open GIS Consortium
(OGC)) we have developed an interface called a WMS (Web Map Server). WMS
is mostly RESTful but that does not matter for this example.

WMS defines 3 interfaces (maybe some would call them methods). One of
these allows you to ask for a map over any geographic area. Another lets
you ask for specific information about a point on a map you have already
gotten back. And the third lets you ask the WMS what kind of maps, over
what geographical areas it can draw.

Now imagine that there are two WMS instances out there. One can draw
maps over North America, and the other can draw maps over Europe. I
think Marco is calling this "state". I.e. there is a long-running
service (WMS) that maintains its state for the lifetime of the service.
The state is effectively which geographic area the WMS serves. WMS's
also have other lifetime/instance associated state. We would refer to
this state as content. I.e. a WMS can be bound to content that
distinguishes it from other content.

WSDL does not provide a standard way of distinguishing among the two
instances since their interfaces are the same. However, which WMS a
client decides to access depends on which continent the client wants to
get a map from.

To further complicate matters, there can also be content-free WMS's that
can be bound to content dynamically.

[This is, of course, why every WMS has that 3rd method - a client can
ask it what maps it knows about.]

In the Grid computing world, you could imagine many similar situations.
There are a lot of services people want to deploy, sitting on top of
specific data holdings. Often the data holdings can be replicated. Thus
there will be many instances of the same service, some having different
lifetime state. Furthermore, one of the characteristics of the Grid
world is that people want to dynamically migrate processes to be close
to their data. So once a suitable data pool is discovered, a service
instance can be squirted into a closely associated compute node where it
will sit and provide services for some lifetime. This is where there is
need for life cycle management.

What is needed is some standard means of having these service instances
be able to describe themselves so those descriptions can be captured in
a registry. Then clients can query the registry and make decisions about
which instance to connect to. Within the OGC we have a couple of
solutions that are evolving. However, now people are putting these OGC
services inside of Grids. So we share Marco's problems.

Just as a final aside - the other method where you can ask about a
specific point on a map is a more traditional "stateful" interaction.
There, the state is captured by the fact that the client got the map
from the server instance and the client can refer to that map when
talking to the server. Rather than have map handles, we decided that the
client should simply send back the entire original map request along
with the x/y pixel coordinates on that map to the server. The server can
then return what it knows about the data under that pixel. This is more
along the lines of session state. There is private information, known
only to the client and the WMS instance, and they are referring to it
using a token.

Let me know if I'm way off base!

    Allan

Received on Friday, 20 June 2003 09:55:06 UTC