wsdm message

Subject: Re: [wsdm] WSDM will discuss the 'Grid Application Framework' paperSept 4th.

From: John DeCarlo <jdecarlo@mitre.org>
To: Heather Kreger <kreger@us.ibm.com>
Date: Tue, 02 Sep 2003 09:52:15 -0400

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:      jdecarlo@mitre.org
voice:      703-883-7116
fax:        703-883-3383
DISA cube:  703-882-0593

Message-ID: <3F46615A.6000004@nas.nasa.gov>
Date: Fri, 22 Aug 2003 11:30:50 -0700
From: Peter Vanderbilt <pv@nas.nasa.gov>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
MIME-Version: 1.0
To: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>,
   ogsi-wg@gridforum.org
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
Sender: owner-ogsi-wg@gridforum.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 [1]), 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[2].  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 [1]).

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 [1] 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.

[1] "A Grid Application Framework based on Web Services Specifications
and Practices".  http://www.neresc.ac.uk/projects/gaf/

[2] Instead of "resource", you might substitute "entity" or "thingy".
Instead of "encapsulates", one might also use "wraps" or "is a proxy
for".

</div>

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>
Thread-Topic: Grid-SOA and service state
Thread-Index: AcNo218ZYnf4X0RDRa+vggcAFrNCPQAyzGrw
From: "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>
To: "Peter Vanderbilt" <pv@nas.nasa.gov>, <ogsi-wg@gridforum.org>
Content-Transfer-Encoding: 8bit
Sender: owner-ogsi-wg@gridforum.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 [1])

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 [1] 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 [1], 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 [1]).

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 [1].

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 [1])

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.

[1] "A Grid Application Framework based on Web Services Specifications
and Practises" - http://www.neresc.ac.uk/projects/gaf