- online man pages   

SunOS man pages : fns (5)

Standards, Environments, and Macros                        fns(5)


fns - overview of FNS


Federated Naming Service (FNS) provides a method for federating multiple naming services under a single, simple interface for the basic naming operations. The service sup- ports resolution of composite names, names that span multi- ple naming systems, through the naming interface. In addi- tion 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: o associating (binding) names to objects o resolving names to objects o 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 con- text 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 con- texts 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 sys- tems. 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 com- ponent. The syntax for composite names is that components are com- posed 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 SunOS 5.8 Last change: 22 Nov 1996 1 Standards, Environments, and Macros fns(5) fns_policies(5) and fns_initial_context(5) for more exam- ples of composite names. Why FNS? FNS is useful for the following reasons: o 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 port- able across platforms because the interface exported by FNS is XFN, a public, open interface endorsed by other vendors and by the X/Open Company. o Names can be composed in a uniform way (that is, FNS supports a model in which composite names are con- structed in a uniform syntactic way and can have any number of components). o 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 nam- ing 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.


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) SunOS 5.8 Last change: 22 Nov 1996 2