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-1 shows 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

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.

• File - Files within a file system.

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