Manpages

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)