[ogsa-wg] RE: [ogsa-d-wg] Data architecture requirements on naming

[Hiro Kishimoto]

Peter's email bounced.
-- 
Hiro Kishimoto

Subject: RE: [ogsa-d-wg] Data architecture requirements on naming
Date: Tue, 22 Nov 2005 13:36:31 +0100
From: "Peter Kunszt" <Peter.Kunszt at cern.ch>
To: "David Berry" <daveb at nesc.ac.uk>, <ogsa-naming-wg at ggf.org>,
	"ogsa-wg" <ogsa-wg at gridforum.org>, <ogsa-d-wg at gridforum.org>

hi dave

in our experience, case (B) is not being used by clients.
the reason is that the policies that are put in place
to find the 'best' concrete replica are very application
specific and are usually implemented by the applications
themselves. what turned out to be much more useful was to
present the list of replicas when asked for it with some
measured qualifyers that the grid can provide, i.e. predicted
access cost, latency, time to wait (queues) or whatever is
available so that the application can resolve the 'best'
replica based on any model/policy they may want to apply.

it turned out that implementing a generic policy enforcer
is very difficult and what you end up doing is to provide
a python interpreter so that the applications can write
their own policy scripts...

hope this helps,

cheers,
peter


 >> -----Original Message-----
 >> From: owner-ogsa-d-wg at ggf.org
 >> [mailto:owner-ogsa-d-wg at ggf.org] On Behalf Of Dave Berry
 >> Sent: 22 November 2005 11:30
 >> To: ogsa-naming-wg at ggf.org; ogsa-wg; ogsa-d-wg at gridforum.org
 >> Subject: [ogsa-d-wg] Data architecture requirements on naming
 >>
 >> 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