[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsdm] WSDM will discuss the 'Grid Application Framework' paperSept 4th.
Heather, Here is one response and a reply from an author of the paper. FYI. -- John DeCarlo, The MITRE Corporation, My Views Are My Own email: firstname.lastname@example.org voice: 703-883-7116 fax: 703-883-3383 DISA cube: 703-882-0593
Return-Path: <email@example.com> Received: from smtpsrv1.mitre.org ([184.108.40.206]) by mailsrv1a.mitre.org (Netscape Messaging Server 4.15) with ESMTP id HK1AKZ00.E1S for <firstname.lastname@example.org>; Fri, 22 Aug 2003 14:41:23 -0400 Received: from avsrv1.mitre.org (avsrv1.mitre.org [220.127.116.11]) by smtpsrv1.mitre.org (8.12.9/8.12.8) with ESMTP id h7MIeQIS021660; Fri, 22 Aug 2003 14:40:26 -0400 (EDT) Received: from mcs.anl.gov (cliff.mcs.anl.gov [18.104.22.168]) by smtpproxy1.mitre.org (8.12.9/8.12.8) with ESMTP id h7MIeJTv028340; Fri, 22 Aug 2003 14:40:19 -0400 (EDT) Received: (from listserv@localhost) by mcs.anl.gov (8.11.6/8.9.3) id h7MIToc108528 for grdfm-ogsi-wg-outgoing; Fri, 22 Aug 2003 13:29:50 -0500 Received: from pony1pub.arc.nasa.gov (pony1pub.arc.nasa.gov [22.214.171.124]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h7MITcB283014 for <email@example.com>; Fri, 22 Aug 2003 13:29:38 -0500 Received: from [126.96.36.199] (account firstname.lastname@example.org HELO nas.nasa.gov) by pony1pub.arc.nasa.gov (CommuniGate Pro SMTP 4.0.6) with ESMTP-TLS id 2342039; Fri, 22 Aug 2003 11:29:37 -0700 Message-ID: <3F46615A.email@example.com> Date: Fri, 22 Aug 2003 11:30:50 -0700 From: Peter Vanderbilt <firstname.lastname@example.org> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>, email@example.com Subject: [ogsi-wg] Grid-SOA and service state References: <BC28A9E979C56C44BCBC2DED313A447001EC3AD8@bond.ncl.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.21 X-Spam-Level: Sender: firstname.lastname@example.org Precedence: bulk <div class="moz-text-flowed" style="font-family: -moz-fixed">Savas Parastatidis wrote: > [...] > The attached document investigates the Grid architecture and its > relationship to the Web Services Architecture. This paper (see ), which I'll call the Grid-SOA architecture, has a lot to like, especially the wider use of emerging WS technologies. But the paper contains a fair amount of discussion about the state of a Grid Service using a terminology different from OGSI's, leading to an "apples-to-oranges" comparison. I'd like to try to tease these different notions apart. In OGSI, a service encapsulates some resource. Examples of resources include databases, machines, jobs and client-supplied notification sinks. To the extent that the resource has identity, state and lifetime, so does the service. In some sense, what OGSI is about is providing access to *resources* via standard interfaces -- over-simplified, the service is just a wrapper for the resource. So for resources with identity, OGSI has GSHs; for resources with state, OGSI has service data; and for resources with limited lifetimes, OGSI has factories and termination operations. I suspect that the authors of Grid-SOA think of a service as an entity separate from the resource to which it provides access. So when they talk of the service as being stateless and not having a lifetime, they are really talking about something different than the resource. In this thinking, a change in the state or existence of a resource is independent from the state and existence of this "accessor" service. The "service state" the Grid-SOA folks talk about seems to be associated with a client, a connection or an activity. They talk about a Grid Service Instance as being created to "maintain interaction-specific state (or session-based state)". And they propose a "context" as an alternative to this state. In particular, a context (as I understand it) is a piece of information returned to the client in order to allow the service to recognize that client in subsequent invocations -- it's a lot like a cookie in the web world. (I recognize that the context can be used to identify a resource instance but I'm uncomfortable about that for reasons I won't go into here.) This cookie-like notion of service state is orthogonal to OGSI's notion of service state. In OGSI, one common implementation strategy is to provide access to a resource using a server process that maintains little or no state of its own, certainly no per-client state or per-connection state. (If it needs such state, the context mechanism could be used.) I suspect that what I call "the process" here is what the Grid-SOA people think of as "the service" and, so, this strategy provides pretty much what the Grid-SOA people mean by stateless services. But in OGSI, the "service" logically includes the resource, so when we talk about the state of the service, we include the state of the resource. It is through a service's operations that one gets to access a database, discover the load on a machine, determine the state of a job or send a notification to a client. Clearly in this notion of "service", a service is stateful -- if I add something to the database, the state of the database changes and, so, subsequent invocations *are* affected by the prior ones (in contrast to the text between the first two boxes on page 2 of ). Resources have identity. For example, two different jobs are, well, different and when I ask for the state of a particular job, it's not OK to get the state of a different one (even though the actual server process is providing access to hundreds of jobs, including several of my jobs). The OGSI notion of GSH is a way to provide a reference to a particular resource. Note that a GSH is a string (a URI) that can be written out and used later, a GSH can be stored by another service (like a Service Group) and a GSH is something that can be explicitly passed to other participants. (It's not clear that a Grid-SOA context has these properties). The OGSI notion of service data is a common paradigm for one way to access the state of a service and, thus, the state of the resource encapsulated by that service. Similarly, the lifetime of an OGSI service is related to the lifetime of its resource (in an application-specific manner). Many resources have lifetimes that are not controlled by the client and, in these cases, the OGSI lifetime operations are no-ops (or throw an exception). But in other cases, the resource is something more transient like a job or notification channel. In these cases, the OGSI lifetime operations apply to the resource (as well as the service that encapsulates it). A service may use the OGSI destroy() operation as one way to cancel a job or release a notification channel. Also the notification channel may use OGSI "keep-alives" to allow it to release itself if its sink crashes. In conclusion, I think we need to carefully identify resource state verses interaction (or client) state. OGSI is about resource state and says virtually nothing about interaction state. I think  would be more compelling if it made this distinction and compared the two architectures "apples-to-apples". Pete P.S. This email contains my opinions, without consultation with the other OGSI authors.  "A Grid Application Framework based on Web Services Specifications and Practices". http://www.neresc.ac.uk/projects/gaf/  Instead of "resource", you might substitute "entity" or "thingy". Instead of "encapsulates", one might also use "wraps" or "is a proxy for". </div>
Return-Path: <email@example.com> Received: from smtpsrv2.mitre.org ([188.8.131.52]) by mailsrv1a.mitre.org (Netscape Messaging Server 4.15) with ESMTP id HK36HN00.QLM for <firstname.lastname@example.org>; Sat, 23 Aug 2003 15:08:11 -0400 Received: from avsrv2.mitre.org (avsrv2.mitre.org [184.108.40.206]) by smtpsrv2.mitre.org (8.12.9/8.12.8) with ESMTP id h7NJ7Aex019946; Sat, 23 Aug 2003 15:07:10 -0400 (EDT) Received: from mcs.anl.gov (cliff.mcs.anl.gov [220.127.116.11]) by smtpproxy2.mitre.org (8.12.9/8.12.8) with ESMTP id h7NJ77Q6004207; Sat, 23 Aug 2003 15:07:07 -0400 (EDT) Received: (from listserv@localhost) by mcs.anl.gov (8.11.6/8.9.3) id h7NIqxc264654 for grdfm-ogsi-wg-outgoing; Sat, 23 Aug 2003 13:52:59 -0500 Received: from cheviot1.ncl.ac.uk (cheviot1.ncl.ac.uk [18.104.22.168]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h7NIqrB285162 for <email@example.com>; Sat, 23 Aug 2003 13:52:53 -0500 Received: from bond.campus.ncl.ac.uk (bond.ncl.ac.uk [22.214.171.124]) by cheviot1.ncl.ac.uk (8.10.1/8.10.1) with ESMTP id h7NIpOS31558; Sat, 23 Aug 2003 19:51:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: [ogsi-wg] RE: Grid-SOA and service state Date: Sat, 23 Aug 2003 19:51:24 +0100 Message-ID: <BC28A9E979C56C44BCBC2DED313A447001EC3F1F@bond.ncl.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Grid-SOA and service state Thread-Index: AcNo218ZYnf4X0RDRa+vggcAFrNCPQAyzGrw From: "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk> To: "Peter Vanderbilt" <firstname.lastname@example.org>, <email@example.com> X-Newcastle-MailScanner-Information: Please contact Postmaster@newcastle.ac.uk for more information X-Newcastle-MailScanner: Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mcs.anl.gov id h7NIqsB231508 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.21 X-Spam-Level: Sender: firstname.lastname@example.org Precedence: bulk Peter, Thank you very much for your comments. You made some interesting observations. We did aim to distinguish (and support) the two types of state that you point out in your message (interaction state and resource state). However, we weren't as clear as you were in separating these out. In the next version of the document, we'll try to do this, and will adopt your terminology. Here are some points: 1. We have indeed thought about the use of Grid Service Instances as ways to expose resources outside of the administrative boundaries of an organisation, and about what "state" means in such situations. However, we believe that it is not within the SOA concepts to use an individual service as the means to expose a specific resource. A service represents the logical manifestation of a collection of resources (like data, programs/business logic, devices, or humans) that reside behind the boundaries of an organisation. Using a single service to give access to a single resource is not, we feel, the right level of abstraction. Building Grid applications using a lot of such small services as building blocks may carry the danger of lack of scalability since "chatty" interactions would be encouraged, complicated interrelationships may be introduced between services, and there may be loss of encapsulation since specific resources would be identified and exposed to the network. We believe that Grid applications should be built using more coarse-grained services than Grid Service Instances encourage. (Section 2.2 in ) So, we agree on the importance of allowing access to such resources, but feel that one service per resource is not the right level of abstraction. 2. You give an excellent summary of the use of GSIs for resource state. We propose a very conventional alternative to GSIs for this: it's probably what most WS designers would do by default. In the most common case, a service would provide access to a set of resources. Messages exchanged between services and consumers carry the local resource id (i.e., the resource id is a parameter to a WSDL operation). In either case, this seems to meet your criteria that the identifier can be stored or passed-around. Another approach would be to establish a contextualised interaction with the coarse-grained service exposing the set of resources, with each interaction representing the dialogue with a resource. This would offer similar semantics to Grid Service Instances, while staying within the concepts of SOA. Access to resource state is therefore possible whichever of the two options the designer of a service chooses. When a resource ID is used, access to the resource's state (if the Web Service designer wishes to expose it) is possible with the provision of the resource ID. When a contextualised interaction is used, then messages sent/received may be implicitly associated with a resource, hence providing the means to access a resource's specific state. Our dataref example in Section 5.2.2 in  presents such a usage pattern. Access to the state of a resource could be made possible through SDEs, WSDL attributes (if they are adopted by the WSDL working group), or "simple" WSDL operations. We argue in Section 3.3 in , that unless the Web Services community agrees on a common way to describe the access mechanisms of such state, we should stick with WSDL operations. All things considered, "access to state" is nothing more than messages being exchanged between consumers and services. Finally, the service could choose to offer lifetime management operations on the resources that it encapsulates if it wishes (e.g. through a destroy(id) operation). Or, even better, a service could manage the lifetime itself based on the duration of the contextualised interaction (Section 3.4 in ). So, we feel that the support for resource state could be captured in a more conventional way, without the use of dynamically created GSIs. We understand that all the above are possible with Grid Service Instances but we hope to demonstrate that we can achieve the same without the need for a Grid-specific infrastructure but, rather, using only Web Services practises and specifications. At the same time, we would like to make sure that Grid applications are not built around fine-grained services, which are encouraged by GSIs. If you consider a dataset as a resource, an example of the above is presented in 5.2.2 in . 3. We worry that the "one OGSI service per resource" approach that you describe is not scalable to Grids with very large numbers of resources. For example, if the resources we wanted to access were files in a filestore, and there were millions of them, is it feasible to create a GSI for each one? If not, and instead one GSI is used to represent the filestore (with filenames being passed as parameters to operations), then it would appear to be very similar (identical?) to the first of the approaches described in 2 above. Another example might be a huge N x M grid (in the old-fashioned sense!) of sensors. 4. Just as an observation, although you say that "OGSI is about resource state and says virtually nothing about interaction state", in one of the main OGSI services, with whose design we are familiar (the OGSA-DAI DB service), dynamically created GSIs are used to allow us to represent the interaction state of database sessions. This is one of the reasons that we felt it was important to show that contextualisation could be used as an alternative solution for this. (Section 3.1 in ) Therefore, we believe that by using: a) contextualisation for interaction state (e.g. WS-context), and b) the conventional or contextualisation approach for resource state described in 2 above, it is possible to use conventional WS specifications and practises to meet these two requirements, so avoiding the need for a Grid-specific infrastructure. Thank you again for the constructive comments. We will make sure that our document is updated so it deals with the points you raised more clearly. Regards Savas & Paul.  "A Grid Application Framework based on Web Services Specifications and Practises" - http://www.neresc.ac.uk/projects/gaf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]