- ogsa-wg - lists.ogf.org

Teleconference minutes - 2 March 2005
by Andreas Savva 07 Mar '05

07 Mar '05

Minutes attached. This call was mostly a review of the basic profile. Gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050302/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 2 March 2005 ================================== * Participants Mike Behrens (R2AD, LLC) Hiro Kishimoto (Fujitsu) Allen Luniewski (IBM) Fred Maciel (Hitachi) Tom Maguire (IBM) Takuya Mori (NEC, ANL) Steven Newhouse (OMII) Andreas Savva (Fujitsu) Latha Srinivasan (HP) Jem Treadwell (HP) Jay Unger (IBM) Peter Ziu (Northrop Grumman) Minutes: Andreas Savva * No minutes available * Minor change to the GGF13 schedule to add the teleconference information * Discussion generated from Tony Hey's article - Agreed to timebox (10 minutes) this discussion so that it would not take over the entire call. - Two stack interoperability problem? - It is a problem if we end up with different message protocols - Important to describe how the two stacks interroperate (one more analogy given: driving a car either on the left or the right side of the road) - It might be possible to write code that is agnostic but must make a choice about the wire format when running it on the grid. - Migration and co-existence are important issues. They should/could be addressed incrementally in later versions of the standards as they evolve (e.g., WSRF 2.0) - The article's point is that it is not possible to decide which is the right choice at the lower level at this moment; wait and see while defining things at a higher level in an independent manner; and follow the winner later. - Also possible to choose one approach and map to the other with some overhead - The suggested approach does not really solve the problem because it does not reach a common standard - Concern further clarified that building up an infrastructure by making the wrong choice (OGSI raised as an example) might end up messing up application code that is built specifically for it. - End of timebox; followup on the list. * Basic Profile review The latest draft is on gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… Aka: draft-ggf-ogsa-basic-profile-008 [Unassigned actions belong to Tom by default.] ** Front matter - Last line of "Status": This is a recommendation document so delete "...does not define any standards..." - Abstract: - l.4: There is a WS-I citation but no reference. Clarified that WS-1.1 is implied and will be referenced. (Tom to revise) - "Guided by these principlies" what does "these" refer to: > "interroperability, interaction" (Tom to revise) - Why is there no mention of WS-Resource? - In an earlier review agreed that the Profile is only discussing the WS-Addressing embodiment. - But there is a normative reference to WS-Resource. It should be removed (Tom to revise) - Also need to refer to Profile template document (Tom to revise) ** 1 Introduction - Pending action on WS-I copyright issues: - Tom & Hiro will follow up with their companies' representatives on whether the introductory text can be re-used as is or whether it has to be rewritten. - Suggestion to add a short (historical) paragraph on OGSI. - Rejected. No need to refer to OGSI. *** 1.2 Relationships - To add the relationship to Basic Security profile as well. *** 1.3 Notational conventions - UDDI namespace is not needed. Delete. - Other namespaces that are not used for normative statments should also be deleted (xsi, soap, ...) *** 1.4 Profile identification - Discussion on Profile 'name', versioning and what profile instance definition. - Note 'name' does not include the 'version' so the example given is correct. - Since a conformance URI (2.4) will also be defined consider doing the versioning definition just on the URI (or in conjunction) to avoid the need for similar versioning explanation appearing more than once. ** 2 Profile Conformance *** 2.2 Targets The new ones (introduced by this profile) are ENDPOINTREFERENCE and RESOURCE. The rest come from the WS-I BP 1.1. *** 2.3 Scope - It is stated that "extensions...when identified in the Profile..." - So what does it mean if an extension in a referenced spec is not identified in the profile? - There seems to be a minor gap in this explanation. [It is copied from the WS-I Profile explanation.] - The intention is, however, to list all relevant extensibility points from the referenced specs in the profile. ** 3 Addressing After the F2F Tom split off most of the text here to a separate document in anticipation of a separate Naming profile. - Discussed whether to move the remaining statement to the Naming profile or not. The consensus that those dealing with ServiceName and portType could be left here but the rest should go. - Tom will make this a tracker and revisit. ** 4 Resource Property - Description requirement on getmultipleproperties / query - This is already a recorded issue. ** 5 Resource Lifetime There has been some discussion but no firm conclusion on the destroy / resource destruction issue yet. It is recorded as an issue and will be revisited. ** ServiceGroup Tom has deleted this section as agreed at the F2F. ** 6 Notification No change. ** 7 Base Faults Tom added text that requires use of the structure, as agreed. ** 8 Security Dave S is not on the call. Postponed. * Basic Profile Tracker review ** Review of tracker setup Reviewed new tracker status values and discussed other configuration issues. It seems that only a person with OGSA-WG administrator rights can close an artifact on this tracker. Considered changing this but agreed it is good form in order to make sure that changes are properly verified before a tracker is closed. Use of priorities: To capture what to work on next; so it can (and should) be updated to boost the visibility of issues that become more important. ** Artifact review Spend about half an hour going through all artifacts updating them as necessary. For details refer to the BP tracker. Agreed that issues relating to Naming will be moved to a new tracker once the Naming profile draft becomes an independent (and publicly visible) document. > Andreas will take care of the transition.

