[ogsa-wg] BES query
Ian Foster
foster at mcs.anl.gov
Tue Aug 30 18:34:32 CDT 2005
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 at ggf.org [mailto:owner-ogsa-wg at ggf.org] On Behalf Of
>Ian Foster
>Sent: 30 August 2005 04:02
>To: Tom Maguire
>Cc: Andrew Grimshaw; ogsa-wg at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20050830/962a1ed2/attachment.htm
More information about the ogsa-wg
mailing list