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@mcs.anl.gov]
Sent: 03 March 2005 07:04
To: Tony Hey; Frank Siebenlist
Cc: Dennis Gannon; Samuel Meder; ogsa-wg; paul.watson@ncl.ac.uk; dave.pearson@oracle.com; savas.parastatidis@ncl.ac.uk; Jim Gray; humphrey@cs.virginia.edu; grimshaw@virginia.edu; Andrew Herbert; gcf@indiana.edu; mark.linesch@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