W3C home > Mailing lists > Public > www-ws-arch@w3.org > June 2003

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

From: Allan Doyle <adoyle@intl-interfaces.com>
Date: Fri, 20 Jun 2003 09:59:01 -0400
Message-ID: <16115.4901.363943.359295@intl-interfaces.com>
To: www-ws-arch@w3.org

On Friday, June 20 2003 at 08:54:07(-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

Yes, I agree that state is not the right word. I was trying to see if
that's what Marco means. WSDL does not provide a standard way of
capturing any of these conditions.


 > 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
 > 
 > 
 > 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle                         http://www.intl-interfaces.com
+1.781.433.2695 (Office)            adoyle@intl-interfaces.com
+1.781.634.0421 (FAX)
Received on Friday, 20 June 2003 09:59:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:21 GMT