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@ggf.org [mailto:owner-ogsa-d-wg@ggf.org] On Behalf Of Dave Berry Sent: 22 November 2005 11:30 To: ogsa-naming-wg@ggf.org; ogsa-wg; ogsa-d-wg@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