Ian,
As
always, you raise interesting questions. Some I want to ask you about
further; some I would like to see other people address.
However, I was surprised by your reply about the "three levels" of
naming. While WS-naming doesn't include these concepts, the OGSA v1.0
document does. They also form the basis of the GFS working group work that
led to RNS and WS-Naming, and are important parts of EDG/EGEE, for
example. That doesn't mean that you have to agree with it but I'm
surprised that this issue wasn't resolved earlier.
I'm
also surprised that you give name equivalence as the main
characteristic of an abstract name. I thought the main characteristic was
that it was a persistent name that does not specify a particular location.
(Although this could be a property of the WS-Name package rather than the
string - see below).
I'm
afraid I don't follow your example of a file replication system. Clearly
we need to name the separate entities involved and there may be many levels of
indirection. I don't see why that is an argument against the three level
approach. We don't need to have one "level" of name for each "level" of
indirection.
Turning to a question I'd like to see other people
address:
Ian's point about uniqueness within a particular context makes good
sense to me. If a WS-Name is a combination of an arbitrary string and a
resolver, isn't it the combination of the two that should be globally
unique? E.g. if one WS-Name resolves "foo" to my hard drive and
another resolves "foo" to Ian's, the two WS-Name packages themselves are
still globally unique. I suppose this is why Ian took name equivalence as
a key property. Do we perhaps need a scope notion in WS-Names, so that
they may be valid within a VO, or globally unique, or have some other
scope?
I
guess the counter to this is whether it is really such an imposition to create a
globally unique string, given that UUIDs seem to do the job.
Dave.
Dave:
My "proposal" was just a
request that we have the "resolver EPR" in a separate
specification.
However, in a bit more detail, here are my opinions in
this area:
1) The BES specification should just use EPRs, and not
mandate the use of WS-Naming AbstractNames.
Rationale: Such a
requirement imposes a cost on BES users that they may not want to pay--for a
benefit that they may not require.
Mandating the use of WS-Naming names
imposes an overhead in terms of both time (the cost of generating the
AbstractName) and space (the storage that it requires).
Yet:
a)
I may not need to perform the equivalence test that AbstractNames are
introduced to allow. (E.g., I haven't thought deeply about this--but I can't
recall that we've ever encountered that need.)
b) I may need to
perform an equivalence test, but not require the "globally unique in time and
space" constraint that WS-Naming requires. [This constraint presumably
constrains the form of the name that I can create, preventing me, for example,
from using user-supplied strings.]
c) I may need to perform an
equivalence test, but want to do that at a different level: e.g., I may
already maintain my own table of jobs for some other purpose, so the WS-Naming
AbstractName just replicates unique data that I am already
maintaining.
If people WANT to pass around EPRs that have these
AbstractNames in them (or other similar constructs with different
constraints/semantics: e.g., "unique within my VO"), all power to them: but I
don't see a reason to require this in BES or any other
specification.
2) We should have a separate specification for the
"resolver EPR" (and associated Resolver portType) and the "AbstractName"
concept.
Rationale: The "resolver" EPR is useful in a wide range of
situations independent of the specific name syntax and semantics described in
WS-Naming.
I can imagine lots of places where I might use a resolver
EPR. E.g., maybe in the BES case my jobs can migrate, and so I want the EPR
that I get back to include a resolver EPR that I can use to determine its new
location. But as noted above, I don't necessarily need an AbstractName in the
BES case.
Similarly for relocatable services: maybe I'll do a metadata
query on a registry to get a service EPR (with a resolver EPR in it), then if
the service is not where the registry says, contact the resolver to determine
its new location. Again, I don't see that I will need AbstractName semantics
here.
Thus, given that we have two concepts that seem logically quite
distinct, and that are certainly distinct in terms of when and how that will
be used, I argue that they should be separated.
3) You also asked
about three levels and about "human-oriented" vs. "abstract". These concepts
are not in the WS-Naming spec, but for what it's worth, I don't see them as
useful or relevant here. People use many sorts of "names" of different sorts,
and they don't cleanly separate into three levels or into "human-oriented" or
"abstract". E.g., if I'm implementing a replica location service, I often want
to map first from a "logical file name" to a "site name" and then from there
to a "physical location." Furthermore, if you build a system of this sort, you
have to allow people to stick whatever names are convenient for them in at
each level, because often these names come from elsewhere. Some users may make
some of these names "human-oriented", others may not--it shouldn't matter to
the service.
Regards -- Ian.
At 08:58 PM 8/30/2005
+0100, Dave Berry wrote:
Ian,
I wonder whether you
or one of your team could write a note about the
background to your
proposals? It would help me to understand how they
fit into the
wider architecture. At present I don't feel able to make
an
informed contribution to the discussion.
The current shape of OGSA
(if I can call it "current" without biasing
the discussion) has three
concepts relevant to this discussion:
1. Three levels of
naming (human-oriented, abstract, and address).
2. An
implementation of abstract names as an EPR containing a string
and a
resolver.
3. A service interface for BES that takes abstract
names as
parameters.
Each has associated questions raised by your
concerns:
1. Do you want to have fewer levels of naming
across the architecture
or are you happy with the three listed
here?
2a. Are you happy that abstract names should be
represented in this
way?
2b. What would a "resolver without an
abstract name" resolve? When do
you need it in addition to or
instead of an abstract name? Does it
fulfill a different function
or is there some overlap?
3. What should the BES
interface accept instead of or as well as
abstract names? When do
you need this functionality? How should the
interface cope with the
different types of entity?
I can make a guess at part of these
answers but I'd rather read an
explanation from the horse's
mouth.
Best wishes,
Dave.
-----Original
Message-----
From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of
Ian
Foster
Sent: 30 August 2005 04:02
To: Tom Maguire
Cc: Andrew
Grimshaw; ogsa-wg@ggf.org
Subject: Re: [ogsa-wg] BES query
I'm
interested in that question too. As I've said on quite a few
occasions,
I like the EPR + ResolverEPR (as in the original
WS-RenewableReferences)
--
that is a nice simple mechanism. I don't
understand why we can't have
this
in a separate
specification.
Ian.
At 09:23 PM 8/29/2005 -0400, Tom
Maguire wrote:
>So just to get some nomenclature correct. By
WS-Names we mean an EPR
>that
>is profiled to
>contain
both a ResolverEPR and an AbstractName. So what do we call an
EPR
>which just
>contains a
ResolverEPR?
>
>Tom
>
>Ian Foster
wrote:
>
>>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
>><http://www.mcs.anl.gov/%7Efoster>
>>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/>
_______________________________________________________________
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