About a decade ago, different mail systems stored messages in different
ways, which was a big problem. To simplify the matter, the world settled on a
standard format (X.400) for mail messages. This standard wasn't the mail format
for any particular mail system, just an intermediate format that everyone agreed
on. In theory, with X.400, you don't need to write gateways between cc:Mail and
MSMail, PROFS, All-in-1, CEO, Simple Mail Transfer Protocol (SMTP), and so on.
You write just one gateway from cc:Mail to X.400. Similarly, you get a gateway
from MSMail to X.400, and mail can go from Acme to Apex as cc:Mail to X.400 to
MSMail. Terrific. We've solved the "How do I send mail from a cc:Mail user
to an MSMail user in a format MSMail can understand" problem. But that's
not the whole mail interface problem because the user databases that MSMail and
cc:Mail use present another point of incompatibility.
An Acme employee can fire up cc:Mail and create a new message, and cc:Mail
will present the user with a list of the users that cc:Mail knows. At the end of
that list, a bogus user such as X400GTW will appear. cc:Mail is conveniently
showing the Acme employee its user database, but no MSMail users appear on the
list. To send mail to an Apex user, the Acme employee must send mail to X400GTW.
Then cc:Mail will prompt the employee for the name of the person on the other
side of the gateway that she wants to communicate with. Bummer. Now she has to
call the person she's mailing to and ask him his email name. The same kind of
thing happens to an Apex user trying to use MSMail to email a cc:Mail person.
The problem of connecting mail systems is, then, twofold. First, different
mail systems use different message formats; a standard intermediate format
called X.400 solves this part of the problem. Second, different mail systems use
different formats for querying their databases of recognized users. Again, the
standards folks came to the rescue with something called X.500, a standard for
accessing databases of users.
Is this situation starting to sound familiar? Many database vendors have
very different database engines, but most vendors have agreed on a set of verbs
for accessing a database: Structured Query Language (SQL). The beauty of SQL is
(in theory) that a client accessing data on a database can be relatively
ignorant of whether the data is stored in DB-2, Oracle, Informix, or SQL Server.
(I say in theory because every vendor likes to enhance SQL, making for some
incompatibilities.)
The Directory Server Solution
Now suppose the MSMail and cc:Mail programmers (and the Novell and NT
programmers, for that matter) decide that they're tired of writing code to keep
track of a database of users. Instead, they'll let anyone do it, so long as
users can query that database in some standard way. Just as you can have file,
print, and Web servers provide services on the network, you can also have a "user
database server" (or directory server) keep the user database and
respond to queries from MSMail, cc:Mail, Novell, NT, and the like. Ultimately,
that's what a domain controller will do under NT 5.0. In NT 5.0, third-party
client-server products such as databases, mail systems, and groupware systems
could all "open hailing frequencies" to their nearby domain controller
to find out about a user.
But those programs still need an interface, a standard set of programming
commands to query the directory. Writing a program to interrogate an NT 3.x or
4.0 domain controller about what's in its SAM is possible, but the language and
protocol to do that job is a proprietary Microsoft one. SQL could be the answer,
but it's awfully resource-heavy. Making every domain controller speak SQL would
be overkill, because SQL is designed to solve a wide range of data query
problems in a relational model. In contrast, databases of users, directories,
are simpler: They tend to be flat files, and they tend to be read more
frequently than they are written. As Microsoft's Steve Judd said, "You put
things into Active Directory that need to be visible in a lot of places but that
don't change very often." The term for such a database is a directory. You
can think of X.500 as SQL for directories.
Many people considered X.500 to be something of a cumbersome protocol, and
the Internet world came up with LDAP, an alternative method of accessing X.500
directories. Running an LDAP client imposes less system overhead than X.500.
Also, LDAP is an Internet protocol, and X.500 is a Consultative Committee for
International Telegraphy and Telephony (CCITT) protocol. LDAP will definitely
correct one of the sins of NT.
Before I go, let me add one more point. I've been referring to the Active
Directory as a database of users, but that's not all you'll find in the Active
Directory. Under NT 5.0, Active Directory will also contain information about
the machines on the network, shares available on the network, and available
applications. Active Directory will be the central repository of network
configuration information.