Developing A White Pages Service with LDAP and JNDI
by Budi Kurniawan
05/21/2001
Lightweight Directory Access Protocol (LDAP) is increasingly
popular because it simplifies what has been complex, namely, accessing
directory services. In this article you will learn what you can do
with LDAP and how Java handles LDAP with its Java Naming and Directory
Interface (JNDI) API. At the end of the article, you will find a
project that provides a white pages service built with LDAP and
JNDI.
Naming and Directory Services
Before you start the project, you should first familiarize yourself
the jargon of naming and directory services.
The Naming Service
A naming service lets you find an object in a system based on the
name associated with the object. Naming services are easy to
find. Take the filesystem in your computer, for instance. Every file
in a computer has a name; to access a file you must know its name. In
filesystems, files are objects associated with filenames. Another
example is the Internet's DNS, which maps easy-to-remember names (such
as onjava.com and jUpload.com) to IP addresses. When you work with
Enterprise JavaBeans (EJB), you use a naming service to get a
reference to a Bean. In short, a naming service allows you to look up
an object by its name.
Each naming service has its own rules for making valid names. For
example, the rules for valid filenames Linux are different from the
rules in Windows.
The association of a name with an object is called a binding. In a
filesystem, a filename is bound to a file. In a DNS server, domain
names are bound to IP addresses.
Objects in some naming services cannot be stored directly inside
the naming service. Instead, the name service stores pointers or
references to objects. A reference contains an address, that is,
specific information on how to access the object itself.
A Context
In a naming service, obviously you have more than one
name-to-object binding. The set of bindings is called a context. There
are two types of contexts: root and subcontext. A root context is the
base name of an object. In a filesystem, the root context is the base
from which all other directories and files are stored. In the Unix
file system, the root context is /. Under Windows it is
normally C:\.
A subcontext is a name that adds another level to the root
context. For example, a directory, such as usr under
/ in a Unix filesystem, is a subcontext. In the Unix
system, this subcontext is called a subdirectory. That is, in a
directory, /usr, the directory usr is a
subcontext of /. In another example, a DNS domain, like
COM or NET, is a context. A DNS domain named relative to another DNS
domain is a subcontext. For example, in the DNS domain
brainysoftware.com, the DNS domain brainysoftware is a subcontext of
COM.
The Directory Service
A directory service is an extension of a naming service. In a
directory service, an object is also associated with a name. However,
each object is allowed to have attributes. You can look up an object
by its name; but you can also obtain the object's attributes or search
for the object based on its attributes.
Going back to the Unix file system, it's not just a naming service
but also a directory service. Each file can have attributes like owner
and date. In real world applications, a directory object in a
directory server can be used to represent anything: a printer, a
computer, a network, or even a person in an organization.