JNDI Architecture
A JNDI Example
Introducing the Context
Looking Up Objects in a Context
The NamingShell Application
Listing the Children of a Context
Creating and Destroying Contexts
Binding Objects
Accessing Directory Services
Modifying Directory Entries
Creating Directory Entries
Searching a Directory
The Java Naming and Directory Interface ( JNDI) is an API that supports accessing naming and directory services in Java programs. The purpose of a naming service is to associate names with objects and provide a way to access objects based on their names. You should be familiar with naming systems; you use them every day when you browse the filesystem on your computer or surf the Web by typing in a URL. Objects in a naming system can range from files in a filesystem and names located in Domain Name System (DNS) records, to Enterprise JavaBeans (EJB) components in an application server and user profiles in an LDAP (Lightweight Directory Access Protocol) directory. If you want to use Java to write an application such as a search utility, a network-enabled desktop, an application launcher, an address book, a network management utility, or a class browser--in short, anything that accesses objects in a naming system--JNDI is a good candidate for writing that application.
As its name implies, JNDI doesn't just deal with naming services. JNDI also encompasses directory services, which are a natural extension of naming services. The primary difference between the two is that a directory service allows the association of attributes with objects, such as an email address attribute for a user object, while a naming service does not. Thus, with a directory service, you can access the attributes of objects and search for objects based on their attributes. You can use JNDI to access directory services like LDAP and Novell Directory Services (NDS) directories.
As an enterprise programmer, you will most likely use JNDI to access Enterprise JavaBeans; the EJB specification requires that you use JNDI to locate EJB components on the network. But you can also use JNDI to find remote objects in an RMI registry on a remote server. And most enterprise Java suppliers, such as BEA WebXPress, IBM, Novell, Sun, and SCO, support JNDI access to their naming systems.
The architecture of JNDI is somewhat like the JDBC architecture, in that both provide a standard protocol-independent API built on top of protocol-specific driver or provider implementations. This layer insulates an application from the actual data source it is using, so, for example, it doesn't matter whether the application is accessing an NDS or LDAP directory service.
The JNDI architecture includes both an application programming interface (API) and a service provider interface (SPI), as shown in Figure 6-1. A Java application uses the JNDI API to access naming and directory services, primarily through the Context and DirContext interfaces. The JNDI API is defined in the javax.naming and javax.naming.directory packages. Note that JNDI is a standard extension to the Java 2 platform; it is available at http://java.sun.com/products/jndi/. This chapter covers Version 1.1 of JNDI.[1]
[1]As this book went to press, Sun released a public draft of Version 1.2 of the JNDI specification. The information in this chapter is unchanged by this new version of the specification.
In order for an application to actually interact with a particular naming or directory service, there must be a JNDI service provider for that service. This is where the JNDI SPI comes in. A service provider is a set of classes that implements various JNDI interfaces for a specific naming or directory service, much like a JDBC driver implements various JDBC interfaces for a particular database system. The provider can also implement other interfaces that are not part of JNDI, such as Novell's NdsObject interface.
The classes and interfaces in the javax.naming.spi package are only of interest to developers who are creating service providers. For instance, the NamingManager class defines methods for creating Context objects and otherwise controlling the operation of the underlying service provider. As an application programmer, you don't have to worry about the JNDI SPI. All you have to do is make sure that you have a service provider for each naming or directory service you want to use. Sun maintains a list of available service providers on the JNDI web page listed earlier.
 |  |  |
| 5.10. The Servlet API 2.1 |  | 6.2. A JNDI Example |
Copyright © 2001 O'Reilly & Associates. All rights reserved.