[ogsi-wg] Grid-SOA and service state

[Peter Vanderbilt <pv@nas.nasa.gov>]

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