Java Reference
In-Depth Information
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 look
up 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
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:
