Hi everyone, I've had a read of the RNS spec (Nov 2005 version), and made a short summary of it - see below. My own thoughts are as follows: - As suggested by the use of "Human Interface Names", I think that an RNS service would be very useful for user/client GUIs etc. But it does still seem to be quite file application oriented. - Would it be possible to customise the view of the namespace for different users? (Like for example in the way that everyone has their internet bookmarks/favourites arranged in folders of their own devising.) Perhaps one could build up one's own view as a series of federated namespace services that you have discovered. Although one could equally do this by building up a collection of data services perhaps? - The authors of the spec identify several issues that are not yet tackled including consistency and coherency (between redundant and delegated RNS services) and access control lists. These could be quite challenging! - I'm not sure how this all links in with WS-Names and it's "resolve" operation for example. WS-Naming isn't mentioned at all in the spec. Speaking to Malcolm Atkinson last week, he was wondering how data that was generated on the fly and yet to be materialised could be stored/named by the Resource Namespace Service. For example, data that is given by performing a query on a data service or resource, such as http://www.upmystreet.com/map/l/EH1.html?mapNest=1&mapSess=L1VLL2ZpbmRte W5lYXJlc3QvbW90b3JzL3R5cmUtZGVhbGVycy1hbmQtcmVwYWlycy9yZXN1bHRzL2luLw%3D %3D . I guess that because this is a valid URI it can be represented as an EPR and hence named within the RNS service? Cheers, Stephen. ------------------------------------------------------------------------ ---------------------------------------- For RNS spec see https://forge.gridforum.org/docman2/ViewCategory.php?group_id=115&catego ry_id=369 . The specification has 2 parts: Resource Namespace Service (RNS) - this is the main part of the spec. Resource Endpoint Resolution Service (RNS Resolver) - a companion service to RNS. Resource Namespace Service (RNS) - Hierarchically managed namespace for federated & virtualised data, services or any grid resources. - Looks like a directory tree (of entities). - WSRF compliant. - Revised abstraction of the Virtual Filesystem Directory Service (VFDS). - Has 3 types of names; Human Interface Names, (optional) Logical References, Endpoint References. - The optional Logical References (i.e. abstract names) can be used as an additional level of indirection to link the human names to the EPRs, with the assistance of an RNS Resolver or any other EPR (Name) Resolution Service. - Note that mapping information and associated pointer handles for directly mapped human interface name to endpoint references are not exposed by RNS and are therefore only used internally by RNS. - RNS features an extensible design allowing normative profile specifications, such as OGSA Basic Profiles, to define a standard set of resource properties for specific instantiations of the namespace service - deleteProperty, insertProperty, listProperties, updateProperty. - Specification does not address any data related namespace requirements. - RNS is comprised of two fundamental namespace components: virtual directories and junctions. - A virtual directory is an RNS entry that is represented as a non-leaf node in the hierarchical namespace tree. - A junction is an RNS entry that interconnects a reference to an existing resource into the global namespace. - Referral junctions are junctions that are used to graft RNS namespaces - allow federation of independent domains of control. - A logical reference junction is a junction that contains a context unique (potentially global) logical name. If the logical name is expressed as an EPR then a resolver service must be contained in the EPRs WS-Address. - RNS defines a stateful resource referred to as an IteratorContext. (Allows part of the directory list to be returned based on the current iterators index.) - Operations defined are: create, delete, list, lookup, update, (move, rename, mkdir), createIteratorContext, getIteratorContext. Resource Endpoint Resolution Service - Also known as RNS Resolver, provides resolution of logical references - i.e. an abstract name to address/EPR resolution service. - Independent of the RNS but may have the same service URL (but different port type). - RNS Resolver is composed of the following operations: 1) An operation for resolving logical names to endpoint references. 2) Operations for creating, removing, and updating logical references [and EPRs]. General considerations: - The following issues are not explored yet in the document: security, replication, consistency and coherency (between redundant and delegated RNS services), access control lists, root-level names and resolution services, and discovery. ---------------------------------------------------------------------- Stephen Davey, NextGrid Software Architect, National e-Science Centre, 15 South College St., Edinburgh, EH8 9AA, UK Tel: +44 131 6 509820
