Federated Naming Specification (XFN)

Naming Services

• associating (binding) names to objects

• resolving names to objects, which also identifies how to access them

• assigning information (attributes) to objects and supporting the sharing of that information

• removing bindings, listing names, renaming and so on.

Traditional systems include a multitude of naming services, usually integrated with another service, such as a file system, directory service, database, desktop, mail system, spreadsheet, or calendar.

Each of the naming service interfaces differ widely and the essential naming operations are often obscured.

Furthermore, within a distributed system, the name of an object may be composed of elements from several different naming systems. Such a name is referred to as a composite name.

Federated Naming Specification

The Federated Naming Specification (XFN) defines an interface comprising a set of common naming operations, that map a composite name to an object reference. The XFN does not specify administrative interfaces as the administrative models of different naming services vary too widely to permit a useful generic treatment.

The XFN is intended to be implemented over a number of existing naming services, using their existing programming interfaces and protocols, as well as with new naming services in the future.

The components of the XFN specification are:

• XFN API
  The XFN API is the means by which clients interface with the XFN services and is described in more detail later in this chapter.
  

• XFN composite name string representation
  This is not of significance to this report and is not described further. Refer to XFN for further information.

• XFN naming policies
  XFN naming policies are concerned with the structuring of names at differing levels including, global, enterprise and application levels. This is not of significance to this report and the reader is referred to the XFN for further information.

• XFN reference and address
  A reference is the address of an object by which the object may be manipulated. The reference includes an indication of the type of object, and a list of addresses via which it may be accessed. An address comprises an address type identifying the mechanism that should be used to reach the object and an opaque data buffer containing the address information for that mechanism.

There are additionally optional components:

• XFN protocols
  An XFN protocol is a protocol for communication between XFN client and server components and provides for the support of the distribution of XFN services and the interworking between different XFN implementations.

• XFN context implementation
  An XFN context implementation is the implementation of a service interface between an XFN implementation and an underlying name service.

• XFN enterprise policies
  The XFN defines a set of policies for the structuring of common name spaces within an enterprise namespace. These include policies for the structuring of the namespaces for organisational units, hosts, users, filesystems and services. The reader is referred to XFN for further information.

Implementation Models

The three diagrams XFN Configuration using Client Context Implementations , Lightweight XFN Client Configuration and XFN Configuration with Surrogate Client serve as examples of the conceptual models of the different possible configurations. The dark shaded boxes shown in these diagrams are building blocks that a naming service integrator needs to provide in order to integrate the naming system with XFN. The modules depicted in the three diagrams are defined as follows:

XFN API

The XFNAPI is the complete set of interface operations defined in this XFN specification.

XFN Framework

The XFN framework is the implementation of the XFN API, including the client library and the service provider interfaces necessary for integrating native naming systems.

Context Implementation

The context implementation is the naming service-specific module on the XFN client system that is required to integrate legacy naming systems with XFN. The code of the context implementation is a wrapper that maps the XFN API to the API exported by the legacy naming system. The complexity of the context implementation depends on how well the XFN API maps to the native naming service API and which XFN operations are to be supported. At a minimum, the name resolution phase of all operations must be supported.

The techniques used to access the naming service-specific context implementations from the XFN framework may vary. For systems that support shared libraries and dynamic linking, a common approach might be that the context implementations are dynamically loadable modules.

This approach of integrating a naming service using a context implementation module does not require any modification to the existing naming service's source code nor does it require access to the naming service's source code. All that is needed is access to the module (library) that exports the naming service-specific API. This approach is by far the easiest and fastest way of adding an existing naming system into the XFN federation.

XFN Client

The XFN client is a module that implements the client protocol machines for the XFN protocols.

Two XFN protocols are specified, the RPC based protocols for ONC+ systems (specified in RPCL) and for DCE environments (specified in IDL).

In addition to supporting the protocols, the XFN client might provide services typically offered by naming clients, such as caching. The extent of this support is implementation-specific.

XFN Protocol Exporter

The XFN protocol exporter is the module required on systems that export one of the XFN protocols. This could be a new naming system, an existing naming system that was modified to also support XFN protocols, or a system that supports the XFN client library and also exports XFN protocols (capable of acting as surrogate client).

