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)