Are you still using databases to try and store hierarchies of data? Storing trees of information in a relational database can often be troublesome. SQL makes it difficult (if not impossible) to store some types of trees of data. Self-referencing foreign keys, recursive triggers, and optimizing queries makes this even harder. Perhaps there is a better solution to store those trees. In this article, I'll explain what Microsoft's new Active Directory Application Mode (ADAM) is, and how it can help you write better code.

ADAM is a stand-alone LDAP server that shares its codebase with Active Directory. ADAM can be deployed onto servers without any relationship to your enterprise's domain model. If you wanted to use Active Directory for application specific information but did not want to deal with the issues of changes affecting your corporate security or IT staff, ADAM may be for you.

I've long espoused the merits of using LDAP information to store hierarchical data instead of databases, but until recently, the methodology of using Active Directory for application data was too confused. Now that ADAM has shipped, I hope I can convince you to look at LDAP for data storage.

There are two chief reasons to store data in an LDAP data:

• Tuned for reading: LDAP stores in general (Active Directory/ADAM specifically), are tuned to handle a large number of reads in a very performant fashion.
• Hierarchical storage: Databases are great for storing relational information, but are not well suited to store data in hierarchies.

LDAP isn't always the answer. Here's a few reasons why LDAP may be the wrong tool for a given job:

• Volatile Data: Since LDAP servers are not tuned for writing, data writes are usually deferred until all reads are satisfied.
• Mission Critical Data: If your data must be a clean read every time (e.g. write and immediately read always equal each other), the lazy writing of data to the LDAP store makes it incompatible.
• No Transaction Support: I am unaware of any transactional LDAP stores. Certainly, ADAM does not support this natively.

But let's get back to those advantages.

ADAM is an important technology because it allows all of the benefits of using Active Directory, without the weight of Active Directory. That is, it doesn't require a Windows Server 2003 to be a domain controller. Because ADAM is installed as a local service, it can act much more like a typical LDAP server.

Schema, in an ADAM instance, is completely isolated. While you can link two instances, in general two different ADAM instances do not need to propagate the same schema. This is a major difference between ADAM and its Active Directory cousin. ADAM has most of Active Directory's features, such as schema management and replication, but it forgoes the usual weight of being a key piece of your domain security system. When you see ADAM, just think of it as a stand-alone LDAP solution. It is nothing more, nothing less.