Overview of the JNDI Architecture
| The Java Naming and Directory Interface (JNDI) enables Java clients to have access to various naming and directory services. Like other things in the J2EE Specification, JNDI provides a set of APIs that contain Java interfaces and classes. JNDI is divided into five core packages:
For most EJB applications, the naming service features are used more than the directory service features. The directory service features are very important but are a little out of scope for this book. We will cover the naming service only as it relates to EJB. If you are interested in more information on the directory service features offered through JNDI, see the Sun JNDI site: http://java.sun.com/products/jndi Because we are focusing strictly on the naming service features, we will look exclusively at the javax.naming package. You must have a vendor-provided implementation to take advantage of JNDI services. This is similar to the Java Database Connectivity (JDBC) API where you must have a JDBC driver to use the JDBC APIs to connect to a database. With JNDI, the vendor-provided implementation is known as a Service Provider Interface (SPI), and it allows the JNDI methods to be called on a particular naming service. Figure 4.4 shows how an SPI provides the implementation behind the APIs. Figure 4.4. Java clients use the JNDI APIs and a Service Provider Interface to take advantage of naming and directory services. The SPI enables JNDI to connect to a particular naming service implementation and it wraps the proprietary naming service APIs with the ones defined by JNDI. The SPI maps the JNDI calls to ones that a particular naming service can understand. This allows the client to use the JNDI APIs only and to switch between different naming services without negatively affecting the client application. In fact, a client can navigate from one type of naming service to another using JNDI without knowing it. For example, a binding from an LDAP server might have a reference to an object that exists in an RMI Registry naming service. As long as the client uses the JNDI API, the transition from one naming service to another will be transparent. All the proprietary code for the particular naming service is encapsulated within the SPI. The Available JNDI Service ProvidersThere are several different types of naming services. There is a JNDI implementation for most of the different types. There also might be different providers for a particular type. For example, both Iona and Inprise have a Common Object Services (COS) name service within their CORBA products. You can use JNDI to access both of them. The following is a list of the JNDI implementations available:
Some of these are still beta releases. The list is being added to frequently. To get a current list of implementations that are available, see the list maintained on the Sun site at http://java.sun.com/products/jndi/serviceproviders.html Looking at the different types of naming services, you might be able to imagine that not all naming services are created equal. The way in which they store binding information or allow clients to locate certain bindings can be very different. Each naming service might store the information in a slightly different format than another. Because some names in a binding might point to another name in a different binding, most naming services store the bindings in a hierarchical fashion. However, the manner in which a client sees this hierarchy and navigates through it can be completely different from one naming service to another. For example, the DNS uses dots (".") to separate the bindings, as in www.sun.com . LDAP, on the other hand, uses a completely different format. Because naming services can be so different, there must be a Java way of hiding the naming service-specific details and allowing for a single API. This is the purpose of JNDI. JNDI allows a client to see all these different naming services in the same way. |
EAN: 2147483647
Pages: 223