The advantage for naming systems that support one of the specified protocols is that any existing XFN client that imports the protocols can be used to communicate with it. This is particularly useful for applications that need to export naming interfaces. Application programmers do not have to duplicate the client-side implementation and they do not have to invent new naming interfaces. This provides additional benefits such as the ability to utilise caching and other mechanisms provided by the XFN client implementations, and a direct (and possibly more efficient) mapping of XFN operations to the application's naming operations.

XFN Configuration using Client Context Implementations shows the layering of the XFN client library on top of existing naming system clients on the same system. None of the legacy naming systems needs to be modified.

Figure: XFN Configuration using Client Context Implementations

Figure: Lightweight XFN Client Configuration

The legacy naming system clients in XFN Configuration with Surrogate Client reside on a remote system (similar to XFN Configuration using Client Context Implementations ) that also exports at least one of the XFN protocols. This remote client can be viewed as a surrogate or proxy client that acts on behalf of the initial requestor and performs the native naming system functions.

Figure: XFN Configuration with Surrogate Client

Another aspect shown in XFN Configuration using Client Context Implementations and XFN Configuration with Surrogate Client is the capability of the surrogate client to also import the XFN protocol (XFN client module). Such a configuration could serve emerging XFN servers or existing name servers that export one of the specified XFN protocols in addition to, or in replacement of, the native protocol.

Note that a context implementation precisely defines the set of modules that are co-located with the XFN framework to map the XFN API to the native naming service API. However, in the context of this description, we also use the term context implementation to mean the XFN mapping code that is necessary at the server of a naming system that directly exports one of the XFN protocols ( XFN Protocol Exporter and XFN Server in the diagrams).

XFN API

• the basic context interface
  The basic context interface provides the operations for naming, such as binding a name to a reference, looking up the reference bound to a name, unbinding a name.

• the basic attribute interface
  The basic attribute interface provides operations to examine and modify attributes associated with named objects.

• the extended attribute interface.
  The extended attribute interface provides operations to do searching and creation of objects in the namespace with attributes.

A summary of the XFN functions is presented below with the functions grouped in a categorisation with a security perspective in mind. That is functions are grouped with the definition of security policy in mind. The names of the functions listed provide a good indication of their purpose and the style of the interface. The reader should refer to XFN itself for more detail.

All name resolution operations occur by reference to a context. A handle to an XFN context is an input parameter to almost every XFN function. Before the XFN functions may be used an initial XFN context handle must be obtained. Handles to additional contexts represented by an XFN reference are obtained from a name lookup operation. The functions that manipulate XFN contexts are:

• fn_ctx_handle_from_initial()

• fn_ctx_handle_from_ref()

• fn_ctx_get_ref()

• fn_ctx_get_syntax_attrs()

• fn_ctx_handle_destroy()

The principal purpose of a name service is to resolve names to object addresses, or XFN reference. The functions that support this purpose are:

• fn_ctx_lookup()

• fn_ctx_list_names()

• fn_namelist_next()

• fn_namelist_destroy()

• fn_ctx_list_bindings()

• fn_bindinglist_next()

• fn_bindinglist_destroy()

• fn_ctx_lookup_link()

To support the name resolution process name to object bindings must be created and managed. the set of functions that support this functionality are:

• fn_ctx_bind()

• fn_attr_bind()

• fn_ctx_unbind()

• fn_ctx_rename()

• fn_ctx_create_subcontext()

• fn_attr_create_subcontext()

• fn_ctx_destroy_subcontext()

The creation of a subcontext creates a new branch in a context namespace. (It is like a mkdir operation in a filesystem.)

The attribute related functions included under bind management are part of the extended attribute interface and provide for the creation of objects with attributes assigned as part of the creation operation.

A secondary purpose of a name service is to support the assignment of information attributes to objects and the sharing of that information between users of the name service. The XFN includes functions that operate with single attribute values, multiple attribute values, and multiple attributes:

• fn_attr_get()

• fn_attr_modify()

• fn_attr_get_values()

• fn_valuelist_next()

• fn_valuelist_destroy()

• fn_attr_get_ids()

• fn_attr_multi_get()

• fn_multigetlist_next()

• fn_multigetlist_destroy()

• fn_attr_multi_modify()

The extended attribute interface provides for search capability based on attributes. The functions are:

• fn_attr_search()

• fn_searchlist_next()

• fn_searchlist_destroy()

• fn_attr_ext_search()

• fn_ext_searchlist_next()

• fn_ext_searchlist_destroy()