[ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'

[Hiro Kishimoto]

Another Andy's email.
----
Hiro Kishimoto

Subject: RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging    Times
for GGF & Standards'
Date: Thu, 3 Mar 2005 18:16:35 -0000
From: "Andrew Herbert" <aherbert at microsoft.com>

Ian

My point in resurrecting the CORBA history was that in that debate
neither "side" could understand what the other side needed that wasn't
already provided for.

I defer to those building systems who don't support WSRF to comment
technically on what it is that they feel is over-constraining for them
about WSRF in detail. They tell me they can build practical and
effective systems using other web services standards and that they
find systems based on WSRF are more complicated to program because
there is more mechanism and parameterization to be dealt with. To my
ears this would seem to be more a discussion about factoring
functionality and keeping mandatory interfaces simple, than it is
about specific mechanisms. And I guess people who are comfortable
getting systems to work without WSRF find it hard to get motivated to
enter technical discussion about something they don't see the need for
in their systems.

I realize this doesn't help you solve your problem.

Andrew

________________________________

From: Ian Foster [mailto:foster at mcs.anl.gov] 
Sent: 03 March 2005 08:52
To: Andrew Herbert; Tony Hey; Frank Siebenlist
Cc: Dennis Gannon; Samuel Meder; ogsa-wg; paul.watson at ncl.ac.uk;
dave.pearson at oracle.com; savas.parastatidis at ncl.ac.uk; Jim Gray;
humphrey at cs.virginia.edu; grimshaw at virginia.edu; gcf at indiana.edu;
mark.linesch at hp.com
Subject: RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for
GGF & Standards'

 

Andy:

One thing that would really help, I think, is for someone on "the
other side" to explain what it is that they want to do that GGF/OGSA
WG is preventing them from doing. I understand it must be something
important, but think that there is genuine lack of understanding
within GGF/OGSA WG as to what it is. A set of application scenarios
would really help.

A second thing that would be helpful would be a crisp characterization
of what "the other side" wants to see GGF/OGSA WG do instead. Should
we allow for the use of WS-Transfer as an alternative way of
interacting with stateful resources? Or that we should allow for EPR +
context-id as an alternative way of interacting with state? Or both?
Or something else? Again, this hasn't been made clear: the only
explicit communication we've received is that "we shouldn't use WSRF,"
which isn't a very satisfying answer.

Clarity on these two issues would really help I think.

A couple of other minor points:

* I don't see the fact that people build Grid applications and systems
in different ways as a reason not to work towards
interoperability. Yes, people have built nice Grid-like systems with
custom protocols, with JINI, with Web services, with CORBA, with DCOM,
etc. But these systems don't interoperate, and interoperability is
important in some situations.

* I said management applications were "a primary focus" of OGSA, not
"THE primary focus."

Regards -- Ian.

At 04:25 PM 3/3/2005 +0000, Andrew Herbert wrote:




Ian, Tony

 

This discussion reminds me very much of the early history of CORBA,
when there was a create debate between those who believed dynamic
interface types were central to object request broking and those who
thought they were the spawn of the devil.  Both approaches were able
to emulate the other and so any argument about which was the more
fundamental was sterile.  There was certainly an element of bias
towards different styles of application, and this was what split the
OMG community since each camp had an legacy to carry forward and an
investment in their view of the future.  The OMG architecture was
therefore positioned at a level where both approaches could be
accommodated and as CORBA and CORBA Services were defined a case by
case view was taken of the need for a static or dynamic interface, or
both, or some unification of the two. It led to optional elements and
even some duplication of function in the early OMG specifications, but
as the standards process unfolded and users gained experience with the
technology it became easier to make rational choices and if necessary
go back and fix the specifications. Of course vendors initially
implemented just the options they preferred but over time they
converged on common components and interfaces.  And of course the
users also demanded interoperability between CORBA and DCOM and got
it, even though for many CORBA vendors DCOM was the enemy.

 

The academic question of the superiority of one style of object
request broking over another was never actually resolved a workable
hybrid evolved which meet the needs of the users and the OMG moved
on. Interestingly given your comment about the position of names in
messages, with hindsight many of the CORBA debates were ultimately a
fight about where names stood relative to dot, comma, braand ketin
object invocation semantics and fifteen years later I find it hard to
remember the passions that made these things seem so important at the
time.

 

Ian positions the primary purposeof OGSA as being certain classes of
management application.  The problem Tony and others appear to be
grappling with is the desire to have OGSA as the architecture for
broader notions of Grid Computingand e-Scienceand this is where the
shoe starts to pinch.  Ian asks how to make progress.  It seems to me
that GGF has two choices make the scope of OGSA narrow so those
interested in certain classes of management applicationcan develop an
architecture for this unimpeded, or make the scope of OGSA broader and
admit to the possibility of other classes of application of interest
to the GGF community.

 

I observe colleagues I respect building systems that clearly are doing
Grid Computingof the kind envisioned in Ian and Karls book that coined
the concept, and these people seem to manage to build and operate
their systems without invoking WSRF so this makes me wary of any
architecture for Grid computingand/or e-Sciencewhich mandates WSRF in
its entirety in all cases.

 

Andrew

________________________________

From: Ian Foster [mailto:foster at mcs.anl.gov] 
Sent: 03 March 2005 07:04
To: Tony Hey; Frank Siebenlist
Cc: Dennis Gannon; Samuel Meder; ogsa-wg; paul.watson at ncl.ac.uk;
dave.pearson at oracle.com; savas.parastatidis at ncl.ac.uk; Jim Gray;
humphrey at cs.virginia.edu; grimshaw at virginia.edu; Andrew Herbert;
gcf at indiana.edu; mark.linesch at hp.com
Subject: RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for
GGF & Standards'

 

Tony:

I think your message captures nicely (although perhaps inadvertently!)
the way in which people are talking past each other in this
discussion.

I would never say that the "messages to single resources approach" is
the "the foundation for all operations on all services." I understand
that some people in this strange religious debate that we've fallen
into have characterized things that way, but that's far from the
truth.

>From my perspective, WSRF was motivated by our experiences building
"service oriented infrastructure", and seeing that the same patterns
were occuring repeatedly in different places as we built systems to
manage Grid systems. The codification of those patterns in standard
(and WS-I+-compliant, I like to emphasize) WSDL has allowed us to
simplify many aspects of both service implementation and client
tools. Others report the same positive experiences. The introduction
of WS-Transfer, which provides similar functionality and seems to be
intended for similar purposes, suggests that there is broad
recognition of the importance of these patterns. However, the fact
that these patterns are useful in building certain classes of
management applications (a primary focus of OGSA, by the way)
certainly doesn't mean that they are appropriate everywhere.

I'd also like to suggest that when considering the assertion that
"sending messages to single resources makes systems fragile", it is
useful to recognize that the messages sent over the wire when using an
EPR to a WS-Resource (the WSRF approach) vs. an EPR plus a context id
(e.g., as in the eCommerce systems that are often mentioned) are close
to identical. In fact, the only difference is really just the location
of the "context id": in the EPR vs. in the body of the message! I
don't see how the choice of one placement vs. the other can render a
service "robust and scalable" vs. "fragile and
nonscalable"--especially as the service itself can be implemented in
an essentially identical manner in the two cases.

My preceding paragraph suggest that there are opportunities for common
ground, and I suspect that is the case. However, to find that common
ground we need to identify clearly just what it is we are trying to do
and then address different issues separately. I believe that there are
far too many different issues being mixed together at present for
useful progress to occur. Unfortunately, I'm not sure how to proceed
to separate out the different issues.

Ian.

At 11:37 AM 3/3/2005 +0000, Tony Hey wrote:

The point is not about how well the WS-RF and WS-Transfer stacks
compare but rather whether it is always appropriate to use the
"messages are directed at single resources" approach? Many people,
including people whose technical judgement I respect such as Tony
Storey, Ian Foster, Dave Snelling and others, apparently believe that
the answer to this question is "everywhere: it is the foundation for
all operations on all services". It is therefore not surprising that
this group do not see the need to worry about the question "is it a
good idea to build architecture around the idea of sending messages to
single resources?"

_______________________________________________________________
Ian Foster                    www.mcs.anl.gov/~foster
Math & Computer Science Div.  Dept of Computer Science
Argonne National Laboratory   The University of Chicago    
Argonne, IL 60439, U.S.A.     Chicago, IL 60637, U.S.A.
Tel: 630 252 4619             Fax: 630 252 1997
        Globus Alliance, www.globus.org <http://www.globus.org/>