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

The notion of a "stateless interaction" has nothing to do with 
"maintaining state".
Even RESTful resources "maintain state". Nothing wrong with that at all:)

The distinction "stateless interaction" has to do with whether or not the 
server/service
has to remember  or know the state of the client  to make sense of any 
given 
interaction. If all the information needed to service a request is carried 
in the
request message, then the invocation is stateless.

Quoting from Roy's thesis:

"5.1.3 Stateless
        We next add a constraint to the client-server interaction: 
communication must be stateless in nature, as in the 
client-stateless-server (CSS)   style of Section 3.4.3 (Figure 5-3), such 
that each request from client to server must contain all of the 
information necessary to understand     the request, and cannot take 
advantage of any stored context on the server. Session state is therefore 
kept entirely on the client."

IMO, the OGSi "stateful Web service instances" need not be implemented
in a "stateful" manner according to this definition. The distinction there 
is really
one of instance with regards to the description of a service which has a 
fixed
URI for its address. As long as the "instance" context is passed with each 
message
between client and service, then technically, it can still offer a 
completely stateless
interaction. It doesn't make in necessarily stateless, but it certainly 
doesn't
preclude a stateless interaction.

Allan's "final aside" example is IMO actually stateless if I understand it 
correctly
(at least, it certainly could be implemented in a stateless manner)

The WMS server does not need to know that the client has previously 
retrieved
the map. That would be stateful. If I understand it correctly, the server 
should be
able to respond to any request for "more information" where a map request
also contains an x/y coordinate if it uses a GET with a URI for the map 
resource and the
x/y coordinates are expressed as (additional) query arguments.

If, on the other hand, the client *had* to retrieve a map before sending a 
request
for more information about a particular spot on the map, and the server 
were implemented
such that it *had* to remember which map the client had previously 
retrieved to make sense of
the invocation to get more information about some coordinates on the map, 
well that
would be a stateful interaction and would suffer all of the issues 
relevant to stateful
interactions (e.g. if the server failed between the time that the client 
retrieved the map
and were restarted before the request for more information arrived it 
could not
service that request unless it presisted the knowledge of which map the 
client
had previously retrieved (state) and used a cookie to recall that state 
associated
with the client... this might be a rather expensive bit of overhead to 
mitigate against
server failure).

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

www-ws-arch-request@w3.org wrote on 06/20/2003 09:54:07 AM:

> 
> 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 11:14:51 UTC