As an aside, ironists among you may find amusement in that the reasons given in OGSA WG discussions for adopting WSRF in the OGSA Basic Profile are precisely that WSRF is stable, widely adopted and requires no special tooling or runtime support. Dave. -----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Savas Parastatidis Sent: 03 March 2005 23:40 To: Andrew Herbert; Ian Foster; Tony Hey; Frank Siebenlist Cc: Dennis Gannon; Samuel Meder; ogsa-wg; paul.watson@ncl.ac.uk; dave.pearson@oracle.com; 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' Dear Ian, 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 [1]. 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 [2]. 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. Best regards, -- Savas Parastatidis http://savas.parastatidis.name [1] " Stateful Interactions in Web Services - A comparison of WS-Context and WS-Resource Framework", http://www.sys-con.com/story/?storyid=44675&DE=1 [2] "Using Web Services to Build Grid Applications - The "No Risk" WSGAF Profile", http://www.neresc.ac.uk/ws-gaf/WSGAF-NoRiskProfile.pdf [Previous messages snipped]