BOSTON (05/15/2000) - The driving force in making directories a relevant term on our networks today is LDAP (Lightweight Directory Access Protocol). The best thing LDAP has to offer is simplicity. Directory servers - originally applications laden with complexity, jargon and confusion - have been simplified to the point that getting a directory project up and running is no longer a Herculean effort.
Still, finding your place in the world of LDAP directory servers can be confusing. A plethora of products are available, but they offer widely different characteristics. Before starting any directory-enabled project, you must first understand what LDAP is and is not, how your directory will mesh with your existing databases and what your application 's performance and sizing characteristics are.
LDAP is a direct descendent of X.500, a set of directory recommendations published by the International Telecommunication Union. This older specification was designed by telephone companies to generate enormous, complex and worldwide webs of directory servers linked together. Accordingly, the X.500 recommendations were enormous and complex. LDAP was born when a group of Internet developers looked at X.500 and asked, "How can we simplify X.500 so mere mortals can use it?"
LDAP and X.500 have a strong relationship. LDAP is designed as an access method for X.500 directories. It doesn 't require that the directory be a X.500 directory, but it uses X.500 terms and definitions when describing the directory. This is especially clear when talking about the schema, which defines the structure of objects in the directory database. The LDAP/X.500 schema can be overwhelming when you first see it, but many LDAP servers make schema modifications a simple task. For example, with Oracle 's Internet Directory, adding a field to an object is simply a matter of defining the field name, type and length, linking it to the object that contains it and clicking a few boxes to select how you want the field indexed.
The "lightweight" in LDAP reflects the basic design goal of the entire project: build a directory service that has enough power to solve basic problems but doesn't have so much technology packed into it that no one wants or can afford to use it. LDAP is now a standard for directory information access, and is being used as an underpinning in a variety of products such as authentication systems, mail systems and e-commerce applications. To date, more than 60 LDAP servers have been released on the market. Approximately 90% of these products are stand-alone LDAP directory servers, while the remaining 10% are shipped as components of other applications.
The "DAP" part of LDAP spells out the few restrictions that LDAP puts on a software developer. In the X.500 directories, DAP is the protocol used to query the directory. LDAP, then, is just a lightweight version of DAP, which is only one part of the bigger directory service picture. LDAP only concerns itself with how applications - meaning everything from a browser to a complex enterprise resource planning system - talk to directories. All other aspects of building, managing and using a directory are left to the developer 's imagination.
Directory and database differences
One of the confusing things about LDAP is that it looks like another kind of database. If you 've had experience with SQL or any relational database, LDAP looks like a way to get at a simple kind of database.
First impressions are correct. You can use LDAP to retrieve data from a standard database, as Oracle Corp. and Computer Associates International Inc. have demonstrated with their LDAP directories, which have been built on top of their relational databases.
LDAP server vendors, such as Netscape Communications Corp. and Innosoft International Inc., don 't like this comparison. For one thing, they don 't want to compete with established database vendors. Selling database software against Oracle is only slightly easier than selling operating system software against Microsoft Corp. However, they also want to emphasize the differences between their directories and a traditional relational database. LDAP sharply defines the operations you can do on the directory.
You can do five things to an LDAP directory. A client can connect or bind to it, search it, modify it, add to it and delete from it. All other features of a relational database (transactions, multitable queries, views and joins) have no counterparts in an LDAP realm. An LDAP server offers none of this power, at least not via the LDAP interface. Nevertheless, the trade-off comes with a big payoff. With an LDAP store, you get greater speed, lower cost, a simpler data model and easier management and implementation.
LDAP defines an access method to a database, but it also defines a database implementation philosophy. Technically, there is no such thing as an LDAP directory. However, LDAP so strongly colors the database design, that most people call the directory you talk to with LDAP an "LDAP directory." A directory optimized for LDAP is easier to build than a general-purpose database. For example, there is no concept of transactions or rollbacks in LDAP, so all the complexity of locking and journaling you see in relational databases and all the overhead that complexity brings is gone in an LDAP environment.
If there were a traditional database that mapped well to an LDAP directory, it wouldn 't be the modern relational databases, but a hierarchical database such as IBM Corp.'s Information Management System. This is because LDAP directories are arranged as hierarchical trees of information, designed to mimic the hierarchy of the organizations they describe: locations such as country, city and state, organizational units, departments, and so on down to people, conference rooms and printers.
The number of entries you can put in the directory and the rate at which you can query it segments the LDAP directory market. If you 're running a customized Web portal site and you have 10 million members, and you get one million hits per day, you probably have an "extranet" or "e-commerce" LDAP server. With this type of product, you have the capability to do a particular type of query (exact match on member ID, for example), handle a lot of reads and have a huge database that doesn 't change much from day to day.
On the other hand, if you 're running a mail backbone for a Fortune 500 company, you probably get one-tenth of the queries of an extranet LDAP directory, but you may get a mix of exact match, fuzzy or wildcard searches.
Plus you have a lot fewer entries in your database - 50,000 employees would be a reasonable number for this class (an enterprise directory) of LDAP directory.
The distinction is somewhat arbitrary. Vendors such as Microsoft and Novell Inc., which you would think fit better into the enterprise model of directories, won 't hear of it. Both firms are ready and willing to fit a few million entries (in Novell 's case, one billion entries) into their directories and want to go up against the best of them.
However, the reality is that no directory can be optimized for all applications. IPlanet (the new Netscape), which wants to be the premier extranet/e-commerce directory vendor, can bulk-load a one-million-entry directory in less than an hour. This is a common operation in LDAP directories, where it is often simpler to reload the directory from scratch than to keep it updated with changes throughout the day. Microsoft 's Active Directory isn 't designed for that modus operandi and would have a hard time bulk-loading the same database in 12 hours.
Enterprise directories tend to be tapped into for a broader range of services than the extranet variety, with several kinds of applications storing and retrieving different kinds of data in the directory. Enterprise directories are often tied to network or system management, and vendors such as Novell and Microsoft store security and configuration information in the directory making the actual operating system itself a big client of the directory.
Your choice of directories may be limited by your application. Windows 2000, which ships with Active Directory as an integral part, is not going to play well with other directory products. Novell has made a bold push to swap Active Directory for its Novell Directory Services (NDS) eDirectory, which also runs on Windows 2000, but playing that game in Microsoft 's backyard is a dangerous one with the potential for incompatibility high.
Similarly, many directory-enabled applications, such as authentication servers and mail gateways, use LDAP but are tuned for a particular API. As we discovered in our benchmark testing, there are wide differences in how products support standard LDAP calls. If you don 't have access to the source code for your application for a subtle tweak here or there, you may not be able to mix and match as much as you want.
Any directory-enabled project needs a lot of design before product selection can begin. There are a few good books on LDAP available. However, we found Netscape 's documentation accompanying its LDAP server to be an outstanding introduction to the design and implementation of LDAP-based applications of all type. Even if Netscape 's product isn 't for you, the documentation kit is worth buying at an early stage to help with application design.
Once you 've identified core directory attributes - including application profile, size and performance requirements, query mix and distribution features - you will find it easy to short list products and identify which LDAP directory server is best for you.