Chapter 1 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 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 Solaris Naming Administration Guide 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 SunSoft, 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 describes the XFN programming interface in detail.

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

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

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

Examples of Composite Names

This section shows examples of names that follow FNS policies. The specific choices of organization names, site names, user names, host names, file names, and service names (such as "calendar" and "printer") are illustrative only; these names are not specified by FNS policy.

Composing Names Relative to Organizations

The naming systems to be found under an organization are: user, host, service, fs, and site.

org/csl.parc/site/videoconference.northwing

names a conference room videoconference located in the north wing of the site associated with the organization csl.parc.

org/csl.parc/user/mjones

names a user mjones in the organization csl.parc.

org/csl.parc/host/inmail

names a machine inmail belonging to the organization csl.parc.

org/csl.parc/fs/pub/blue-and-whites/CSL92-124

names a file pub/blue-and-whites/CSL92-124 belonging to the organization csl.parc.

org/csl.parc/service/calendar

names the calendar service for the organization csl.parc. This service might manage the meeting schedules for the organization.

Composing Names Relative to Users

The naming systems associated with users are service and fs.

user/jsmith/service/calendar

names the calendar service of the user jsmith.

user/jsmith/fs/bin/games/riddles

names the file bin/games/riddles under the home directory of the user jsmith.

Composing Names Relative to Hosts

The naming systems associated with hosts are service and fs.

host/mailhop/service/mailbox

names the mailbox service associated with the machine mailhop.

host/mailhop/fs/pub/saf/archives.91

names the directory pub/saf/archives.91 found under the root directory of the file system exported by the machine mailhop.

Composing Names Relative to Sites

The naming systems associated with sites are service and fs.

site/B5.MountainView/service/printer/speedy

names a printer speedy in the B5.MountainView site.

site/B5.MountainView/fs/usr/dist

names a file directory usr/dist available in the B5.MountainView site.

XFN Overview

The following gives an overview of the main concepts in XFN and they are used in defining a federated naming system.

XFN References

An XFN name is bound to a reference, which is the information on how to reach an object. It contains a list of addresses, which identify communication endpoints on how to reach the object. Multiple addresses identify multiple communication endpoints for a single conceptual object or service. For example, a list of addresses might be required because the object is distributed or because the object can be accessed through more than one communication mechanism.

XFN Contexts

An XFN context is an object that exports the XFN base context programming interface. A context contains a list of atomic names bound to references, as shown in Figure 1-5. An atomic name can have zero or more attributes. Contexts are at the heart of the lookup and binding operations, described extensively in Chapter 2, Interfaces for Writing XFN Applications.

Figure 1-5 An XFN Context

XFN Attributes

In addition to references, there can be zero or more attributes associated with each named object, as shown in Figure 1-5. Each attribute has a unique attribute identifier, an attribute syntax, and a set of zero or more distinct attribute values.

XFN defines operations for examining and modifying the values of attributes associated, as well as searching for objects using their associated attributes.

XFN Compound Names

An XFN compound name is a sequence of one or more atomic names. An atomic name in one context object can be bound to a reference to another context object of the same type, called a subcontext. Objects in the subcontext are named using a compound name. Compound names are resolved by looking up each successive atomic name in each successive context.

A familiar analogy for UNIX users is the file naming model, where directories are analogous to contexts, and path names serve as compound names. Furthermore, contexts can be arranged in a "tree" structure, just as directories are, with the compound names forming a hierarchical namespace.

• UNIX example: usr/local/bin. UNIX atomic names are ordered from left to right and are delimited by slash (/) characters. The name usr is bound to a context in which local is bound. The name local is bound to a context in which bin is bound.

• DNS example: sales.Wiz.COM. DNS atomic names are ordered from right to left, and are delimited by dot (.) characters. The domain name COM is bound to a context in which Wiz is bound. Wiz is bound to a context in which sales is bound.

• X.500 example: c=us/o=wiz/ou=sales. An X.500 atomic name contains an attribute type and an attribute value. Atomic names are known as relative distinguished names in X.500. In this string representation, X.500 atomic names are ordered from left to right, and are delimited by slash (/) characters. An attribute type is separated from an attribute value by an equal sign (=) character. Abbreviations are defined for commonly used attribute types (for example, "c" represents country name). The country name US is bound to a context in which wiz is bound. The organization name wiz is bound to a context in which the organizational unit name sales is bound.

Figure 1-6 shows an example of a hierarchical naming system with compound names.

Figure 1-6 Hierarchical Naming System With Compound Names

XFN Composite Names

An XFN composite name is a name that spans multiple naming systems. It consists of an ordered list of zero or more components. Each component is a name from the namespace of a single naming system. Composite name resolution is the process of resolving a name that spans multiple naming systems. Appendix A, XFN Composite Names, and Appendix B, XFN Composite Names Syntax, supply more detail about composite names.

Components are slash-separated (/) and ordered from left to right, according to XFN composite name syntax. For example, the composite name

sales.Wiz.COM/usr/local/bin

has two components, a DNS name (sales.Wiz.COM) and a UNIX path name (usr/local/bin).

Figure 1-7 shows an example of a federated naming system with composite names. The position of the name within a context has no inherent significance in this illustration.

XFN Links

An XFN link is a special form of reference that is bound to an atomic name in a context. Instead of an address, a link contains a composite name. Many naming systems support a native notion of link that can be used within the naming system itself. XFN does not specify whether there is any relationship between such native links and XFN links.

"XFN Links" describes links in detail.

Figure 1-7 Federated Naming System With Composite Names

XFN Initial Context

Every XFN name is interpreted relative to some context, and every XFN naming operation is performed on a context object. The initial context object provides a starting point for the resolution of composite names. The XFN interface provides a function that allows the client to obtain an initial context.

The policies described in Solaris Naming Administration Guide specify a set of names that the client can expect to find in this context and the semantics of their bindings. This provides the initial pathway to other XFN contexts.

API Usage Model

Many clients of the XFN interface are only interested in lookups. Their usage of the interface amounts to:

• Obtaining the initial context

• Looking up one or more names relative to the initial context

After the client obtains a desired reference from the lookup operation, it constructs a client-side representation of the object from the reference. This need not be code within the application layer but can be code inside the service layer. For example, RPC services can provide clients with a means of constructing client-side handles from a composite name for the service or from a reference containing an RPC address for the service. After receiving this handle, the client performs all further operations on the object or service by supplying the handle.

This is the basic model of how the XFN interface is expected to be used. The FNS policies described earlier further encourage a bind/lookup model for how services and clients can rendezvous through the use of the naming service.

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.

Applications use FNS in the following ways:

1. Applications can use FNS through existing interfaces. A significant proportion of FNS use is 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.

2. Applications can 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.

3. 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, in combination with XFN, are examples of naming systems that export the XFN interface.

This book addresses the needs of applications that use the XFN interface. Some examples of these applications are given in the next chapter.

Application Interaction with XFN

The way that client applications interact with XFN to access different naming systems is illustrated in a series of figures. Figure 1-8 shows an application that uses the XFN API and library.

Figure 1-8 Client Application Interaction With XFN

Figure 1-9 shows the details beneath the API. A naming service that is federated is accessed through the XFN client library and a context shared object module. This module translates the XFN calls into naming service-specific calls.

Figure 1-9 Details Beneath XFN API

X.500, DNS, and NIS+ are the naming services that have been federated in the example shown in Figure 1-10.

As resolution of a composite name proceeds, it can cause these different modules to be linked in, depending on the types of contexts referenced in the name.

Figure 1-10 XFN Implementation Examples