NAME
fns − overview of FNS
DESCRIPTION
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.
SEE ALSO
nis+(1), xfn(3XFN), fns_dns(5), fns_files(5), fns_initial_context(5), fns_nis(5), fns_nis+(5), fns_policies(5), fns_references(5), fns_x500(5)