[ Team LiB ] Previous Section Next Section

Java Naming and Directory Interface

Sun Microsystems defines JNDI as “a standard extension to the Java platform, which provides Java technology-enabled applications with a unified interface to multiple naming and directory services in the enterprise. As part of the Java Enterprise API set, JNDI enables seamless connectivity to heterogeneous enterprise naming and directory services.” JNDI has been designed especially for Java. A Java application can use JNDI to retrieve Java objects. JNDI also provides for performing standard directory operations, such as associating attributes with objects and searching for objects using their attributes.

JNDI is an interface, not an implementation. It can be used to seamlessly integrate with different, possibly multiple, implementations (such as LDAP, DNS, and so on). You must still understand certain basics of the underlying implementations (such as their naming convention) to enable JNDI to connect to them, although you aren't required to understand their implementation artifacts.

Overview of the JNDI Architecture

JNDI is comprised of the JNDI SPI (service provider interface), which is used by service providers to JNDI-enable their products and the JNDI API (application programming interface), which is used by clients to connect to these service providers. Figure 8.1 describes the architecture and how clients can use the different service providers using JNDI.

Figure 8.1. JNDI architecture.


In this chapter, you'll see how to use the JNDI API to access WebLogic's implementation of JNDI. Because this chapter discusses the usage of JNDI from your J2EE application, rather than writing a JNDI service provider, a discussion of the JNDI SPI is beyond the scope of this book.

Overview of the JNDI 1.2.1 Specification

WebLogic Server 8.1 fully supports JNDI version 1.2.1. Some of the features of this version of JNDI are

  • Event notification— With JNDI 1.2.1, clients can register to receive events, which can make the client aware of changes to the naming service as well as the bound objects.

  • LDAPv3 extensions and controls— Applications and service providers can now work with LDAPv3 extended operations and controls using the classes and interfaces in the javax.naming.ldap package.

  • Resource file support— The JNDI environment can be created using resource files.

  • The functionality provided by the javax.naming.spi package for service provider support has been enhanced in JNDI 1.2.1.

The following sections discuss the highlights of the packages that the JNDI 1.2.1 specification provides for.


The javax.naming package consists of classes and interfaces that enable the user to communicate with the different naming services. It provides the ability to perform several operations such as

  • Adding or removing a name to object binding

  • Creating or destroying subcontexts

  • Looking up the object bound to a given name

  • Listing the bindings in the namespace

The following are some of the key components of this package:

  • Context— A naming system can be seen as a hierarchy of nodes. Each nonterminal node is represented by the Context interface. The naming system is a connected set of contexts, each of which follows the same naming convention. It defines basic operations on the naming system such as looking up an object bound to a name, listing the bindings, creating and destroying subcontexts, adding a new binding, removing an existing binding, and so forth. Thus, in JNDI, every name is relative to a context—there's no notion of an absolute name.

  • InitialContext— Because a naming system is a connected set of contexts, an application can begin using a naming system by getting its first context of type InitialContext. After getting the InitialContext, you can then access all its subcontexts by using names relative to the initial context.

  • Bindings— A binding is a mapping between a logical name with its object inside a naming service. The Context interface allows applications to access these bindings by using several of its methods. For example, Context.lookup() returns a handle to the object that is bound to the name, which is passed as its parameter, whereas Context.list() returns an enumeration of all the name-to-object bindings present in the naming system.


A directory object is a particular type of object that holds several attributes of a computing environment, thus describing it at an atomic level. The classes and interfaces in the javax.naming.directory package allow the application to access attributes associated with directory objects. This package also provides the application with the capability to search through directory objects by passing in their attributes using the DirContext interface.


The classes and interfaces in the javax.naming.event package allow the application to be notified of several changes to the naming service as well as to the objects bound inside.

For example, events (called NamingEvents) are generated when adding a new object, changing the name (binding) of an object, and so on.

The NamingEvent's type attribute identifies the type of the event. The NamingEvent class defines four types of events, indicating different operations performed on objects (add, remove, rename, or change). Applications may register to receive one or both types of events (that is, namespace changes and object changes) by using either the EventContext or the EventDirContext interface.

You can learn more about JNDI events in the tutorial posted by Sun Microsystems at the URL http://java.sun.com/products/jndi/tutorial/index.html.


The javax.naming.ldap package allows the application to use LDAP v3–specific features including extensions and controls, which cannot be achieved using the javax.naming.directory package.

You can learn more about JNDI LDAP support in the tutorial posted by Sun Microsystems at the URL http://java.sun.com/products/jndi/tutorial/index.html.


The javax.naming.spi package allows different naming/directory service providers to provide implementation hooks to their facilities so that applications using the JNDI API can have access to those facilities. This package also provides support for the case in which one service provider implementation must access other implementations to complete a client's JNDI operations, thus providing support for composite namespaces.

You can learn more about the JNDI SPI in the tutorial posted by Sun Microsystems at the URL http://java.sun.com/products/jndi/tutorial/index.html.

    [ Team LiB ] Previous Section Next Section