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

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@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@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@ncl.ac.uk; dave.pearson@oracle.com; savas.parastatidis@ncl.ac.uk; Jim Gray; humphrey@cs.virginia.edu; grimshaw@virginia.edu; gcf@indiana.edu; mark.linesch@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@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. 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/>