[ новости /+++ | форум | теги | ]

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

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)

Партнёры:

Хостинг: