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

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

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