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

["Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>]

Dear Peter,

Thank you for another thoughtful & constructive message. Apologies for
the late response.

[snip]

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

We agree with Karl's comments on the OGSI-WG e-mail list regarding the
above point. We think that whether a Grid Service is associated with a
process/thread/object is an implementation detail which is independent
of the discussion on the architectural concepts. Our concern is that the
_conceptual_ association between a resource and a service may cause
scalability problems. This could encourage Grid application architects
to design systems that result in fine grained interactions between
entities (Grid Service Instances) and may suffer from having a great
number of exposed interrelationships, as can be the case with closed,
distributed OO platforms, such as those based on J2EE and CORBA. This
is, we believe, one of the main reasons for the move from distributed
OO-based architectures to service-oriented architectures, where
resources and their interrelationships are kept internal to a service,
behind a coarser-grained "organisation-level" service interface. 

As an aside: our reading of the "Physiology of the Grid" paper is that a
service instance encapsulates and exposes a resource. We can find no
such requirement or suggestion in the OGSI specification, but we believe
that Grid application designers are being encouraged to expose
resources, no matter how small, through a one-to-one association with
service instances. Examples include the "Data Virtualisation" [1] and
WS-Agreement [2] proposals.

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

We worry that if the emphasis is placed on defining interfaces for
exposed, small, conceptual entities then we are going to end up with
Grid applications that are fragile since interdependencies between
internal-to-organisation resources are formed that cross the
organisations' boundaries. We were therefore trying to design an
architecture that encourages more emphasis to be placed on document
structure and information exchange, rather than interfaces.

We do appreciate the importance of resources in the Grid and the need to
identify them. The WS-GAF (as we have now named the proposal) approach
attempts to decouple the association of resources with service
instances. In fact, as a result of your valuable feedback and the focus
of this discussion, we are considering extending the DataRef idea to
something called WS-Resource which would be very close to the GSH+GSR
idea for naming and reaching resources but, we hope, fits better with
the overall WS-GAF architecture. We proposed to disassociate lifetime
related information from a service instance and introduce it closer to
the appropriate entities in the WS-GAF architecture (i.e., timeout for
contextualised interactions, lifetime information for endpoint
availability, and lifetime information for resource availability).

Of course, as with every statement in science, investigation will have
to be carried out to test these views:-)
 
[snip]
> 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.

