Understanding and Deploying LDAP Directory Services > 1. Directory Services Overview > What a Directory Is Not |
What a Directory Is NotIn our experience, people sometimes have one of two extreme reactions upon learning about the wonders of directories. One reaction is negative: "What good is this directory really going to do? Why can't I just use X to fill that same need? I don't see how this directory is going to be as reliable and perform as well as you say, and I am hesitant to make my application depend on it!" This reaction can usually be overcome by additional education, helping the skeptic see a directory in action, and better explaining all the great things a directory can do for the person. The other reaction is equally misguided, but can be harder to overcome: "This directory is great! I bet there's nothing it can't do. I can now use the directory instead of my file system, Web server, FTP server, and a host of other things. Finally, a handy, all-in-one tool that chops, slices, dices, makes homemade desserts, but best of all, it cleans itself!" The enthusiasm of this reaction is to be admired, but there is danger here, too. There is an old saying that states that if the only tool you have is a hammer , every problem begins to look like a nail. Needless to say, not all problems are nails , and trying to treat them as such tends to lead to poor carpentry. A directory is no different ”like any other technology, it is best suited to solving one set of problems. A directory can be usefully applied to many other problems as well, though with somewhat less satisfaction. A directory can be abused by trying to make it solve problems that it was not intended to solve. In this section we examine this area more closely, explaining some of the many applications for which directories are not well suited. We will explain why directories are different from the following network services that may look similar on the surface:
We will explain how your directory can complement all these services and why each one fills a valuable niche in your computing infrastructure. We will conclude this section with a summary of when to use a directory to store information and when to use something else. Database ComparisonIn the previous section we described what a directory is, and we spent quite a bit of time comparing directories to databases. We will not repeat that comparison here, but we will highlight a few important points. First, recall that directories are typically read-focused rather than write-focused. So if your application is writing large volumes of data, say for recording logs or merchandise transactions, you should choose a database over a directory. Second, directories support a relatively simple transaction model. Directory transactions involve only a single operation and a single directory entry. Databases, on the other hand, are designed to handle large and diverse transactions, spanning multiple data items and many operations. If your application requires this kind of heavy-duty transaction support, again a database is a better answer than a directory. On the other hand, if you have an application that does not have these requirements but instead wants to read and occasionally write information to a network-accessible database in simple transactions, a directory server may well be a good, cost-effective , much simpler choice than using something like an Oracle database. File System ComparisonA directory makes a poor file system. Files have characteristics that are different from directory information. Files are often very large, containing many megabytes or even gigabytes of information, whereas directories are optimized for storing and retrieving relatively small pieces of information. Although there is often no restriction on the size of a directory entry or attribute, the question is one of design center. Some files are written far more often than they are read, such as log files and files used to hold a database. Directories, as you'll recall, are optimized for read over write. Some files, of course, are read far more often than they are written. Application binaries are a good example of files in this category, but the size of these files is often larger than should be stored in a directory. Applications often access files in chunks , especially if the file is large. File systems support calls ”such as seek() , and read() and write() ”can be used to write only a portion of a larger file for this very purpose. Directories do not provide support for this kind of random access. Instead, a directory entry is split up into attributes. You can retrieve attributes separately, but you usually have to retrieve all of any attribute you ask for. There is no way to retrieve only part of a value, starting at some byte offset. File systems, on the other hand, are not good at storing attribute-based information. They do not typically support any kind of searching capability like directories do. Web ComparisonSince the World Wide Web burst onto the computing scene a few years ago, Web servers have become ubiquitous. Chances are good that your organization, depending on its size, runs anywhere from one to several hundred. Web servers have certain similarities to file systems. They are made to serve clients accessing documents or files that can vary greatly in size. Although Web server documents usually share the typical read-many-write-few characteristic of directory information, directories are not well suited to the task of delivering to clients multimegabyte JPEG images or Java applications. Web servers also often serve as a springboard to a development platform for Web applications. These platforms range from simple CGI (common gateway interface) to more-complex platforms, such as the one found in the Netscape Application Server. Directories typically do not provide this kind of flexibility in application development, even when they do provide directory application development platform services, such as those provided by the Netscape Directory Server. Directories are optimized for providing sophisticated searching capabilities of the data they hold. Web servers can be used to develop similar search applications, but such applications are not standards based. Web servers are tuned to providing GUI-style interfaces on applications; they are not tuned to providing generic application access to directory data. If you have a specific database of information you want to make available to users, a Web server might be a good choice. If you have information you want to make available to a wide variety of applications, a directory server is a better choice. FTP ComparisonAn argument similar to the previous one for Web servers applies to File Transfer Protocol (FTP) servers. One could argue that the days of FTP servers are numbered now that Web servers have arrived, but they are hardly threatened by the arrival of directory services. Again, the main differentiating factor is the size of the data and the type of client that needs access to it. Another important point is that FTP is a very simple protocol, tuned to do one thing and do it well. If all you want to do is create a means to transfer files from one place to another, the extra directory infrastructure needed to perform replication, searching, updating, and so on is overkill. On the other hand, if your application involves more than simple retrieval and storage of information, a directory is a more appropriate choice. Unlike directories, FTP provides no capability for search, no attribute-based information model, and no incremental update capability. DNS ComparisonDNS, the Internet's Domain Name System, translates host names, such as home.netscape.com, into IP addresses. Host names are good for users wanting to remember how to connect to their favorite Internet service. IP addresses are required by the networking infrastructure underlying the Internet that is responsible for actually making the user 's connection happen. The DNS and a typical directory like LDAP have certain similarities, such as providing access to a hierarchical distributed database. But there are some important differences that set the two apart. DNS is highly optimized for its main purpose; most directories are meant to be more general purpose. The DNS has a specialized, fixed set of schemas; directories allow schemas to be extended. DNS does not allow updates of its information; directories do. DNS can be accessed over the UDP connectionless transport; directories are usually connection-based. Note Some recent work on dynamic DNS by the Internet Engineering Task Force (IETF) is aimed at providing update capabilities. Proposed IETF work on connectionless LDAP is aimed at providing LDAP access over UDP. These efforts and others may bring DNS and LDAP closer together. But for now, the best argument for not trying to replace the DNS with LDAP is that the DNS seems to be working just fine. If it's not broken, don't fix it! The Complementary DirectoryThere are certain similarities between directories and many of the services just listed. Directories tend to complement most of these services. We will now take a moment to explore this notion of a complementary directory, what it means, and how it can create synergy among all the services in your enterprise. A good example of the complementary directory is how it relates to a Web server. Here the directory has a number of important supporting roles to play. First, the directory can serve as an authentication database. When clients authenticate to the Web server, their credentials are checked against the directory. When the Web server needs to make an access control decision, the directory can again be consulted to determine group membership and other information pertinent to the decision. The value of the directory in this role is especially apparent when you consider an environment that is running many Web servers, all of which need access to the same authentication database. By sharing a directory, the Web servers reduce the user management problem to a manageable level. Other services can benefit from this type of use as well. Second, the directory can serve as a network-accessible storage device for information about configuration, access control, user preferences and profiles, and other things. The value of the directory in this role is twofold:
As a third example of its complementary nature, the directory can be used to help organize and access information contained in the Web server itself. Today, Web search engines exist to catalog and organize Web-based content. But as anyone who has spent much time using these services can attest, you often spend more time wading through irrelevant matches to your query than reading the actual information desired. The problem is simply that Web content lacks structure and, therefore, is hard to organize and search in an automated way. With the advent of XML (Extensible Markup Language), this lack of structure is beginning to change. This is where directories come in. Directories are great at organizing and providing subsequent access to information. Imagine today's Web search engines driven by directories: Using the directory query language and typed information structure to more accurately specify the information you are looking for, the directory could return a much more focused set of results. Keep in mind that in this scenario the content itself is still stored in a Web server and that free-text searches would still be conducted as they are today. The directory's value is to provide some structure on top of this arrangement and also provide a precise, yet flexible, query mechanism. Another good example of a directory complementing existing services is found in examining file systems and FTP servers. In this case a directory can be used not to hold the contents of files, but rather to hold meta-information about those files, their locations, who owns them, and other things that might be useful in locating them. Most importantly, the directory can hold the information that a file system or FTP client needs to access files contained in that service. An FTP server could also use a directory server for authentication purposes. This idea of using directories to organize and search for information that you really want to access is a common theme. Directories often don't hold the content for which you are searching, but they can hold the location of that information along with other attributes that can help you find what you are looking for. The dividing line between what should be held in a directory and what should be held elsewhere is not always clear. In fact, sometimes it can be quite difficult to tell. General guidelines are that the more information there is, the less likely it should be put in a directory. The more frequently the information changes, the less likely it should be maintained in a directory. The less structured a piece of information is, the less benefit you will likely derive from placing it in a directory. However, the more often a piece of information is shared, the more benefit you will likely derive from placing it in a directory.
|
Index terms contained in this sectionapplicationsunsuited for directories 2nd 3rd 4th 5th 6th 7th 8th comparing directories and databases directories and DNS (Domain Name System) 2nd directories and file systems 2nd directories and FTP (File Transfer Protocol) directories and WWW (World Wide Web) 2nd complementary directories 2nd and FTP (File Transfer Protocol) and Web servers 2nd 3rd databases directories comparing directories applications not suited for 2nd 3rd 4th 5th 6th 7th 8th complementary 2nd complementary directories and FTP (File Transfer Protocol) complementary directories and Web servers 2nd 3rd databases comparing 2nd DNS (Domain Name System) comparing 2nd file systems comparing 2nd FTP (File Transfer Protocol) comparing WWW (World Wide Web) comparing DNS (Domain Name System) directories comparing 2nd IETF (Internet Engineering Task Force) Domain Name System, see DNS file systems directories comparing 2nd File Transfer Protocol, see FTP FTP (File Transfer Protocol) and directories (complementary) directories comparing IETF (Internet Engineering Task Force) Internet Engineering Task Force, see IETF languages markup XML (Extensible Markup Language) markup languages:XML (Extensible Markup Language) protocols FTP (File Transfer Protocol) comparing with directories servers and complementary directories 2nd 3rd services and complementary directories 2nd Web servers and directories (complementary) 2nd 3rd World Wide Web, see WWW WWW (World Wide Web) directories comparing 2nd XML (Extensible Markup Language) |
2002, O'Reilly & Associates, Inc. |