[ogsa-wg] BES query
Michael Behrens
behrens at r2ad.com
Tue Aug 30 23:11:00 CDT 2005
2-cents: It is my understanding that EPRs can't by themselves be
guaranteed to be unique or that bit-wise comparisons are unreliable
considering canonicalization and embedded metadata issues. If so, then
a unique AbstractName is needed in order to accurately resolve EPRs,
especially considering the potential service migration.
Instead of mandating, perhaps the speficiations can recommended the use
of WS-Naming? Specifications could still accept EPRs and
implementations can check them for the presence of an AbstractName and
take advantage of it if available (internal hash table, etc).
Ian Foster wrote:
> 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>
>> >><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/>
>> <http://www.globus.org/>
>>
>> _______________________________________________________________
>> 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
> <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/>
>
--
Michael Behrens
R2AD, LLC
(571) 594-3008 (cell) *new*
(703) 714-0442 (land)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20050831/f037a50f/attachment.html
More information about the ogsa-wg
mailing list