[ogsa-d-wg] RNS spec

[Stephen Davey]

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-d-wg/attachments/20051212/56156bc8/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 35887 bytes
Desc: image001.jpg
Url : http://www.ogf.org/pipermail/ogsa-d-wg/attachments/20051212/56156bc8/attachment.jpe 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ogsa_rns_3tier_diag.JPG
Type: image/jpeg
Size: 37205 bytes
Desc: ogsa_rns_3tier_diag.JPG
Url : http://www.ogf.org/pipermail/ogsa-d-wg/attachments/20051212/56156bc8/attachment-0001.jpe