J2EE or J2SE? JNDI works with both

The Java Naming and Directory Interface is not just for J2EE applications

By Brian Goetz, JavaWorld.com, 04/19/02

JNDI, the Java Naming and Directory Interface, allows applications to access various naming and directory services via a common interface. The figure below shows the JNDI architecture. Like JDBC (Java Database Connectivity), JNDI is not a service, but a set of interfaces; it allows applications to access many different directory service providers using a standardized API. Just as with JDBC, the JDK contains the JNDI interfaces but does not include a JNDI service provider -- although Sun Microsystems provides adapters for connecting to existing directory service providers, such as LDAP (lightweight directory access protocol), DNS (domain name service), and CORBA. However, you can use one of several free or open source JNDI providers in your J2SE (Java 2 Platform, Standard Edition) applications.

JNDI is the glue that holds together J2EE (Java 2 Platform, Enterprise Edition) applications. JNDI was designed to support highly dynamic application assembly and deployment, with components constantly being added and updated without rebuilding the entire system. A naming service helps organize an enterprise application by acting as a central registry for components. J2EE applications typically use JNDI in several ways:

• As a means to store application configuration information in a centralized, hierarchical database
• As a repository for live objects shared among application components, which can run in different JVMs or on different systems
• As an interface to existing directory services like LDAP (using a provider specific to that external service)
• As a lightweight, hierarchical database for storing transient application state

Like J2EE applications, larger or more dynamic J2SE applications can benefit from the loose coupling and dynamic binding offered by an active directory service.

A simple JNDI example

Storing and retrieving objects from a JNDI namespace is quite straightforward; you first obtain a JNDI naming context and then use the bind() and lookup() methods to store and retrieve objects, as Listing 1 shows:

Listing 1. Store and retrieve objects from a JNDI namespace

  import javax.naming.*;
  public void createName() throws NamingException {
    Context context = new InitialContext();
    context.bind("/config/applicationName", "MyApp");
  }
  public String getName() throws NamingException {
    Context context = new InitialContext();
    return (String) context.lookup("/config/applicationName");
  }  

Listing 1 demonstrates the most common JNDI operations -- creating a JNDI context, binding an object in the context, and retrieving an object from the context. Note that the JNDI namespace and the client might reside in different JVMs, and the bind() and lookup() invocations might likewise occur in different JVMs. A JNDI provider uses a variety of techniques, including serialization, to ensure that the object can move from JVM to JVM and still be retrieved in its original form.

Listing 1's code fragments have several hidden assumptions: How does JNDI know which provider to use when creating the context? For providers that require authentication, where do the credentials come from? Generally, you specify the provider and other connection parameters by setting several JNDI-specific properties in the system properties, or by setting them in the jndi.properties file. Also, any given provider might not be able to bind or retrieve arbitrary objects. For example, some providers, such as the DNS provider, are read-only, and some providers might be more flexible about the types of objects they can bind. Most vendor-supplied JNDI providers can store and retrieve objects that implement one of java.io.Serializable, java.rmi.Remote, or javax.naming.Referenceable.