- From: Allan Doyle <adoyle@intl-interfaces.com>
- Date: Fri, 20 Jun 2003 09:59:01 -0400
- 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 UTC