Under the Hood: The Database Holding Information

---

After a whole chapter speaking about protocols, communication standards, servers, and clients, you might be wondering where the data is finally held.

As stated previously, LDAP is a standard for communication protocols between server and client. As such, it does not define how or where the data should be held. Indeed, the choice of where the data goes is independent of the implementation. In any case, some kind of repository working as a back end is needed to store the data. The repository can be implemented in any number of ways, but we will limit our brief discussion to two examples: Netscape and OpenLDAP. Both Netscape and OpenLDAP are based on the University of Michigan implementation. Netscape uses a lightweight database management (LDBM) system. LDBM is a so-called embedded database. This means that you have a subset of data storage and access methods that are available with a full fledged RDBMS. Like LDAP, an embedded database avoids all unneeded resource-consuming activities. OpenLDAP is very interesting inasmuch as it offers a big choice of back ends. This includes, first of all, various embedded databases (LDBM, for example, like Netscape). It also allows you to write your own back end. OpenLDAP has a Perl back end that lets you write the real back end using the Perl programming language and a shell back end that lets you write the back end using the standard UNIX shell. But this is not all. You can also use a back end that accesses another LDAP server; in other words, you have an LDAP proxy server. Last but not least, OpenLDAP also has an SQL back end. This back end allows you to use an RDBMS such as the one from Oracle. So you combine LDAP with a RDBMS. Messaging Direct offers an interesting white paper ^[6] that discusses this. At this point, you might reasonably ask: What is the difference between LDAP and an RDBMS? An RDBMS and a directory server address two different purposes. The following list itemizes the differences:

• The directory server does not know about transactions. A transaction is an all-or-nothing process. The purpose of a transaction is to guarantee data consistency. For example, if you transfer money from one bank account to another, you must be sure not to add the money to the receiving account and forget to delete this amount from the paying account. An RDBMS offers transactional support. LDAP does not guarantee such data integrity.

• The directory server does not readily support complicated joins between different tables.

• The directory server does not know about report-building utilities.

• The directory server — in contrast to an RDBMS — does provide a complicated replication mechanism. It also supports a multimaster model in addition to the master-slave replication model. (The replication mechanism is not yet a standard at the time of this writing. Efforts are under way to create a standard.)

• Directories are optimized for reading, not for updates. An application updating hundreds of tables per minute would not be a good candidate for directories. A better choice would be an application making thousands of queries per minute.

• Directories are organized in an object-oriented, hierarchical way. This information-storage method helps to mirror exact replicates of objects into the directory.

• Directories are delivered with ready-to-use schemas, many of which are even standardized. An RDBMS schema must he defined before use.

• Directories rely on open standards, which guarantees the interoperation of different applications on different platforms.

• Since directories are a network protocol, they are natively network-enabled. This means that the user has access to functions such as data distribution and data replication implemented inside the software.

• Directories offer a lightweight method of connecting to a repository, grabbing the data, and closing the connection. An RDBMS takes much more time to establish a connection. Once opened, however, the RDBMS system offers a wider array of services. As always, system administrators must balance the cost of a higher overhead with the required services.

^[6]MessagingDirect Limited, Combining Directories, and Relational Databases in the Enterprise, white paper, Document IC-6055-V2.0, Edmonton, Canada, 2000; available online at http://www.messagingdirect.com.

---