Sun Microsystems, Inc.
spacerspacer
spacer www.sun.com docs.sun.com |
spacer
black dot
 
 
25.  Federated Naming Service (FNS) FNS and Enterprise Level Naming How FNS Policies Relate to Files-Based Naming  Previous   Contents   Next 
   
 

Target Client Applications of FNS Policies

One goal of the FNS policies is to maintain coherence across the most commonly used tools, including the file system, the DeskSet tools, such as Calendar Manager, Print Tool, File Manager, and Mail Tool, and services that support these tools, such as RPC, email, and print subsystems.


Note - Some of these examples are not currently implemented in the Solaris operating environment. They are listed here to illustrate how FNS can be used.


  • Calendars. Instead of using names of the form username@hostname to access someone's calendar, in most cases you simply supply a site, organization, or user's name. You should also be able to use composite names to name calendars. For example, when federated under FNS, names of the following form are acceptable to calendar manager:

    • bernadette

    • user/bernadette

    • site/pine.bldg-5 (calendar for Pine conference room)

    • org/sales (calendar for the sales organization)

  • Printing. Instead of naming a specific printer by its name, you should be able to name a printer relative to a user, site, or organization. For example:

    • ilych (ilych's default printer)

    • org/sales (an organization's default printer)

    • site/pine.bldg-5 (printer in the Pine conference room)

  • File access. You should be able to use composite names to name file systems and files. The automounter should use FNS to make resolution of composite names possible. For example, you should be able to use a file name like /xfn/user/baruch/fs/.cshrc to reference the .cshrc file for user baruch.

  • RPC. Instead of addressing services by their host name, program, and version numbers, you should be able to name the service using a composite name. For example, you should be able to name an RPC service relative to a user or an organization such as: user/hatori/service/rpc.

  • Mail - Similarly, composite names can be used to name mail destinations. You should be able to use names such as the following:

    • angus

    • user/angus

    • org/mlist (an organization's mailing list)

    • site/pine.bldg-5 (mailbox of the conference room coordinator)

  • Other desktop applications - You should be able to pass composite names to other desktop applications such as spreadsheets, document preparation tools, fax tools, and so on. Some of these applications attach their own namespace to the service namespace, thus becoming part of the FNS federation.

Example Applications: Calendar Service

This is a description of how one application, a calendar service, could be modified to use FNS policies. This example illustrates how FNS composite names might be presented to and accepted from users.

The DeskSet's calendar service is typical of client-server applications. Calendar servers run on some set of machines and maintain the users' calendars. Calendar Manager (cm) runs on the desktop and contacts the appropriate server to obtain the calendars of interest.

The calendar service could benefit from FNS using a simple registry/lookup model as follows:

  • Binding - Upon startup, the server registers the calendars that it manages by binding a reference containing its own ONC+ RPC address (host, program, version) to the composite name for each calendar it manages, such as user/jsmith/service/calendar.

  • Lookup - When using cm, the user specifies another user's calendar simply by entering the user's name (for example, hirokani) or selecting it from a list of names previously entered. Given the user name hirokani, cm composes the composite name user/hirokani/service/calendar and uses this to look up the RPC address that it needs to communicate with the server that manages that calendar.

In the previous example, we used the name "calendar" to denote a calendar binding. The developers of the calendar service should register the name "calendar" with the FNS administrator, much as RPC programs are registered with the RPC administrator. Refer to "Service Name and Reference Registration".


Note - The name "calendar" used here is an example. FNS policy does not specify the names of specific services.


The calendar service could take further advantage of FNS policy by allowing calendars to be associated with sites, organizations, and hosts, while still naming them in a uniform way. For example, by allowing calendars to be associated with a conference room (a site), the service can be used to "multibrowse" the conference room's calendar as well as a set of user calendars to find an available time for a meeting in that room. Similarly, calendars can be associated with organizations for group meetings and hosts for keeping maintenance schedules.

The cm calendar manager could simplify what the user needs to specify by following some simple steps.

  1. cm uses a tool for accepting composite names from the user and constructing the name of the object whose calendar is of interest.

    The object is the name of a user, a site, a host, or an organization. For example, the user might enter the name kuanda and the calendar manager generates the composite name user/kuanda. This tool could be shared among a group of DeskSet applications.

  2. cm uses the XFN interface to compose this name with the suffix /service/calendar to obtain the name of the calendar.

  3. This calendar name is then resolved relative to the process's initial context.

    Continuing with the example, this results in the resolution of the name user/kuanda/service/calendar. Similarly, if the user enters the name of a site, pine.bldg-5, cm generates the name site/pine.bldg-5/service/calendar for resolution.

    Other services such as printing and mail could take advantage of the FNS policies in a similar way.

FNS File System Namespace

Files may be named relative to users, hosts, organizations, and sites in FNS by appending the fs enterprise namespace identifier to the name of the object, and following this with the name of the file. For example, the file draft96 in the sales division's budget directory might be named org/sales/fs/budget/draft96.

The initial context is located under /xfn in the file system's root directory. Thus a user might view the file by typing

% more /xfn/org/sales/fs/budget/draft96

Existing applications can access this directory just as they would any other directory. Applications do not need to be modified in any way or use the XFN API.

 
 
 
  Previous   Contents   Next