[ogsa-wg] BES query

Dave Berry daveb at nesc.ac.uk
Tue Aug 30 14:58:15 CDT 2005


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





More information about the ogsa-wg mailing list