| |
Federated Naming Service (FNS) provides a method for federating multiple naming services under a single, simple interface for the basic naming operations. The service supports resolution of composite names, names that span multiple naming systems, through the naming interface. In addition to the naming interface, FNS also specifies policies for composing names in the enterprise namespace. See fns_policies(5)
and fns_initial_context(5).
Fundamental to the FNS model are the notions of composite names and contexts. A context provides operations for:
- associating (binding) names to objects
- resolving names to objects
- removing bindings, listing names, renaming and so on.
A context contains a set of names to reference bindings. A reference contains a list of communication end-points. Every naming operation in the FNS interface is performed
on a context object.
The federated naming system is formed by contexts from one naming system being bound in the contexts of another naming system. Resolution of a composite name proceeds from contexts within one naming
system to those in the next, until the name is resolved.
XFN
| |
XFN is X/Open Federated Naming. The programming interface and policies that FNS supports are specified
by XFN. See xfn(3XFN) and fns_policies(5).
|
Composite Names
| |
A composite name is a name that spans multiple naming systems. It consists of an ordered list of components. Each component is a name from the namespace of a single naming system. FNS defines the syntax for constructing a composite name using names from component naming systems. Individual naming systems are responsible for the syntax of each component.
The syntax for composite names is that components are composed left to right using the slash character ('/') as the component separator. For example, the composite name .../Wiz.Com/site/Oceanview.East consists of four components: ..., Wiz.COM, site, and Oceanview.East. See fns_policies(5) and fns_initial_context(5) for more examples of composite names.
|
Why FNS?
| |
FNS is useful for the following reasons:
- A single uniform naming interface is provided to clients for accessing naming services. Consequently, the addition of new naming services does not require changes to applications or existing
naming services. Furthermore, applications that use FNS will be portable across platforms because the interface exported by FNS is XFN, a public, open interface endorsed by other vendors and by the X/Open Company.
- Names can be composed in a uniform way (that is, FNS supports a model in which composite names are constructed in a uniform syntactic way and
can have any number of components).
- Coherent naming is encouraged through the use of shared contexts and shared names.
|
FNS and Naming Systems
| |
FNS has support for NIS+, NIS, and files as enterprise-level naming services. This means that FNS implements the enterprise-level policies using NIS+, NIS, and files. FNS also
supports DNS and X.500 (via DAP or LDAP) as global naming services, as well as support for federating NIS+ and NIS with DNS and X.500. See the corresponding individual man page for information about the implementation
for a specific naming service.
|
|