1 0

Proposed agenda for March 7th call
by Hiro Kishimoto 06 Mar '05

06 Mar '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 7th Monday from 5pm to 7pm (CST). The dial-in number for Monday; Free: +1-866-639-4741 Toll: +1-574-935-6703 PIN: 8980700 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0307 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (if available) Agenda bashing 2) GGF13 preparation (20 min) Conformation of owner/note taker/guests for each session - OGSA session plan https://forge.gridforum.org/projects/ogsa-wg/document/GGF13_session_plan/en… - GGF13 schedule http://tinyurl.com/4cz98 3) OGSA-BES BoF discussion (30 min, Andrew) BoF session description, Draft Charter, 7 questions discussion - current draft http://www.gridforum.org/Meetings/GGF13/Charters/GGF13_OGSA_Basic_Execution… ice_WG_BOF.pdf Revised draft charter etc. will be posted before the call. 4) Basic profile discussion (30 min) Revised basic profile draft https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… le/en/3 5) Wrap up (10 min) AOB Mar. 9 (10-11am CST) Data Design team Mar. 9 (5-7pm CST) Roadmap discussion, GGF13 session preparation Mar. 13-16 GGF13 in Soeul See telecon schedule until GGF: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Hiro Kishimoto

1 0

A proposal to move forward CIM-related work in the GGF
by Fred Maciel 05 Mar '05

05 Mar '05

Hi, As I was telling you recently, I and Tom Roney (CGS-WG) have been working on how to move forward CIM-related work in the GGF and, specially, in OGSA. Here it is, in the attached file. Please give a look. Next week I'll be in Japan, and quite probably I won't participate in the OGSA-WG teleconferences. (Which means I'll escape all the nitpicking that I know that some of you will do on this document, at least for a week :-). But anyway, I intend to explain the contents (and get feedback) in the Resource Management design team session and, perhaps, also in the CGS-WG session. Let's discuss it there. See you in Korea, Fred Maciel.

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Ian Foster 04 Mar '05

04 Mar '05

>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. Savas: What I meant about "mandating" (which upon reflection I suspect is what you meant too): A profile typically says simply that IF you use something, THEN this is how you must use it. It doesn't say you MUST use it. Thus, the OGSA Base Profile doesn't say anything about whether WSRF should be used or not, it just says how you should use it if you do. Where, then, is WSRF "mandated"? At present, nowhere. However, moving forward, it would seem likely that when OGSA WG considers say a management specification for inclusion in some future "management profile", it will look kindly on one that uses WSRF conventions to access remote state, rather than making up its own custom ones, because that is viewed as enhancing interoperability. It would then also want to see that WSRF is used in a way that adheres to the OGSA Base Profile. On the other hand, when considering specifications that have nothing to do with state (e.g., naming), there would be no reason for WSRF to come into the picture. The draft OGSA Naming Profile that Andrew Grimshaw is developing does not use any WSRF mechanisms. It *could*, but this hasn't been seen as particularly useful, so it doesn't. And (the point I was harping on, probably too much), there is nothing to say that you must use WSRF conventions when developing your own services. So, I guess WSRF is "mandated" in some places, and not in others. Steve Loughran wrote more eloquently on some related topics in an earlier post to ogsa-wg. Ian.

4 4

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Savas Parastatidis 04 Mar '05

04 Mar '05

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]

2 1

Teleconference minutes - 23 February 2005
by Andreas Savva 04 Mar '05

