On the CD in the directory for this chapter you will find a sample program called locatew. The sample shows one way to locate a usable LDAP server in a business environment with a minimal amount of hard-coding or onerous user input (“Enter the IP address of the server to which you wish to connect—in binary”). Only when the program is first run does it expect to find a specific server (a bootstrapping step). The program will always use data it found in the LDAP server during its previous invocation to locate other servers in future invocations (or when a server goes down). While this example is miles away from achieving a man-rating, the general idea is probably enterprise-rated for client systems designed for availability. Such a design might be useful for enterprise applications for roaming salespeople (not coinciden- tally, the case study in Chapter 23, Roaming Users with LDAP, takes advantage of this technique).
The locatew sample program has a few other interesting features that might appeal to you:
Separate GUI and directory worker threads. This is so that the GUI never appears unresponsive when the program is accessing a directory server. This makes the programming somewhat more complicated, but the user will not be annoyed by having to wait, thinking that the program is dead. We used separate threads in this example, but we could also have used the asynchro- nous versions of the LDAP APIs to get a similar effect.
A GUI and a console window. The GUI window is where the real applica- tion would do its work, like looking up products in a catalog. The console window is turned on and off from a menu item in the GUI window. The console is used to receive debugging messages, such as how the directory connection is going. There is also a menu item from the GUI window to get directory connection status, as well as a list of available directory servers. The debug console could be turned on and off with a secret key combination (handy for the people who have to service your application).
No new schema objects. We re-used an existing schema object in the Win- dows 2000 Active Directory meant for service publication (which is exactly what we are doing—publishing the location of directory servers).
Figure 5.3 shows the main GUI window of the locatew sample and the menu selec- tions for retrieving directory status and available directory servers. Figure 5.4 shows the dialog that pops up when the user wants to see the available directory servers. Figure 5.5 shows the directory connection status dialog.
When locatew runs for the very first time, it attempts to bootstrap itself by connect- ing to a well-known server. If it is successful, it reads the locations of all other known servers from a published list and stores the list locally in a cache (in the Windows registry). If it is unsuccessful, it asks the user to specify another directory server (as seen in Figure 5.6).
Assuming locatew bootstraps its local cache of directory server locations, either by connecting the well-known server or by having the user specify a server, subsequent Figure E.3 Locatew main window, about to bring up connection status dialog
invocations will work with the cache. The cache is a list of servers that advertised themselves. When locatew starts for all but the very first time, it tries to connect with the last successfully contacted server; if that fails the user is asked to select from the cached list, as shown in Figure 5.7. For good measure, the debug console is shown in Figure 5.8.
What is not covered in this example is how the locations of the directory servers were populated into a directory and kept in synchronization across the many directory servers that might be in the example organization. This cross-directory synchroniza- tion of directory data is not trivial and is covered in Chapter 20.
While an executable can be found on the CD along with all of the files for the project, it is meant to run on Windows 2000. It will not run on a system unless that system has the proper directory access client libraries installed.
Figure E.5 Directory connection status dialog
Figure E.7 Cached list of servers to choose from
Summary
We defined four usage classes of software in this chapter: man-rated, enterprise- rated, good-enough, and don’t-care. Each usage class is typically associated with certain cost parameters and requires different characteristics to be present in appli- cations. In a perfect world all software would be man-rated and free; but in the real world monetary issues get in the way (either the cost of development or the lack of revenue). We enumerated ways in which directory technology can help attack cost issues for the different usage classes of software.
What we described is a classic engineering and business problem: how to satisfy the requirements, within a certain cost envelope, within a certain time envelope, while maximizing revenue and minimizing cost. A directory service can be leveraged by software in many usage categories to speed development, lower cost, and increase revenue, because someone else wrote and tested the code to store and search many kinds of distributed data. Imagine if you had to write the operating system to get your application to run. In the future, we’ll be able to say, “Imagine you had to write the directory to get your enterprise application to run.”
67
THE OPERATING SYSTEM
AND
THE DIRECTORY
"The real world is a special case."
—ANONYMOUS
directory service must be available to various usage categories of applications, as discussed in Chapter 5. The role of an operating system may constrain what usage it can support. If an operating system is less trusted, it cannot support more stringent usage unless the provider of directory services is sufficiently ingenious. Sur- prisingly, there are techniques for making a service more robust than its underlying operating system. Here, we look at some operating system and robustness issues.