1.3 JNDI Basics and Architecture

The Java Naming and Directory Interface (JNDI) is an industry-wide, open, consistent interface that gives developers a common interface for navigating the many naming systems that exist in the computing world today. JNDI is a pure Java API, specified in the Java programming language, that provides access to any naming or directory service implementation, but yet it is defined to be independent of any specific directory service implementation. As such it greatly simplifies the code needed to browse and utilize the functionality of directory services such as NDS, X.500, and LDAP, as well as file systems, DNS, and so forth. Thus, a variety of directories, new and existing, can be accessed in a common way using JNDI.

JavaSoft owns, maintains, and documents the core specification and functionality defined in JNDI, which is one of JavaSoft's extended API offerings and is part of the JavaSoft Enterprise API. You can access the official JNDI API specification at http://java.sun.com/products/jndi/1.2/javadoc/overview-summary.html

In the design of JNDI, JavaSoft worked closely with Novell drawing upon Novell's expertise in directory services and networked file systems to help with the effort. JavaSoft allows JNDI to be distributed by Java licensees, thus allowing it to be distributed with this NDK.

As a Java interface, JNDI provides a common layer of abstraction that insulates the application programmer from multiple interfaces for dealing with the naming aspects of an object system. The naming implementation is totally invisible. Directory service developers can benefit from a service-provider capability that enables them to incorporate their respective implementations without requiring changes to the client.

JNDI is the API and framework through which an application can access one or more naming systems through a single interface, the Service Provider Interface (SPI). This concept is illustrated in the following graphic.

Figure 1-6 JNDI Architecture

JNDI has the following key benefits:

If you’ve written a program that works with NetWare and NDS, chances are you had to hard-code operations on names, such as creation, deletion, and renaming, among others, for each naming system with which you had to work. JNDI levels the playing field, making all naming systems look alike.

In JNDI, you access files, directories, NCP extensions, servers, and NDS objects through the Context interfaces. You can also access the attributes and schema of directory contexts through the DirContext interfaces.

Although JNDI provides an interface to access named objects in naming systems, providers are required to implement certain JNDI methods for accessing a particular naming system. JNDI acts as a mediator between the application and one or more naming system providers.

Because JNDI supports more than one naming system, the functionality for a given context is dependent on the naming system from which it comes. For example, contexts in the server naming system have different functionality from contexts in the file naming system. So while you would use the exact same code to access the attributes of the context from the server naming system as the context from the file naming system, the attributes returned by the two contexts may be completely different.

Because JNDI abstracts the differences behind contexts, you can access and work with all contexts and their functionality using only the core interfaces and their methods.