[ogsa-wg] Re: [ogsa-naming-wg] Data architecture requirements on naming

[David Snelling]

Dave,

Good points and more issues for the Naming WG to chew on.

My point of view:

Of your options, I don't think we should run down the policy route. It 
would have to be an open ended tag that might have a couple of 
predefined policies, fastest, most secure, cheapest, ... But there will 
be others: "any one will do except from that useless repository at 
XXX".

There is also the possibility that a single EPR can contain multiple 
resolutions. See Tom proposal for wsdl bindings. Also, recall that in 
OGSI we had the Locator as the return value from a resolver. It 
contained other names (GSHs) and well as a number of (GSRs).


On 22 Nov 2005, at 10:29, Dave Berry wrote:

> Dear All,
>
> Recent discussions on the OGSA data architecture have raised two use
> cases that may affect the naming discussion.  Both involve the mapping
> of one "abstract" (for some meaning of "abstract") name to multiple
> possible "concrete" names.  A further step is then required to choose
> the best "concrete" name, according to the policies required by the
> client.  We are wondering whether the WS-Name/EPR resolution services
> can be modified to support these functionalities.
>
> Note: here, "abstract" names may or may not have the same meaning as
> abstract names in the proposed WS-Names spec.  This is an issue that
> needs clarification.
>
> Case 1 is when we are dealing with replicated data.  It is common to
> have an "abstract" name that represents a given file, table or query
> result that is stored someone in the system.  This is then resolved to
> one of multiple copies.  The client typically wants the copy with the
> best response time (which will be some function of latency and
> bandwidth).
>
> Case 2 is when we are dealing with data stored at a certain location 
> and
> the data may be accessed by several different protocols (e.g. GridFTP,
> HTTP, ...).  The client (or transfer service) wants to map the
> "abstract" name to the fastest protocol that it can handle.
>
> In each case, we could take one of two approaches:
>
> (A) resolve the "abstract" name to a list of "concrete" names, and use 
> a
> separate selection service to choose among them
>
> (B) pass the appropriate policy specification to the resolver service,
> which will then return the appropriate "concrete" name.
>
> Note: (B) could be considered (and even implemented) as a composition 
> of
> the resolver and selection services in (A).
>
> Would it make sense to specify either one of these functionalities as
> part of the resolver services considered in WS-Naming?  E.g. the
> operations could return a list instead of a single EPR (option A) or
> they could return a single EPR as now but take a policy argument 
> (option
> B).
>
> Best wishes,
>
> Dave Berry
> Research Manager, National e-Science Centre
> 15 South College St., Edinburgh
> Tel: +44 131 6514039
>
>
-- 

Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
     Fujitsu Laboratories of Europe
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE

     +44-208-606-4649 (Office)
     +44-208-606-4539 (Fax)
     +44-7768-807526  (Mobile)