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

[Ian Foster]

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

_______________________________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20050303/1e000220/attachment.htm