Goals for JNDI
Understanding the design goals that the architects of JNDI had in mind may help you understand and appreciate how the JNDI designers intended JNDI to be used. This section is based on the JNDI specification from Sun Microsystems and provides a brief insight into these goals.
- Keep it consistent and intuitive. One of the design goals for JNDI was to make sure the API made sense. That means that they tried to use classes and methods that added the maximum benefit and didn’t overlap too much with services of other APIs. Great effort was taken to avoid duplicating the capabilities of objects in the Java class libraries. By keeping the number of classes to a minimum and leveraging other object classes, the design of JNDI could be made simple yet powerful. Even within JNDI, this principle was followed. For example, the API design for the directory service functionality is simply an extension of the more subset functionality of the naming service API. In this way, the directory service part of the API is easy to learn and use, once you understand the fundamentals of the naming portion of the API.
- Pay for what you use. The term “pay for what you use” means that the designers didn’t want you to have to learn or use more of the features and API than you needed to do the task at hand. This reduces your learning curve and reduces the overall size and complexity of your program. For example, if you want to look up a file on your computer, you need to use only a few classes and interfaces from the javax.naming package. You don’t need to look at the javax.naming.directory package at all to get your job done.
- Implementable for common directory and naming service protocols. Obviously, it is important that a standard interface for accessing naming and directory services support the common protocols. However, the designers are making a more significant commitment to keep the API as implementation independent as possible. This means you should not find too many methods that don’t apply to your service provider. In other words, the API provides just what you would expect for most services. At the same time, you can still leverage the unique features of a particular service by adding your own functionality or by using a service provider that extends the capabilities of JNDI to access these unique features.
- Enable seamless and dynamic services. The goal to enable directory services to seamlessly plug in behind JNDI greatly benefits the programmer using JNDI. By designing JNDI with a dynamic interface for accessing services, you can offload, until run time, choices about which protocol or technique to use for accessing your service. This gives your application more flexibility and lowers the cost of maintaining and enhancing your application over time. For example, today you could access files on your local machine and, with very few or no code changes, access a remote file via some combination of LDAP, RMI, and so on. The ability to seamlessly modify the source of the data without changing your application provides great flexibility and better long-term maintenance of your code, which results in lower total cost.
JNDI Architecture
The JNDI API is a Java extension API and is contained in the packages javax.naming, javax.naming.directory, and javax.naming.spi.
- • The package javax.naming is the basic API used typically to look up objects and values in a naming service, such as an RMI object registry.
- • The package javax.naming.directory contains a slightly more sophisticated API used for filtered searching and modifying of hierarchical values in directory and naming services such as LDAP.
- • The package javax.naming.spi provides a set of interfaces and objects used by service provider developers. Most enterprise developers will not need to use this API, because it is used for mapping JNDI calls to a specific service provider. Typically, you will use the higher-level calls in the javax.naming and javax.naming.directory packages.
Clients of a service provider should be familiar with the JNDI interface. Clients interested in writing a service object class should be familiar with the service provider interfaces and classes in the javax.naming.spi package. Service providers create libraries using the javax.naming.spi package, which contains classes and interfaces that define the behavior of a JNDI service provider. Figure 4.1 illustrates the JNDI architecture.
NOTE: Because most enterprise Java programmers use services rather than creating their own providers, this book does not cover the javax.naming.spi.
Most application developers will use just the classes and interfaces defined in the javax.naming and javax.naming.directory pages, as shown in Figure 4.1. Refer to Table 4.1 for the available service providers.
NOTE: Service providers exist for many of the major directory and naming services. If you can’t find a provider for a service you want to access, you can use SPI to create a JNDI solution that integrates seamlessly with other naming and directory services.
Figure 4.1 JNDI architecture.
Summary
JNDI enables all of the various resources in an enterprise, including files, printers, servers, security services, databases, and business processes, to work together. Most directory services have the ability to manage a set of resources. JNDI allows you to leverage the strengths of many services. Because of JNDI’s design, you need to learn a fairly small API that allows your Java application access to a great variety of enterprise resources. The next chapter explores APIs and looks at code examples for using specific naming and directory services.
