At a previous job, I noticed that our poor receptionist maintained an Excel worksheet containing a list of all the employees’ phone extensions, e-mail addresses, street addresses, and so on. Every time a new employee was hired or someone moved to a different office, she would jot down the information. Then, she would periodically update the worksheet and give all of the employees copies so that we could contact each other without going through the switchboard.
One of my “other duties as assigned” was to make this information available on the company intranet. Before I started to design my Access database, I realized that I would have to build a system to issue lookups, changes, and entries. A senior engineer suggested that I look into Lightweight Directory Access Protocol (LDAP) because it would be a perfect way to maintain this information. It comes with all of the tools to read, write, update, and delete.
LDAP serves as both an information model and as a protocol for accessing and changing directory information. As you can tell by its name, LDAP is a lighter version of a Directory Access Protocol (DAP) directory, also known as X.500. DAP is the “Directory Access Protocol defined by the International Organization for Standardization (ISO) and the International Telecommunication Union (ITU/T) as part of the standards for directory protocols.”
DAP can access a directory server via Internet protocols, as well as many others, such as Systems Network Architecture (SNA) and Internetwork Packet Exchange (IPX). The DAP standard also defines an access protocol and a directory structure. The biggest problem that system architects faced implementing DAP was that it was too heavy, meaning that the protocol was implemented using a technology that was available across many networking protocols that just didn’t fit well on the typical desktop available at the time. Most of these clients used the seven-layer Open Systems Interconnection (OSI) model and therefore took a tremendous amount of processing power to accomplish relatively simple tasks.
Another issue architects faced was that the original DAP standard was seen as being complex and hard to implement. A lighter protocol was needed, one that didn't have to consume vast amounts of desktop resources, didn't require extra software to run, and most of all, would be easy to implement. LDAP surfaced in the 1990s as an answer to this need. It allowed access to these directories via Internet protocols (TCP/IP), enabling “out of the box” operation for most typical desktops.
How does it work?
LDAP is optimized for reading data, not for reading and writing. It isn't a “traditional” relational database in the sense that you have tables with rows of data, foreign keys, relationships, or transactions. Databases possess these items because they are essential to provide for data integrity, normalization, and performance. Databases store data and provide mechanisms (SQL and DML) to retrieve, modify, and delete data while providing integrity.
On the other hand, although LDAP can store, retrieve, modify, and delete data, it is best at reading data. Think of LDAP like the Yellow Pages. In the Yellow Pages, telephone numbers are organized under various categories, and you drill down for name, address, and phone number after looking under a general category like “Plumber” or “Automobile.” (See Figure A.) The Yellow Pages analogy can be taken a step further. You may make a correction to a listed phone number, but it is not done very often.
|LDAP is structured like the Yellow Pages.|
This informational structure can be convenient for a company directory. Objects defined in the LDAP directory can represent any number of things, such as printers, users, desktops, or laptops. Figure B shows how this might be incorporated in a business scenario.
|Applying the LDAP structure to business|
This directory structure could be used to search for individuals, to inventory equipment, or to map corporate intranets. In terms of software development, LDAP is incorporated into many applications that can take advantage of a datastore optimized for reading. Here's a list of applications that use LDAP in one fashion or another:
- Microsoft NetMeeting—ILS Server User Directory for user lookups
- Microsoft Exchange—User lookups and storage
- Microsoft Active Directory—User lookups, network object storage/lookups
- Oracle Internet Directory—User lookups, network object lookups, user authentication
- Oracle Application Server—User lookups, authentication
When I created our company directory, I used a Perl API that came with our LDAP server to create reads, writes, and deletes. These APIs contain convenience methods that provide for common tasks like searching, adding, deleting, and modifying the LDAP server. There are also free versions available for Perl, Java, and C.
Plenty of support
When I approached my manager about implementing LDAP, I received the classic response: “Will we be a guinea pig?” Some people don’t realize that LDAP is widely supported by many major software companies, including Novell, Sun, Netscape, IBM, and Oracle.
One of the more widely used implementations is the iPlanet Directory Server. (iPlanet is a partnership between Netscape and Sun Microsystems that provides a full enterprise solution incorporating many facets of network applications.) IBM supports LDAP in its Domino product. Novell supports its implementation of LDAP with the eDirectory product. With this kind of solid industry backing, we knew our shop wouldn't be on the fringe, and neither will yours.
Have you used LDAP?
For what applications have you used LDAP? Are there other approaches that are better? Send us an e-mail with your experiences and suggestions or post a comment below.