What Is FNS?

FNS provides a method for federating multiple name services under a single, simple uniform interface for the basic naming operations. The service supports resolution of composite names--names that span multiple name 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 environment, the FNS implementation consists of a set of enterprise-level name services with specific policies and conventions for naming organizations, users, hosts, sites, and services as well as support for global name services such as DNS and X.500.

What Is XFN?

XFN is X/Open Federated Naming. XFN is a standard actively supported by organizations such as SunSoft, Inc., IBM, Hewlett-Packard, DEC, Siemens, and OSF. FNS, the Solaris implementation, is compliant with the X/Open Preliminary Specification for Federated Naming (July 1994). 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. The X/Open Co. Ltd. is an international standards organization committed to defining computing standards that are endorsed and adhered to by the major computer vendors.

---

Note - In this manual it is important to distinguish between XFN and FNS. For example, the FNS policies include some extensions to XFN policies, and these are explicitly defined with notes. Objects belonging to the XFN programming interface are designated as XFN objects in order to avoid confusion with other programming interfaces.

---

Why FNS?

FNS is useful for the following reasons:

• A single uniform naming interface is provided to clients for accessing different name services. As a consequence, the addition of new name services does not require changes to applications or to existing member name services.
• Names can be composed in a uniform way, and the resulting composite names can have any number of components.
• Coherent naming is encouraged through the use of shared contexts and shared names.

The following subsections expand on these reasons.

Uniform Naming Interface

Within the Solaris environment, name services are integrated into other services such as the file system, the network information service, the mail system, and the calendar service. For example, the file system includes a

naming system for files and directories; NIS+ service combines a naming system with a specialized information service; a spreadsheet application names cells and macros. An application in the Solaris environment must often deal with this diversity of name service interfaces. In addition, the application may be exposed to a great variety of often incompatible naming systems external to the Solaris environment. Local- and wide-area networks connect a heterogeneous array of hardware and operating systems, increasing the variety of potential interfaces. Not only do these naming interfaces differ widely, but the essential naming operations are often obscure.

A standard interface that provides the basic naming functions greatly simplifies the naming aspect of applications for developers because now a single interface to name different types of objects can be used. Changes to the underlying name service and adding new name services can be applied without requiring changes to the applications.

Uniform Means of Composing Names

Historically, a small percentage of applications use composite names to access objects in the Solaris environment. The commands mail and rcp are examples of such applications. rcp uses composite names such as sylvan:/usr/jsmith/memo, which has two components: the host name sylvan and the file name (path) /usr/jsmith/memo.The mail program uses composite names such as jsmith@hal, which has two components: the user name jsmith and the host name hal. Each application defines its own composition rule for names, parses the composite names, and resolves composite names. Composition rules often differ from one application to another.

The user must remember which applications permit composite naming and which do not. For example, the composite name sylvan:/tmp/foo is accepted by the rcp command, but not by the cp command. The user must also remember the different composition rules used among different applications. Applications that support composite names on their own can use only a small and specific set of naming systems, and must be changed whenever a new type of naming system is added.

Incorporating a uniform policy for composite naming into the computing platform permits any application to support composite names in a uniform way.

Figure 1-2 shows an example of a federated naming system consisting of two component naming systems: a host naming system and a file naming system. When the name jurassic /usr/games/bin/pirates.exe is passed to the federated naming system, the host part of the name, jurassic, is resolved by the host naming system, while the file part of the name, /usr/games/bin/pirates.exe, is resolved by the file naming system. The important point to note is that the application passes one name to one interface.

Coherence in Naming

At present, users of the Solaris environment must use different, inconsistent names to refer to objects. To expand on an earlier example: you may use the name jsmith@admin to send mail to Joan, the name jsmith@hal to access her calendar, and the name /home/jsmith/.cshrc to reach a file in her home directory. This disparity makes it hard for users to formulate names and hard for applications to automatically generate names on behalf of users. FNS policies define a coherent way for naming these objects.

The following principles were used to arrive at FNS policies:

