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:24:13 UTC