The Java Naming and Directory Interface (JNDI) is a staple of the J2EE platform and supports Enterprise JavaBeans (EJB). JNDI enables seamless connectivity to heterogeneous enterprise naming and directory services. JNDI allows developers to build portable, directory-enabled applications. Let’s see how it works and take a look at the code you need to get started.

Naming names
Nearly all aspects of a computing platform rely on being able to find, retrieve, and store resources using some form of standardized naming system. For example, file systems rely on file and directory names, directory services rely on object names, and DNS systems rely on URLs—that’s how you found this article.

Most naming systems use a syntax that facilitates relative naming with the avoidance of name collisions. For example, observe the file system directory structure in Figure A.

Figure A
Sample directory structure

You may notice some files with the same names (File 1 and File 2) in Figure A. This presents a number of problems when trying to refer to one of the files. However, when each file is referred to in context with its parent directory, the problem is solved. To illustrate, let’s assume that the naming syntax uses a UNIX-style separator. To refer to each file named File 1 by its full pathname we use the following syntax:
�
��� /Root/Directory 2/Directory 2.2.1/File 1
��� /Root/Directory 2/Directory 2.2.2/File 1
�

Notice that each file’s full pathname is unique. This allows an operating system to properly perform an operation on one file without worrying about whether the operation will collide with the other file. An environment that provides this kind of flexibility to refer to an object relative to its context is referred to as a namespace.

Introducing JNDI
The Java Naming and Directory Interface is a standard extension to the Java platform, providing a set of interfaces, classes, and concepts across any namespace. As with many other Java technologies, JNDI is a provider-based technology exposing an API and a service-provider interface (SPI). This means that any name-based technology can be exposed through JNDI if a JNDI provider is available for the technology. Currently the list of available JNDI providers includes LDAP, CORBA Common Object Services (COS) name service, RMI, NDS, DNS, and Windows registry, among others. Many J2EE technologies, including EJB, rely on JNDI to organize and locate entities.

JNDI associates an object with a name using a concept known as a binding. In a file system, a filename is bound to a file. In DNS, a URL is bound to an IP address. In a directory service, an object name is bound to an object entry.

A group of bindings in JNDI is referred to as a context. The set of operations exposed by each context in JNDI is consistent. For example, every context provides a lookup operation that returns an object for a given name, and every context provides operations for binding and unbinding objects to names. Namespaces are exposed in a generic fashion in JNDI using a hierarchy of contexts and subcontexts that use the same naming syntax.

JNDI in action
Let’s look at how contexts are used in JNDI. First, an initial context is established. This is simply a starting place from which to navigate. Next, we browse the objects existing at the initial context, add objects, remove objects, traverse to parent contexts or subcontexts, etc. The example in Listing A illustrates how to establish an initial context at the root of a file system and list the objects (files and directories) at that context. We will use the file system provider available from Sun.

In Listing B, you can see how to establish an initial LDAP context for a publicly available LDAP server and browse its objects.

As you can see by the examples, each namespace can be browsed in the same manner. The only difference in the code is the provider URL property. This is the crux of JNDI—providing an abstraction on heterogeneous namespaces, thus providing the ability to operate on them with essentially the same code. You have to dig deep into a service provider’s particular implementation to find many operational differences.

Listing C modifies our examples slightly to perform a lookup on our initial contexts to find a specific subcontext. We will perform the lookup operation on the file system provider first.

Listing D establishes an initial LDAP context for a publicly available LDAP server and browses its objects.

Again, you can see how the code remains essentially the same across providers. Only the specific name for each subcontext needs to change to perform the lookup.

Employing JNDI
JNDI became part of the Java 2 SDK as of version 1.3. With versions 1.1 through 1.2, you can download and install it as a standard extension to the JDK. You must also have the service provider installed for the particular namespace with which you want to work, such as LDAP, file system, or RMI. You can download the desired service provider from Sun’s JNDI Web site or from the SPI vendor directly.