ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

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.

Pages: 1, 2, 3, 4, 5, 6, 7

Next Pagearrow