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.
Note - In a 64-bit XFN application, the X.500 directory service is not supported.
Figure 1-6shows 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 inSystem Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) 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.