04 Mar '05

Attached. Gridforge https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050223/en/1 -- Andreas Savva OGSA Teleconference - 23 February 2005 ====================================== * Participants Dave Berry (NeSC) Ian Foster (ANL) Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Mark Morgan (UVa) Steven Newhouse (OMII) Andreas Savva (Fujitsu) Frank Siebenlist (ANL) Jem Treadwell (HP) Jay Unger (IBM) Minutes: Andreas Savva * Data (ByteIO BoF) Review of basic proposal; simple data access interface. Dave B has sent the revised charter to Stacey (and the list). Malcolm's comments are taken care. (1) WG will produce informative usecase document (2) WG will define API including WSDL (i.e., a WS interface, not java binding) Dave B will also send 7 Q&A to Stacey and Data Area ADs (Malcolm and Dave Martin) (It is probably not required at this point and in any case one purpose of the BoF is to review and draft the final answers.) - Proposed Milestones - Draft document and implementation by June - Draft experience document by GGF15 - Is there no other similar or related WS standard? WS-Enumeration was mentioned but it deals with XML streams rather than bytestreams. * WS-Naming A number of documents were sent out prior to the call. 1. A presentation for review in this call 2. A document describing the proposal 3. A draft Naming profile that was split off from Basic profile - There is one more (earlier) document that discusses motivation, use cases, etc. - GGF13 Plans - A union of these documents will be presented at GGF13 - Everything except the 'resolve' can be a profile. So one spec and one profile - The reason for the alternative document (2) is also to present to people who may not have an interest in the wider OGSA picture. The Profile is based on extending WS-Addressing EPRs with additional information. These extended EPRs can be used as normal EPRs by existing clients with no changes. This is an important requirement that is neeed to help initial adoption. Two elements are added: 1. Abstract name: A string, globally unique, only equality comparison allowed - Anything in profile should be testable; so how can global uniqueness be tested? - Probably not testable though there could be an argument that they are. No good answer at this point. - Strings are already comparable; why re-state this? - To emphasize that lexicographic ordering is not meangingful. Only equality is defined. - Why not use a URI? - No need to constrain the Abstract Name further at this point - Interesting points on whether it might have structure, and whether it can be reasoned about to some extent. - Scheme presented as 3-levels; but actually there can be many more levels than that. - Three levels capture requirements of many systems. It's not the intention to constrain it to (at most) 3 levels. This should be made clearer. 2. Resolver - Optional: it may appear and if it does its usage is optional - Singleton or list? - Currently saying that this is at-most-one - Leaving this as an issue for the WG that will define this. - If a list then there is additional complexity with whether you get the same answer from all resolvers or not, which one to use, and so on. - The resolver is a WS with an EPR and a portType with the operation 'resolve' that receives an epr and returns an (equivalent) updated one. - Could there also be a WSRF binding that casts the resolver as a WS-Resource with just the operation 'resolve' (no arguments; the resource is 'pointing' to what needs to be resolved.) - If necessary, it could be defined as a separate profile. - EPR examples slide - Case with "No resolver," "Simple," and "Resolver with resolver" - Resolver with resolver can be stateful or close to the WSRF rendering of a resolver mentioned before. - Exactly one abstract name or is it possible to include different names or aliases in the same EPR? - Is it inevitable or not? (Perhaps) - Sameness issues? - Might be better to constrain it at this level and at this point in time. - Properties on resolver, e.g., to distinguish them? - It is out of band - Extensible scheme for Names so that people can introduce names that are unique for that authority or not? (context) - Names are defined as globally unique but there is nothing stopping an organization to produce them in such a way that they can be interpreted differently within a context or domain (and those domains do not overlap) - For example, IP addresses are globally unique but many organizations use certain spaces (10.*) internally. - Issue of addressability from other places - Can generate a unique name/id, but someone else could re-use it later. Can't stop people from doing that. - No guarantee. Need to be careful when saying 'globally unique.' Might need to look at making this statement in a better or more descriptive manner. - Andrew and Mark are working to bring Tom's document (Naming profile draft) and this document together. - OGSA Naming session will probably be used as BoF for these activities. * OGSA-BES update - Not ready for a detailed review yet. Will continue on a separate teleconference to discuss logistics and come back to the main call. - Haven't completed the 7 questions yet - The draft reviewed at the F2F is not updated yet. Refinement of that document is not the focus at the moment. * Basic security profile - Frank is not available before GGF13. Probably discuss this at that time.

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Dave Berry 04 Mar '05

04 Mar '05

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(a)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(a)ncl.ac.uk; dave.pearson(a)oracle.com; Jim Gray; humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu; gcf(a)indiana.edu; mark.linesch(a)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]

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Hiro Kishimoto 03 Mar '05

03 Mar '05

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

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Hiro Kishimoto 03 Mar '05

03 Mar '05

Andy's email bounced. ---- Hiro Kishimoto Subject: RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' Date: Thu, 3 Mar 2005 16:25:09 -0000 From: "Andrew Herbert" <aherbert(a)microsoft.com> 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", "bra" and "ket" in 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 purpose" of 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 Computing" and "e-Science" and 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 application" can 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 Computing" of the kind envisioned in Ian and Karl's 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 computing" and/or "e-Science" which 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(a)ncl.ac.uk; dave.pearson(a)oracle.com; savas.parastatidis(a)ncl.ac.uk; Jim Gray; humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu; Andrew Herbert; gcf(a)indiana.edu; mark.linesch(a)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/>

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Hiro Kishimoto 03 Mar '05

03 Mar '05

Tony's email bounced. Tony: You can read whole mail threads triggered by your article at; http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/02/threads.html http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/03/threads.html There are more opinions than you've already read. ---- Hiro Kishimoto Subject: RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' Date: Thu, 3 Mar 2005 11:37:06 -0000 From: "Tony Hey" <Tony.Hey(a)epsrc.ac.uk> Dear OGSA WG members and others, I am interested by this debate (obviously) but fear that I did not get my essential point across. Let me try once more - sinc e I think this is a crucial decision point for the whole GGF and Cyberinfr astructure effort. First, to reassure Dave Snelling and others, I am NOT trying to endorse 'proprietary' proposals such as WS-Transfer from Microsoft; nor am I trying to impede the progress of WSRF etc through OASIS. IBM and others have indeed acted as I had urged and submitted their p roposals to a recognized standards body. Second, the point is not about whether one can implement WSRF in .Net technologies. I respect the work of Marty Humphrey and h is team but this also is not the point at issue. The point is not about how well the WS-RF and WS-Trans fer stacks compare but rather whether it is always appropriate to use the "messages are directed at single resources" approach? Many people, includi ng people whose technical judgement I respect such as Tony Storey, Ian Foster, Dave Snelling and others, apparently believe that the answ er to this question is "everywhere: it is the foundation for all op erations 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?" In fact, although I am clearly not an implementor, I t hink that this is not a closed issue. People whose technical judgement I a lso respect - such as Jim Gray, Pat Helland and Andy Herbert (yes, a ll from Microsoft but wait for the supporting cast) - believe that this is not a good way to build robust wide area, inter enterprise distributed sy stems. I understand why opinions from 'Microsoft' may be viewed wit h suspicion but in this case I think their views are deeply held matters of principle. Andy Herbert, for example, is from Microsoft Re search and spent a long time trying to make distributed systems lik e CORBA work. He came to the conclusion that while CORBA was just fine for local area networks it encouraged a style of programming for wide a rea networks that led to such implementations being 'brittle'. Thus I believe that they think that while something like WSRF may be fine for use within corporate computing centers behind corporate firewalls, this approach to building distributed systems will not lead to robust wide area implementations. (I hope Andy and the others cited will either support or correct my interpretation of their views.) So I think this is not a small matter of WSRF versus WS-Transfer. This view is supported by others in the distributed computing community - not only people like Paul Watson, Savas Parastatidis and Jim Webber, but also professional database people like Dave Pearson from O racle who I believe has concerns that in an inter enterprise computing context, many companies will not wish to expose details of their datab ases to open scrutiny. What changed for me recently was the realisation after months of trying to persuade Microsoft to engage with GGF/OGSA/WSRF that this issue was actually a matter of principle and that there was no prospect of Microsoft being able to join the WSRF bandwagon or of their 'morphing' their ideas to be compatible. This being the case - and it was confirmed for me by the OGSA-UK meeting I referred to - and recognizing that the non-WSRF folks might, just might, be proved correct in the long run, at least for certain types of e-Scien ce applications, then for GGF to tie its 'flagship' OGSA to this approa ch to resources by mandating the WSRF route would be to take an unnecessary high risk with our user community. Such a route would also be highly likely to effectively exclude Microsoft from GGF and hinder their pl aying any positive role in GGF, Grids and Cyberinfrastructure. In addition, speaking as someone with responsibility for t he UK e-Science applications people, I can state categorically tha t they are not interested in religious debates about how the distribu ted systems they rely on have been implemented. They just want the underlying distributed middleware to work and for GGF to concentrate on delivering timely and high level standards that will assist them in constructing their interoperable Cyberinfrastructure. They absolutely do no t want to be forced to choose between an 'IBM' camp and a 'Micro soft' camp - they just want a standard on which they can build higher le vel standards and APIs. They want to be insulated from any low-level dispu tes about how to fix the plumbing. So that's it folks. I believe it really is a crucial time for GGF to show that it is really an open standards body dedicated to delivering useful standards for users - rather than backing one bra nch of a religious debate right down at the plumbing level that i ts user community does not want to know about. However, is it possible to define OGSA in such a way that it does not mandate the WSRF approach to resources? Well I have talked with Andrew Grimshaw and o thers and Andrew believes that this might indeed be possible. I would the refore ask you to be open-minded and assist such an investigation. Obviously the first implementations of OGSA will be WSRF based and I expect many UK projects will be very happy to adopt WS RF, GT4 and a WSRF version of OGSA-DAI. What about a non-WSRF implementation? All I know is that Paul, Savas and Jim investigated alternative, non-WSRF ways of providing OGSA-like functionality in a small UK project - but I suspect that the final word has not yet been said on how to provide such implementations. I do not want to de-rail WSRF - as I said it will certainly be adopted by many UK projects. I just want GGF/OGSA to leave the door open - so that if it does turn out that the WSRF way is not so good for inter enterprise applications - then GGF and OGSA are not made obsolete. Ian often asks me why the UK are so keen on Web Services . I used to reply that Web Services were significant only because Microsoft and IBM had agreed to agree - the Men In Black philosophy. Following this philosophy it is surely self-evident that GGF, Grids and the whole Cyberinfrastructure agenda would be much, much stronger if both Microsoft and IBM were engaged. This is why giving some space between OGSA and specific implementations using WSRF is so importa nt. I should end by noting that these are my own opinions. Furthermore, the people I have explicitly cited may or may not agree wi th the opinions I have attributed to them. I hope at least that my views and intentions are now clear. Tony -----Original Message----- From: Frank Siebenlist [mailto:franks@mcs.anl.gov] Sent: 01 March 2005 07:08 To: Ian Foster Cc: Dennis Gannon; Samuel Meder; ogsa-wg; Tony Hey Subject: Re: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'C hallenging Times for GGF & Standards' So... if ws-transfer and ws-properties are sets of convent ions that do essentially the same thing, then it's actually a great c ompliment to ogsa's choice of wsrf that MS decided that it needs a similar functionality! Do I understand that Tony essentially asks the OGSA-WG t o come up with an additional abstraction layer that allows one to model the usage patterns such that it can map to either wsrf or ws-tra nsfer implementations? ...but if we model the usage patterns with wsrf, and w srf and ws-transfer are doing conceptually the same thing, isn't t he ogsa-wg doing just that: it uses an abstraction that can be us ed to describe the relevant usage patterns without losing any generality. The idea of inventing "yet an other abstraction layer" d oesn't sound very productive. -Frank. Ian Foster wrote: > Dennis: > > I'm not sure that the "we don't need WSRF" is th >e heart of the debate. > If it was, then I think things are fairly clear:=2 >0W SRF is just some > conventions for the messages that you send to do c >er tain things (e.g., > getResourceProperty to get state, Terminate to destroy=2 >0s omething, or > whatever the names are) in a WS context. If you >do n't have those > conventions, then everyone ends up defining their own, > so that e.g. a > job management interface might have "getJobStatus" and=2 >0" destroyJob", a > file transfer interface might have "getTransferStatus" a >nd > "destroyTransfer". This lack of consistency just makes=2 >0l ife difficult, > without providing any benefits. > > The debate with MS, as I understand it, seems to=2 >0r ather relate to the > fact that they are promoting a *different* set of >co nventions for > doing similar things, e.g., WS-Transfer instead of WS-ResourceProperties. > > Ian. > > > > At 10:23 PM 2/28/2005 -0500, Dennis Gannon wrote: > >> hi Sam, >> i don't think MS has any orchestrated view on WSR >>F at all (but i may >> be wrong.) I think it is more the case that >>th ere are people working >> on grid standards (outside of microsoft) that feel >>th at what exists >> in the ws-spec world is sufficient. hence if there >>20 is any onus, it is >> on those folks to show us that this is true. =2 >>0w hat tony is saying is >> that users, i.e. application builders, should not hav >>e to deal with >> these details. The should see clearly defined OGSA >>se rvices and they >> should have an easy to understand set of interactio >>n patterns to use >> these services to build thier applications. the OG >>SA point of view >> is that to be precise in the definition of these >>20 behavior patterns >> requires a framework like wsrf. >> >> i actually feel that these things can all coexist. >>20 but from the >> politics of "what is simple", we seem to live in >>20 interesting times. >> >> dennis >> >> On Mon, 28 Feb 2005, Samuel Meder wrote: >> >> > On Mon, 2005-02-28 at 14:38 -0800, Frank Siebenli >>st wrote: >> > > Could anyone summarize MS' WS-view, and how i >>t differs from WSRF? >> > >> > So far I have not seen any substantial differen >>ce between the two >> > approaches and I definitely believe the onus is=2 >>0o n MS to show why >> people >> > should adopt their proprietary specifications vs. a >>do pting >> > something that is being developed in a open sta >>nd ards body, is >> > getting very close to a 1.0 version and has m >>ul tiple implementations behind it. >> > >> > /Sam >> > >> > > >> > > Thanks, Frank. >> > > >> > > >> > > >> > > Hiro Kishimoto wrote: >> > > >> > > >Hi all, >> > > > > > >Absorbing article by Tony Hey. >> > > > >> > > >http://news.tgc.com/nview.jsp?appid=3D360&print=3D1#342708 >> <http://news.tgc.com/nview.jsp?appid=3D360&print=3D1#342708> >> > > >---- >> > > >Hiro Kishimoto >> > > > >> > > > >> > > > >> > > >> GRIDtoday >> > > >> NEWS AND INFOR >>MA TION FOR THE GLOBAL GRID COMMUNITY >> > > >> >> --- February 28, 2005: Vol. 4, No. 8 --- >> > > >> >> > > >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > > >>SPECIAL FEATURES >> > > >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > > >> >> > > >>[ ] M342708 ) WSRF? WS-*? Where is GGF's >>20 OGSA Headed? >> > > >> By Tony Hey >>, Contributing Editor >> > > >> >> > > >> Tony Hey, director of e-Science for the >> Engineering and >> > > >>Physical Science Research Council, continues to >> elaborate the >> > > >>need for open standards in the realm of W >>eb services-based Grid >> > > >>computing. He discusses the great debate of=2 >>0W SRF vs. WS-*, and >> > > >>lays out what the >> > GGF >> > > >>must do with OGSA in order to give e-Scie >>nc e application >> > > >>developers something to rally around. >> > > >> >> > > >> >> > > > >> > > > >> > > > >> > > >> > -- >> > Sam Meder <meder(a)mcs.anl.gov> >> > The Globus Alliance - University of Chicago >> > 630-252-1752 >> > >> > >> > > > _______________________________________________________________ > Ian Foster =2 >0 www.mcs.anl.gov/~foster > <http://www.mcs.anl.gov/%7Efoster> > Math & Computer Science Div. Dept of Computer Sci >en ce > Argonne National Laboratory The University of Chic >ag o > Argonne, IL 60439, U.S.A. Chicago, IL 60637, > U.S.A. > Tel: 630 252 4619 Fax:=2 >06 30 252 1997 > Globus Alliance, www.globus.org <http: >// www.globus.org/> > -- Frank Siebenlist franks@mcs. anl.gov The Globus Alliance - Argonne National Laboratory ********************************************************************** Internet communications are not secure and therefore EPSRC does not accept legal responsibility for the contents of this message. Any views or opinions presented are solel y those of the author and do not necessarily represent those of the EPSRC unless specifically stated. All EPSRC staff can be contacted using Email addresses w ith the following format: firstname.lastname(a)epsrc.ac.uk **********************************************************************

1 0