• When it is natural to name other objects relative to a certain object, that object should provide a naming context. For example, because it is natural to want to name various things relative to a user, a user object should be a naming context.

• It should be possible to compose names using common components. This reduces the number of names that users need to remember and makes it easier for applications and users to construct names based on their knowledge of common constituents and how they can be logically composed.
• Names should be intuitive and self-evident. For example, the calendar name jsmith@hal names the host where the calendar service is being provided. To the user, there is no obvious connection between the user's calendar and a host. The host name is extraneous and difficult to discover and remember.
• Never use two contexts when one context will do. In the example above, we would like to name a mail address, a calendar, and a file's directory relative to the user jsmith. Sharing contexts and their names make naming more coherent and simplifies administration.

FNS in the Solaris Environment

In the Solaris environment, the FNS implementation currently consists of a set of enterprise-level name services implemented on top of NIS+, global-level naming systems using DNS and X.500, file naming, and support for printer naming. FNS will become increasingly more visible to the Solaris user as more applications and systems use FNS.

FNS and NIS+

NIS+ is the enterprise-wide information service in the Solaris environment. It is an information-retrieval system for well-known UNIX databases, such as the password tables, host tables, and mail aliases tables. It also supports Solaris-specific databases such as the automount maps and the credentials tables. It partitions an enterprise into organizational units that are arranged into a tree and assigned hierarchical domain names.

FNS federates NIS+ in order to support enterprise-level naming policies in the Solaris environment. To do this, FNS provides the XFN interface for performing naming operations on organization, site, user, and host objects. It implements these operations using the NIS+ programming interface for accessing NIS+ directories and tables. It stores bindings for enterprise-level objects in NIS+ and uses them in conjunction with the standard NIS+ tables for passwords and hosts.

FNS and DNS

The Internet Domain Name System (DNS) is a hierarchical collection of name servers that provide the Internet community with host and domain name resolution. FNS uses DNS to name entities globally. Names can be constructed for any enterprise that is accessible on the Internet; consequently, names can also be constructed for objects exported by these enterprises. For more information about FNS and DNS, see "Federating DNS" on page 62.

FNS and X.500

X.500 is a global directory service. Its components cooperate to manage information about objects in a worldwide scope. Such objects include countries, organizations, people, and machines. FNS federates X.500 in order to enable global access to enterprise name services. For more information about FNS and X.500, see "Federating X.500" on page 63.

FNS-based File Naming

FNS-based file naming integrates FNS naming into the Solaris file service. FNS-based file naming enables files to be named relative to users, hosts, sites, and organizations, using the FNS policies shared with other non-file applications. FNS-based file naming gives clients a common view of the global and enterprise-wide file namespaces. Solaris applications that access the file system will, without modification, have access to the file namespaces supported by FNS.

FNS-based Printer Naming

FNS-based printer naming provides the basic naming support for the unbundled SunSoft Print Client (SSPC). FNS-based printer naming enables printers to be named relative to users, hosts, sites, and organizations, using the FNS policies shared with other non-printing-related applications. FNS-based printer naming gives clients a common view of the global and enterprise-wide printer namespaces and allows centralized administration of the printer namespaces.

FNS and Applications

Applications that are aware of FNS can expect the namespace to be arranged according to the FNS policies, and applications that bind names in the FNS namespace are expected to follow these policies.

There are three ways for applications to use FNS:

• Applications could be direct clients of the XFN interface and policies. Application-level utilities such as the file system, the printing service, and the desktop tools (calendar manager, file manager) are examples of clients that use the XFN interface directly.
• Applications can use FNS through existing interfaces. A significant proportion of FNS use will be through existing application programming interfaces. For example, consider a UNIX application that obtains a file name that it later supplies to the UNIX open() function. With FNS support for resolution of file names, the application need not be aware that the strings it deals with are composite names rather than the traditional local path names. Many applications can thereby support the use of composite names without modification.
• Systems can export the XFN interface. Naming systems, such as DNS and X.500, and naming systems embedded in other services, like the file system and printing service, are examples of naming systems that export the XFN interface.