[ogsa-wg] BES query

Wed Aug 31 08:15:19 CDT 2005

owner-ogsa-wg at ggf.org wrote on 08/31/2005 12:11:00 AM:

> 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.

That is correct

>If so,
> then a unique AbstractName is needed in order to accurately resolve
> EPRs, especially considering the potential service migration.

I think that AbstractName is certainly one approach to solving this
problem.  Remember that ReferenceParameters are used to provide information
to the RECEIVER(wsa:to) to disambiguate the resource for dispatch.
Obviously, in order for the refParams to be useful they should be
unique (in some context).  The wsa:to provides the context in this
case.  I can envision lots of service migration scenarios that could
take advantage of the above fact and would ensure that the ResolverEPR
was correctly informed of the migration (change in wsa:to URI).

> 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).

Agree with this statement.  In essence, if a service requires the
ws-naming claim it can check for it...

> 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>
> >>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
>
> --
> Michael Behrens
> R2AD, LLC
> (571) 594-3008 (cell) *new*
> (703) 714-0442 (land)