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
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&category_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,
Tel: +44 131 6 509820