All, In the BES working group call last week the issue of naming came up. The current DRAFT specification calls for passing WS-Names in and out of the various function calls. There was the question as to whether EPR's is all that should be specified. We thought this is an OGSA issue: mainly is OGSA endorsing the use of WS-Names where appropriate. Clearly I think we should. But this should be discussed. Andrew
Personally, I view naming as an important part of the basic nature of a Grid. OGSA has already bought into the story that a 3-tiered naming structure is an important part of a workable grid solution. Given that WS-Names represent the lower two levels of this hierarchy, it seems that anything but full endorsement of WS-Names as the OGSA way of handling resiliant, location transparent, names for grid resources would weaken the story that OGSA has to tell. In my personal opinion, I think it's very important that OGSA endorse WS-Names as a core requirement for usable grid resources. Otherwise, various legitimate implementations of OGSA services will provide varying levels of reliability and accessability which will make programming grid applications very difficult. -Mark
-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Andrew Grimshaw Sent: Monday, August 29, 2005 9:26 AM To: ogsa-wg@ggf.org Subject: [ogsa-wg] BES query
All,
In the BES working group call last week the issue of naming came up. The current DRAFT specification calls for passing WS-Names in and out of the various function calls. There was the question as to whether EPR's is all that should be specified. We thought this is an OGSA issue: mainly is OGSA endorsing the use of WS-Names where appropriate. Clearly I think we should. But this should be discussed.
Andrew
I believe that the opinion was expressed by some at the San Diego meeting (e.g., by Steve Tuecke) that WS-Names should NOT be mandated. It certainly defines a nice way of using EPRs that will be useful in some situations. But it surely can't be the case that we always want to mandate this particular set of extensions to EPRs. That requirement certainly doesn't jibe with how we use them in all cases, for example. Ian. At 09:25 AM 8/29/2005 -0400, Andrew Grimshaw wrote:
All,
In the BES working group call last week the issue of naming came up. The current DRAFT specification calls for passing WS-Names in and out of the various function calls. There was the question as to whether EPRs is all that should be specified. We thought this is an OGSA issue: mainly is OGSA endorsing the use of WS-Names where appropriate. Clearly I think we should. But this should be discussed.
Andrew
_______________________________________________________________ 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
All, We did not discuss this issue at all in Sunnyvale. We discussed whether AbstractNames should be mandatory in use of the resolution protocol of WS-Naming -specifically whether the resolution function should take a vanilla EPR or require a WS-Name (EPR with AbstractName) as a parameter. By parameter I mean either as an explicit parameter or as an implicit parameter in the header. The decision was that an AbstractName was NOT required in the resolution function. Thus the function is typed as taking (and returning) an EPR rather than a WS-Name. However, it is the inclusion of the AbstractName in the EPR that makes it a WS-Name. The issue I originally raised was not about whether resolution took EPR's or WS-Names - rather should OGSA mandate/encourage the use of WS-Names. I distinguish between those two because mandate is too strong; for example in RNS a path may refer to either a WS-Name or an EPR - an EPR that is just to some "plain-old" web-service. I believe that we should certainly encourage WS-Names - they give clients the ability to UNIQUELY identify an endpoint and compare EPR's to determine if they refer to the "same" endpoint - a capability otherwise not part of WS-Addressing. In the case of BES I think the argument is very strong. Many different actors (players) may need to refer to a BES activity over time - loggers, "job managers", accounting services, exception managers, workflow engines, and so on. The ability to uniquely identify an activity is crucial. Andrew _____ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Monday, August 29, 2005 2:57 PM To: Andrew Grimshaw; ogsa-wg@ggf.org Subject: Re: [ogsa-wg] BES query I believe that the opinion was expressed by some at the San Diego meeting (e.g., by Steve Tuecke) that WS-Names should NOT be mandated. It certainly defines a nice way of using EPRs that will be useful in some situations. But it surely can't be the case that we always want to mandate this particular set of extensions to EPRs. That requirement certainly doesn't jibe with how we use them in all cases, for example. Ian. At 09:25 AM 8/29/2005 -0400, Andrew Grimshaw wrote: All, In the BES working group call last week the issue of naming came up. The current DRAFT specification calls for passing WS-Names in and out of the various function calls. There was the question as to whether EPRs is all that should be specified. We thought this is an OGSA issue: mainly is OGSA endorsing the use of WS-Names where appropriate. Clearly I think we should. But this should be discussed. Andrew _______________________________________________________________ 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/>
participants (3)
-
Andrew Grimshaw -
Ian Foster -
Mark Morgan