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.

The hidden JNDI provider

The JNDI providers shown in the previous figure all have something in common -- they delegate requests to an external directory service, such as LDAP. However, this diagram doesn't show one important type of JNDI provider: the JNDI provider built into every J2EE container, which stores directory information in an internal database. When we talk about using JNDI in J2EE applications, we usually refer to this container-supplied provider.

How does J2EE use JNDI?

J2EE applications are assembled out of components. The ways components are configured and connected to each other are specified at deployment time; much of this information is stored in a JNDI namespace. J2EE applications use JNDI to store configuration information (such as string and numeric constants), stateless objects (including object factories), and EJB (Enterprise JavaBean) home interfaces.

JNDI is the glue that allows you to build J2EE applications out of components like servlets, JSPs (JavaServer Pages), and EJBs. In a J2EE application, each component finds other components not via static linking, but through JNDI lookups. J2EE applications allow for deployment-time binding while maintaining type and link safety by having each component export a list of external components and resources it needs. The deployer ensures that each import has a corresponding component of the correct type in the application. J2EE containers include tools to help you do this correctly.

How can J2SE apps use JNDI?

Like J2EE applications, J2SE applications can use JNDI as a shared repository of named configuration parameters, objects, and object factories. The Factory creation pattern works especially well with JNDI, as you can just store your factories in the JNDI namespace. J2SE applications can also use JNDI as a more robust, feature-rich, and centralized replacement for the RMI (Remote Method Invocation).

Most J2SE applications load their configuration information from configuration files, which are stored either as property files or XML documents. These configuration files specify all sorts of configuration information; some more sophisticated applications store information for instantiating objects, such as class name and constructor parameters, in a configuration file.

Using JNDI to store constants, objects, and object factories has several advantages over the more traditional configuration mechanism. Since most JNDI providers are network-accessible, you do not need to keep a consistent set of configuration files for each host in a distributed application. Additionally, using reflection to instantiate an object is messy and requires more code (more error-recovery code in particular) than simply retrieving the object out of a JNDI namespace. While using JNDI doesn't generally obviate the need to instantiate an object from configuration information (when you populate the namespace, generally at application startup time), this complexity is factored away from most of the application code, which can simply retrieve the desired object from the JNDI namespace.