We don't see a great deal of difference between the two approaches here,
apart from the Resource Id being passed as a parameter to the service's
operations (as you mention, contextualisation can be used to avoid it,
but that isn't mandatory).  In the OGSI case, the client still has to
deal separately with both the GSR - to call operations on the service -
and the GSH, which gives it a "timeless" way of finding a service
instance that it can use (if one exists), and so will be needed if the
GSR currently providing access to the resource stops working for some
reason.

We believe that the programming model and tools available to developers
are an implementation detail that is better left outside an
architecture-oriented discussion. It is certainly the case that one
could envisage tools that abstract all the architectural concepts and
provide a similar view to developers for both OGSI and WS-GAF.

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

We are actively looking at this area as a way to form a bridge between
the two approaches, and so if you have any specific ideas we'd be very
interested.

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

Please allow us to take this opportunity to clarify one aspect of our
position. You mentioned a characteristic of Web Services, statelessness,
to which we extensively refer in our document. After the initial
feedback we have received to date, it has been made apparent to us that
our position has been slightly misunderstood by some. In Section 2.1, we
say that...

"Here, stateless means that each time a consumer interacts with a Web
Service, an action is performed. After the results of the service
invocation have been returned, the action is finished. There is no
assumption that subsequent invocations are associated with prior ones."

So, when we refer to "stateless Web Services," we refer to the lack of
their ability to correlate messages without some additional help. The
Grid Service Instance idea has been used by the community as a way to
implement stateful interactions. We propose contextualised interactions
instead. By "stateless Web Services" we do not mean that services are
not allowed to have internal state; no useful application would be
implemented if that was the case. Nor we suggest that each message
should carry all the application-specific state.

In future we'll use the clearer interaction state/service state
terminology from your previous message.

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

Yes, they are both designed to meet the same requirements, and deal with
the same concepts (resources, services, lifetimes...) - it is the
mapping onto the underlying WS technology that differs. As described
above, we are now working on a bridge between the two different
approaches.

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

We attempted to address this in Section 3.3 (p11). Firstly, we are
concerned that the introduction of SDEs is more suitable for an OO based
architecture where it makes sense to expose the public state of an
object through its interface. There is the concern that this is the
wrong level of abstraction for an SOA approach in which it is the
"organisation," rather than individual resources within it, that is made
available through message exchanges. However, if a service designer
really does feel that they are required, then it would be best if they
could be adopted by WSDL and WSA, rather than in an OGSI-specific way.
Attempts are being made to do this, but the process of moving SDEs into
WSDL, through the WSDL working group, has shown that only a fraction of
the SDE ideas made it into the latest proposal [3] (which is yet to be
discussed). However, if there is still a need, then there is no reason
why a "WS-SDE" specification could not be produced so that those
services that benefit from it could adopt it. We would however strongly
suggest that this should be optional. This would mean that those
services that didn't support such a specification would be treated as
not offering any SDEs. Unbundling SDEs from OGSI would also have the
advantage that any WS that wished to support it could do so without
having to support the other aspects of OGSI.

One further point...on this topic you argue that "It also allows the
human programmer to better know what the Grid Service is about". We
would agree that SDEs are suitable for human consumption - one may point
a grid service browser to a grid service instance and get a collection
of "dynamic SDEs". However, Web Services are all about
machine-to-machine communication, and it is not yet clear to us how
useful this facility is when there is no human intervention in the
communications between services.

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

When we addressed lifetimes in Section 3.5 (p14), we described how both
contexts and the endpoints in datarefs had lifetimes. The latter is
equivalent to endpoint lifetimes in OGSI. The former is already included
in the WS-Context spec, and gives a useful, extra level of orthogonality
to lifetimes (for example, after a context expires, a service endpoint
may continue to offer access to a resource, but not in that particular
context). As suggested earlier and as a result of these exchanges with
you, we are considering introducing WS-Resource in the next version of
our document, as an extension of datarefs, so that endpoint lifetimes
would be available for every resource.

However, the specific issue you raise concerns resource lifetimes,
rather than endpoint lifetimes, which we didn't discuss. OGSI does not
explicitly deal with resource lifetimes, only service instance
lifetimes. And, nowhere in the OGSI specification is it suggested that
the lifetime of a service instance should be associated with the
lifetime of a resource. For example, if a resource was to be
encapsulated by two different services instances (an example would be
where the resource was some data, and we wanted to provide a full query
interface through one service instance, and a simple "get" interface
through another) then each would have a different GSH, and its own
(potentially different) associated lifetime. However, it is certainly
the case that if a designer chooses to represent a single resource by a
single service instance, as suggested in the Physiology of the Grid
paper, then the service instance lifetime could be taken to represent
the resource lifetime. This could also be accomplished in WS-GAF by
adding lifetime related information to the WS-Resource structure, and
given your comments we are seriously considering doing this for the next
version of the document.

To summarise, in WS-GAF we propose that there are separate lifetimes for
contexts, WS-Resource structures, and endpoints.

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

We agree that this is orthogonal to the OGSI specification, as we
already suggest in the WS-GAF document (section 3.4.1). However, we
covered it as we believe that some in the Grid community have the
impression that through the concept of dynamically creating service
instances it is possible to easily and arbitrary deploy computational
services on the Grid and just receive a locator. So while it is not
within OGSI's aims to deal with such functionality, we wanted to
identify the related issues and our concerns and provide a suggestion on
how dynamic service deployment could be achieved in a Web Services
environment.

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

>From your arguments, we can see the attraction of a compulsory layer,
but it does raise issues. For example in many of our projects we don't
want to build all our services from scratch, but instead want to use
suitable services and specifications produced by others, who may be
outside of the Grid community. For example, many e-science applications
(e.g. myGrid) exploit existing Web services that are non-OGSI (e.g.
bioinformatics services), and not in our control (e.g. they may be owned
by the EBI, or a Japanese University). Therefore, we cannot assume that
all the services that we use to build our applications will be
OGSI-compliant - the ability to exchange messages is the only thing we
can assume. Another point is that the mechanisms OGSI provides may not
be useful for some of the services that we wish to develop. An example
might be a simple computational service that takes in a set of
parameters and returns a result. So, it seems over-prescriptive to force
the designer to support OGSI in these cases, particularly as there is a
development cost in doing so.

Consequently, we'd rather leave it up to the service designer to choose
those specifications that are appropriate for the service they are
writing. This will be the case for all the other OGSA specs that are
envisaged, and so we feel that it would be better to factorise OGSI into
a set of specifications that could be selected by designers as
appropriate.

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

We agree entirely. By submitting our document to the GGF working groups,
we were hoping that we could start a discussion that would lead us
towards exactly that goal: a future for OGSI and OGSA that ensured the
troublesome coexistence of Grid applications in a Web Services world of
emerging technologies and specifications. When OGSI was designed,
convergence was hard to achieve as there was little experience of
building Web Services, and few specifications were available (as we
wrote in the conclusions of our document). Now that the WS world has
moved on, we think that it is worthwhile considering how to achieve a
convergence, hence the proposal in the document.

Thanks again for your interesting comments,

Regards,

Savas & Paul.


[1] http://www-unix.gridforum.org/mail_archive/data-wg/pdf00009.pdf
[2]
https://forge.gridforum.org/projects/graap-wg/document/draft-ggf-graap-a
greement-00.pdf/en/1/draft-ggf-graap-agreement-00.pdf
[3]
http://lists.w3.org/Archives/Public/public-ws-desc-state/2003Sep/0000.ht
ml