Federated Naming Service

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.

Without FNS, users of the Solaris environment must use different, inconsistent names to refer to objects. For example: you might use the name jsmith@admin to send mail to Joan, the name jsmith@altair 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.

FNS and Application Development

Applications also need naming services and applications in the Solaris environment must often deal with a diversity of name service interfaces. An application might also be exposed to a 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.

FNS simplifies these problems in two ways:

• It provides a single standard interface to the basic naming functions that developers can use for their applications.

• It permits changes or additions to network name services without changing existing applications.

FNS and Composite Names

Some 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 sirius:/usr/jsmith/memo, which has two components: the host name sirius and the file name (path) /usr/jsmith/memo. The mail program uses composite names such as jsmith@altair, which has two components: the user name jsmith and the host name altair.

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.

Without FNS, the user must remember which applications permit composite naming and which do not. For example, the composite name sirius:/tmp/saleslist is accepted by the rcp command, but not by the cp command.

Without FNS, 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. The application passes one name to one interface.

FNS Policy Principles

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 components and how they can be logically composed.

• Names should be intuitive and self-evident. For example, the FNS name /user/wong/service/calendar clearly identifies the calendar service used by Wong. In contrast, the calendar name wong@deneb names the host (deneb) where the calendar service for Wong is being provided. But to other users, 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 wong. Sharing contexts and their names make naming more coherent and simplifies administration.