Introduction to the Federated Naming Service (FNS)
This chapter is an overview of the Federated Naming Service (FNS).
What is Federated Naming?
Federated Naming Service provides a method for hooking up, or federating, multiple naming services under a single, simple uniform interface for the basic naming and directory operations. The service supports resolution of composite names--names that span multiple naming systems--through the naming interface. Each member of a federation has autonomy in its choice of naming conventions, administrative interfaces, and its particular set of operations, other than name resolution.
In the Solaris operating environment, the FNS implementation consists of a set of enterprise-level naming services with specific policies and conventions for naming organizations, users, hosts, sites, and services, as well as support for global naming services such as DNS and X.500. More specifically, FNS has support for:
Enterprise-level naming services: NIS+, NIS and files
Global-level naming services: DNS, and X.500 (over LDAP or DAP). See System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) for information on DNS Text records and X.500 attribute syntax for XFN references
Application-specific namespaces: file naming, printer naming
Generic application namespaces for other applications
What Is XFN?
XFN stands for X/Open Federated Naming. XFN is a standard that is actively supported by organizations such as Sun, IBM, Hewlett-Packard, DEC, Siemens, and OSF. The programming interfaces and policies that FNS supports are specified by XFN. An overview of XFN concepts is presented later in this chapter; Chapter 2, Interfaces for Writing XFN Applications describes the XFN programming interface in detail.
Note - In a 64-bit XFN application, the X.500 directory service is not supported.
FNS is compliant with the X/Open CAE Specification for Federated Naming (July 1995). Applications that use FNS are portable across platforms because the interface exported by FNS is XFN, a public, open interface endorsed by other vendors and X/Open. X/Open Co. Ltd. is part of the Open Group, which is an international standards organization committed to defining computing standards that are endorsed and adhered to by major computer vendors.
Why FNS?
FNS is useful for the following reasons:
A single uniform naming interface is provided to clients for accessing different naming services. As a consequence, the addition of new naming services does not require changes to applications or to existing member naming services. Furthermore, application developers need to learn and use only one naming interface.
Names can be composed in a uniform way, and the resulting composite names can have any number of components. This allows the composite namespace to serve the needs of diverse applications.
Coherent naming is encouraged through the use of shared contexts and shared names. This reduces duplication of effort in individual applications when supplying similar functionality.
FNS Policies
FNS provides applications with a set of policies on how namespaces are arranged and used. These policies specify:
The namespaces for enterprise objects: organizations, hosts, users, sites, and services. (These naming services support contexts that allow other objects to be named relative to these objects.)
The relationships between the organization, host, user, site, and service namespaces, and the names used to refer to these namespaces
The syntax of names in these namespaces
How to federate the enterprise namespace so that it is accessible in the global namespace
Names and bindings present in the initial context of every process
Table 1-1 is a summary of FNS policy for arranging the enterprise namespace and Figure 1-1shows that FNS policies provides a common framework for the three levels of service: global, enterprise, and application.
Table 1-1 Policies for the Federated Enterprise Namespace
Namespace Identifiers | Name Service Type | Subordinate Context | Parent Context | Namespace Organization | Syntax |
|---|---|---|---|---|---|
_orgunit | Organizational unit | Site, user, host, file system, service | Enterprise root | Hierarchical | NIS+ domain name Dot-separated, right-to-left |
_site | Site | Service, file system | Enterprise root, organizational unit | Hierarchical | Dot-separated, right-to-left |
_user | User | Service, file system | Enterprise root, organizational unit | Flat | Solaris login name |
_host | Host | Service, file system | Enterprise root, organizational unit | Flat | Solaris host name |
_service | Service | Application specific | Enterprise root, organizational unit, site, user, host | Hierarchical | / separated, left-to-right |
_fs | File system | None | Enterprise root, organizational unit, site, user, host | Hierarchical | / separated, left-to-right |
Printer | None | Service | Hierarchical |
What FNS Policies Do Not Specify
The FNS policies do not specify the specific names used within naming services. In addition, naming within the application is the responsibility of individual applications or groups of related applications. They also do not specify the attributes to use after the object has been named.
Figure 1-1 Different Levels of Naming Services
What FNS Enterprise Policies Arrange
The FNS enterprise policies deal with the arrangement of objects within the enterprise namespace. The policies are summarized in Table 1-1.
Organization - Entities such as departments, centers, and divisions. Sites, hosts, users, and services can be named relative to an organization. The XFN term for organization is organizational unit.
Site - Physical locations, such as buildings, machines in buildings, and conference rooms within buildings. Sites can have files and services associated with them.
Host - Computers. Hosts can have files and services associated with them.
User - Human users. Users can have files and services associated with them.
Service - Services such as printers, faxes, mail, and electronic calendars.
Figure 1-2 What FNS Policies Arrange
The namespace of an enterprise is structured around the hierarchical structure of organizational units of an enterprise. Names of sites, hosts, users, files, and services can be named relative to names of organizational units by composing the organizational unit name with the appropriate namespace identifier and object name.
In Figure 1-3, a user, jsmith in the engineering organization of an enterprise, is named using the name orgunit/desktop.sw.eng/user/jsmith
Figure 1-3 Example of an Enterprise Namespace
Initial Context Bindings
Resolution of a name in XFN always begins with some context. XFN defines an initial context as a starting point for name resolution. The initial context contains bindings that allow the client application to (eventually) name any object in the enterprise namespace. Figure 1-4shows the same naming system as the one shown in Figure 1-3, except that the initial context bindings are shaded and shown in italics.
Figure 1-4 Example of Enterprise Bindings in the Initial Context
The initial context has a flat namespace for namespace identifiers. The bindings of these namespace identifiers are summarized in Table 1-2. The categories of bindings are:
User-related bindings
Host-related bindings
"Shorthand" bindings
In Table 1-2, the user to which the bindings are related is denoted by U, and the host to which the bindings are related is denoted by H. Not all of these names need to appear in all initial contexts. For example, when a program is invoked by the superuser, none of the user-related bindings appears in the initial context.
Table 1-2 Initial Context Bindings for Naming Within the Enterprise
Namespace Identifier | Binding |
|---|---|
_myself | U's user context |
_myens | The enterprise root of U |
_myorgunit | U's distinguished organizational unit context. For NIS+, the distinguished organizational unit is U's NIS+ home domain. For NIS and files, it is the current domain and system, respectively. |
_thishost | H's host context |
_thisens | The enterprise root of H |
_thisorgunit | H's distinguished organizational unit context. For NIS+, the distinguished organizational unit is H's NIS+ home domain. For NIS and files, it is the current domain and system, respectively. |
_user | The context in which users in the same organizational unit as H are named |
_host | The context in which hosts in the same organizational unit as H are named |
_orgunit | The root context of the organizational unit namespace in H's enterprise. For NIS+, this corresponds to the NIS+ root domain. For NIS and files, it is the current domain and system, respectively. |
_site | The root context of the site namespace at the top organizational unit if the site namespace has been configured |
/... | Global context for resolving DNS or X.500 names |
Global context for resolving DNS names | |
_x500 | Global context for resolving X.500 names |