[ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
Savas.Parastatidis at newcastle.ac.uk
Thu Mar 3 17:39:50 CST 2005
I guess I am considered as being part of the "other side" :-)) so please
allow me to put forward some suggestions on what I personally would have
liked to see as an outcome from OGSA.
First, please allow me to say something about my claim that the OGSA WG
mandates WSRF, a claim which you have questioned. I may have
misunderstood the group's intentions, in which case I apologise, but
discussions with various people and minutes from meetings directed me
and many others towards making that conclusion (this was raised by
several people at the UK-OGSA meeting). Also, the current draft of the
OGSA Basic Profile, to which I assume all high-level services will have
to adhere, is described in terms of WSRF.
The argument on whether EPRs and WS-Context are equivalent to the way
state is accessed was discussed in . However, this is a technical
argument and it has been around for some time, as Andrew Herbert pointed
out in his two messages. There is no point in continuing it here. While
I recognise that I am also responsible for fuelling this argument for
the last couple of years, it has always been the case that the Newcastle
team has been proposing an approach to designing the OGSA high-level
services that focused on the use of stable WS standards for production
Grid environments. I will attempt to summarise this position below.
Please note that these ideas were first presented at GGF9 during the
presentation of WS-GAF, and then summarised in .
We acknowledge that there is always going to be different approaches to
building distributed systems. This is especially true at the current
time when Web Services are still a relatively young technology that has
not yet stabilised. Therefore, we advocate a 'safe' approach to
designing and building the high-level services that are needed for
realising the vision (to which you have been one of the main
contributors) of interoperable Grid computing. This 'safe' approach
suggests that only stable, widely accepted and implemented
specifications are used for the OGSA services, even if that means that
what is felt to be the best possible approach is not used. Stability,
interoperability, wide-acceptance, and the availability of high quality
tooling from multiple vendors is given precedence over having the ideal
design (according to parts of the community :-) and new infrastructure.
At this point I would like to point out that many UK e-Science (e.g.
myGrid, Geodise, and many more) and International (e.g. SkyServer)
projects successfully used existing tooling and simple WS specifications
(SOAP, WSDL) as their underlying infrastructure. Perhaps with the
addition of WS-Security, SAML, XACML, and even WS-Addressing (given that
the entire industry is behind it even though it hasn't be finalised
yet), we have an infrastructure that can be used in the design of
high-level services. All these standards (specification in case of
WS-Addressing) are supported by everyone and commercial, high-quality
tooling already exists. I am not proposing a definite set of specs (I
may have forgotten some or some may have to be removed). The OGSA WG
will have to decide the common set of specs so that everyone is on board
(even Microsoft). Also, I am not going to restart the 'state' argument
here but I will point out that even with this simple set of specs large
companies like Amazon and Google offer access to their data and
functionality without requiring additional infrastructure (sorry... had
to mention the 'state' word :-)))
When in few years time Microsoft, IBM, Oracle, Sun, Axis and others have
produced runtimes and tooling that support a new common set of
infrastructure-specific standards, then we can start designing OGSA v2.0
with all the bells and whistles that the new infrastructure will offer.
For example, when WSRF or WS-Transfer or WS-MyNewFavouriteSpecification
becomes widely adopted and the entire industry has agreed because of
market forces, then we can consider it for our next generation Grid
computing platform. Until then, let's do things the simple way, even if
that means that some common behaviour, which part of the community has
identified, is not implemented by the underlying infrastructure. At
least we are going to interoperate and everyone is going to be onboard.
I think a good question we can ask in order to know when it is time to
move to new infrastructure (or richer infrastructure if you want) is
whether WebSphere, .NET/WSE/Indigo, Sun WSDP, Axis, etc. all
implement/support a common set of standards. Please note that I say
'standards' and not 'specifications' (even if that means that we
currently have to remove WS-Addressing from the list I gave above,
although I personally happen to believe in WS-Addressing).
I don't think that we should be in a situation where the architects of a
high-level Grid computing platform define the underlying infrastructure
without the common agreement of all the industry players who are
producing the tooling and runtimes. Interoperability and wide adoption
will be adversely affected.
The issue of stability is very important. The recent example of the
OASIS WSDM WG where the attempt to standardise the specification has
been attacked due to the dependencies in other, unstable specifications
(e.g. WSRF and WS-Addressing) is an indication on where things lead when
we try to define all the layers of our platform at the same time.
As Andrew Herbert suggested, and I think everyone agrees, there is
nothing that can't be done using any of the technologies/approaches
available to us. My suggestion is to use the technologies/approaches
that are stable now for building the stable Grid computing platform that
our users want, with wide-adoption in mind. At the same time, let's
investigate new approaches for the infrastructure and only when we reach
a level of maturity, stability, and wide adoption consider moving our
Grid platform to it. The large set of current Grid systems built on
existing, stable, and interoperable WS platforms demonstrate that we can
indeed find solutions for the problems of Grid computing, even if those
solutions do not leverage an underlying infrastructure of observed
common behaviours, like what WSRF provides.
As always, I am interested in your thoughtful perspective.
 " Stateful Interactions in Web Services - A comparison of WS-Context
and WS-Resource Framework",
 "Using Web Services to Build Grid Applications - The "No Risk" WSGAF
[Previous messages snipped]
More information about the ogsa-wg