Chapter 7. Distributed Technologies

Java Naming and Directory Interface (JNDI)

Packages

javax.naming, javax.naming.directory, javax.naming.event, javax. naming.ldap, javax.naming.spi

Use: J2SE (JDK 1.3), J2EE (J2EE1.2)

Description

The Java Naming and Directory Interface API was developed to provide a standardized way to access lookup services from within Java code.

It’s a vague definition, but it’s that way on purpose. JNDI allows you to standardize access across a whole range of naming and directory services. It's like having all the phonebooks in the world at your fingertips, without actually having to carry them around with you. Which actually makes it more like having 24-hour access to a telephone operator who has the complete set of phonebooks.

In the pre-JNDI days, developers had to use individual APIs to access different services. For instance, to communicate using RMI, an IT group would potentially have to set up and maintain an RMI registry implementation so that applications could find out which servers hosted which remote objects. To manage JDBC communication, the group would have to set up some way to store lookup information for a remote database. To manage directory services, they would have to maintain some scheme to manage navigation within their directory schema.

That’s three different lookup services, with three different technologies, potentially handled three entirely different ways. Some IT departments might welcome the challenge, but the frustration of development and maintenance would quickly drive most developers bananas.

JNDI consolidated the task of managing lookup services, so that an application could use the single technology for all its needs. What's more, JNDI made it easy to separate the configuration of the resources from their lookup characteristics, so that you need to put almost no environment-specific information in your code.

JNDI is also fairly easy to use. To access a resource, just create a helper object called a Context, use it to retrieve a resource by its logical name, then convert it to the expected object type, as shown in Example 7.1:

Example 7.1 Using JNDI

javax.naming.InitialContext jndiCtx = new InitialContext(); Object resource = jndiCtx.lookup("datasource"); javax.sql.DataSource hal = (javax.sql.DataSource)resource;

Once JNDI returns the resource, you just use it as you normally would. In this case, the DataSource could be used to connect to a database.

Java applications use the JNDI API to access a JNDI Naming Manager. The Naming Manager in turn uses one or more JNDI service provider interface (SPI) implementations to access underlying managed services. These services might be associated with directory structure and file storage, such as LDAP, NDS or NIS or they might equally well be associated with distributed object communications, such as RMI or CosNaming for CORBA.

Two major types of JNDI services are available. Naming services provide a way to associate an object with a name. You can subsequently use The name to locate a specific object. Directory services offer a way to group lookup information in a logical hierarchy, like a directory structure. In the hierarchy, names are associated with directories, which can in turn maintain sets of attributes and values. For both naming and directory services, the JNDI name is simply shorthand used to identify an object in a computing environment. In the same way that names are shorthand for representing people, the JNDI names represent complex objects.

In JNDI, a context represents the starting point that developers use to look up a resource. A context holds a set of associations between names and objects called bindings. A context also enforces a naming convention, which is a set of rules used to establish what constitutes an acceptable name.

JNDI consists of five packages, which do an admirable job of partitioning related capabilities. Table 7-1 shows the functional

breakdown:

199