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

It seems that there are still a few important examples of Web services where the interaction itself is stateful. For example a BPEL process should fall under that category.
BPEL uses information from the messages received to figure out which process instance the submitter is interested in, but that message information is used to correlate with an internal context/instance which keeps a bunch of internal process variables. The value of those variables depends on the history of previous calls for that particular instance.

Ugo

> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Friday, June 20, 2003 8:15 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
> 
> 
> 
> 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 16:54:19 UTC