Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
fns(5)		      Standards, Environments, and Macros		fns(5)

       fns - overview of FNS

       Federated  Naming Service (FNS) provides	a method for federating	multi-
       ple naming services under a single, simple interface for	the basic nam-
       ing  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

       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 context object.

       The federated naming system is formed by	contexts from one naming  sys-
       tem 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 is  X/Open Federated	Naming.	The programming	interface and policies
       that FNS	supports are specified by XFN. See  xfn(3XFN)  and   fns_poli-

   Composite Names
       A  composite name is a name that	spans multiple naming systems. It con-
       sists 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  sys-
       tems.  Individual naming	systems	are responsible	for the	syntax of each

       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  com-
       posite names.

   Why FNS?
       FNS is useful for the following reasons:

	  o  A	single uniform naming interface	is provided to clients for ac-
	     cessing 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.

	  o  Names  can	 be composed in	a uniform way (that is,	FNS supports a
	     model in  which composite names are constructed in	a uniform syn-
	     tactic 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 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.

       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),

SunOS 5.9			  22 Nov 1996				fns(5)


Want to link to this manual page? Use this URL:

home | help