[ogsi-wg] Re: Grid-SOA and service state

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

[ in response to Savas's email of 8/23. ]

Savas & Paul,

Thank you very much for your response to my comments.  They were quite
helpful.  Sorry I haven't gotten back to you sooner.

Here are some responses and additional points.

I believe there may be many cases where:

    Grid Service Instance (GSI) != Web Service Instance (WSI)

In fact there can be thousands of GSIs per WSI (although there may
also be cases where they are one-to-one).  I may be abusing
terminology, but the essential thing is that GSIs need not be heavy
weight things.  The architecture does not require per-service state
and certainly no per-service process.  For instance ...

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

Yes, we believe it should be possible to have millions of GSIs.

One way to do this would be to have one web service for the entire
filestore and to structure the GSH to have a part that referred to the
web service and a part that contained a file id.  The file id would be
the path name (or part of it) or a encoding of a set of attributes
that identify the file.  The GSH would resolve to a GSR that contains
a web service address plus the file id; for instance, the file id
might be placed in the query part of the URL.  When the web service is
called, that file id is available to it and the web service performs
its actions based on the named file.

Note that these GSHs can be created when needed -- one need not
pre-create a GSH for each file.  If two GSHs are created at different
times for the same file, they will have the same file id and, thus,
will be equivalent.

Also note that there is no per-GSI state maintained by the web service
-- everything that's needed is carried in the GSH/GSR/URL or is in the
filestore.  Clearly, there is no per-GSI process involved.

(Note I don't know how it's done in GT3 so I may have some details
wrong but the design of OGSI specifically allows for light-weight
implementations).

This is similar to your alternative of a course-grained web service
with resource ids.  But that scheme requires that the client know, and
deal with, two things: the resource id and the web service address.
Supplying the resource id implicitly via contextualisation is scary to
me.  The GSH scheme packages the two together.  (I do recognize that
there are many cases where separating these out is useful and I hope
we can come up with common mechanisms for assigning names or URIs to
resource and for going between these names/URIs and GSHs -- but this
is really a different discussion.)

Also, it is certainly possible to have coarse-grained Grid Services
with resource ids passed as parameters, so one can certainly follow
that model when appropriate.

Anyway, I think we agree that the Grid has resources that have state,
identity and potentially limited lifetime.  I think we agree that web
services are stateless, anonymous and persistent.

I claim that OGSI is the layer over web services that provides the
needed functionality.  Perhaps the problem is the word "Service" in
"Grid Service" as it suggests something stateless, anonymous and
persistent.  Your proposal is another way to achieve the same goal
and, I suspect, that the two are not as different as seems at first
glance.

Another point: I don't think your proposal addresses the "schema"
aspects as does OGSI.  In particular, the service data stuff comes
down to a few simple, generic operations and a bunch of metadata to
describe what state the resource exposes (through those operations).
The operations are just regular web service operations -- no WSDL
extensions are needed to handle them.  Where OGSI extends WSDL is in
the incorporation of metadata which allows tooling to create
specializations of those generic operations.  It also allows the human
programmer to better know what the Grid Service is about.  I don't see
equivalent functionality in your proposal.

The service data mechanism also provides an introspection facility,
which is useful for amplifying one's knowledge about a GSI.  Coupled
with the generic service data operations, introspection allows a
completely generic tool to display the (SD-provided) state of the
resource.

How does your proposal deal with resources whose lifetimes are limited
or controlled?  Instead of having every developer invent their own
mechanisms, shouldn't there be common models and operations?

BTW, your document talks about "deploying binary code across
organizations".  This is completely orthogonal to OGSI, so I'm not
sure why you bring it up.

Also, your document talks about OGSI as a "compulsory" layer and
implies that that's a bad thing.  Think of OGSI over Web Services like
TCP over IP.  Is TCP compulsory for connection-oriented communication?
Is that a bad thing?  I believe protocols and other kinds of common
agreements are good.

On:

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

Point well taken.  I'm not knowledgeable enough about DAIS to comment
further.

> 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 practices
> to meet these two requirements, so avoiding the need for a
> Grid-specific infrastructure.

I think we need some kind of infrastructure, although it should not
be Grid-specific if possible.  Grid resources have state and it is
useful to have common ways to access that state.  Grid resources have
identity and it is useful to have common ways to deal with different
instances of the same interface.  Some Grid Services are transient and
it is good to have common ways to cause them to come into existence
and common ways to control their destruction.  It is also useful to
have common ways to introspect a Grid Service to amplify one's
understanding of the service.

By having common ways to deal with these things, it lessens the
cognitive load one needs to use Grid Services and enables the creation
of generic tools and methods.

BUT: I agree with your fundamental design philosophy of using as much
standard WS stuff as possible.  The Grid Service layer be as thin as
possible (but no thinner).  And to the extent possible, it should not
be grid-specific.

As WS-* standards become adopted (and have the appropriate licensing
and IP terms), it would be good to replace the corresponding parts of
OGSI.  Furthermore, I hope that some of the Grid Service interfaces
migrate into standard web services.  In the long run, I hope web and
grid services will converge to the point that "Grid Services" goes
away.

You mention many WS-* technologies of which I (personally) know
nothing.  I hope we can use your knowledge to evolve OGSI over time to
a better standard.

Pete