Java Naming Directory Interface

Why Use a Naming Service?

One reason to use a naming service is that it enables you to decouple the provider of a service from its consumer. This is because the name that the supplier of the service uses to register the service is the only thing that the consumer needs to know.

Another reason to use a naming service is that it can provide an application with a single repository of information in which it can find all of its required resources.

When you use a naming service, you have a consistent way of publishing services that is independent of any particular platform and, therefore, is portable. In addition, you are free to migrate a service from one host to another. All that you would need to do is update the entry in the naming service to point to the new location of the service. The beauty of this is that the client needs to know nothing about the fact that the service has moved.

The JNDI API defines an interface that Java programs can use to access a variety of naming and directory services in a uniform way. JNDI was designed specifically for the Java platform, and uses Java's object model. Therefore, you can use JNDI to store and retrieve Java objects of any type.

It is perhaps helpful to also state what JNDI is not: It is not a naming and directory service implementation, only an API. Thus, to use JNDI, you must also have available an implementation of a naming and directory service.

In fact, JNDI consists of both an Application Programmer's Interface (API) and a Service Provider's Interface (SPI). Figure 13.4 shows the architecture of how your application, the JNDI API, SPI, and the naming service implementations fit together. Because the JNDI API is defined in a way that is independent of any individual directory service implementation, it is possible to use additional naming services as long as they implement the SPI for JNDI. A service provider is basically a driver that your application can use to communicate with a directory service.

Figure 13.4

The JNDI architecture.

What Is JNDI?The JNDI API defines an interface that Java programs can use to access a variety of naming and directory services in a uniform way. JNDI was designed specifically for the Java platform, and uses Java's object model. Therefore, you can use JNDI to store and retrieve Java objects of any type.

It is perhaps helpful to also state what JNDI is not: It is not a naming and directory service implementation, only an API. Thus, to use JNDI, you must also have available an implementation of a naming and directory service.

Without JNDI, it is necessary to learn the specific APIs that are implemented by the naming and directory service that you are using. This makes life a lot more difficult for application developers because they need to know all the APIs for the different naming and directory services used in their enterprise, thus leading to harder-to-maintain code. Figure 13.3 shows the architecture of a client and multiple services that each provides its own API.

Figure 13.3

The architecture of a system that does not use JNDI.

The JNDI architecture's layered design was constructed to help insulate client code from naming service provider code.

The JNDI classes and interfaces are divided into five main packages: javax.naming, javax.naming.directory,

javax.naming.event, javax.naming.ldap, and javax.naming.spi. These packages are covered in the

next five subsections of this chapter.

The javax.naming Package

The javax.naming package contains the classes and interfaces that your application can use to access naming services. The

Context and Name interfaces are part of this package, as well as the Reference and Binding classes.

The javax.naming.Context Interface

Within a naming service, a set of bindings is referred to as a context. The javax. naming.Context interface is the principal

interface in JNDI because it defines methods that enable you to

Bind objects to, and unbind objects from, names.

Rename objects.

Retrieve objects with the lookup method.

Context configuration in Tomcat6Configure the JNDI DataSource in Tomcat by adding a declaration for your resource to your Context.

<Context path="/DBTest" docBase="DBTest" debug="5" reloadable="true" crossContext="true">

<!-- maxActive: Maximum number of dB connections in pool. Make sure you configure your mysqld max_connections large enough to handle all of your db connections. Set to -1 for no limit. -->

<!-- maxIdle: Maximum number of idle dB connections to retain in pool. Set to -1 for no limit. See also the DBCP documentation on this and the minEvictableIdleTimeMillis configuration parameter. -->

<!-- maxWait: Maximum time to wait for a dB connection to become available in ms, in this example 10 seconds. An Exception is thrown if this timeout is exceeded. Set to -1 to wait indefinitely. -->

<!-- username and password: MySQL dB username and password for dB connections -->

<!-- driverClassName: Class name for the old mm.mysql JDBC driver is org.gjt.mm.mysql.Driver - we recommend using Connector/J though. Class name for the official MySQL Connector/J driver is com.mysql.jdbc.Driver. --> <!-- url: The JDBC connection url for connecting to your MySQL dB. -->

<Resource name="jdbc/TestDB" auth="Container" type="javax.sql.DataSource" maxActive="100" maxIdle="30" maxWait="10000" username="javauser" password="javadude" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost:3306/javatest"/>

</Context>

web.xml configurationNow create a WEB-INF/web.xml for this test application.

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee

http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"

version="2.4">

<description>MySQL Test App</description>

<resource-ref>

<description>DB Connection</description>

<res-ref-name>jdbc/TestDB</res-ref-name>

<res-type>javax.sql.DataSource</res-type>

<res-auth>Container</res-auth>

</resource-ref>

</web-app>

Context initContext = new InitialContext();Context envContext = (Context)initContext.lookup("java:/comp/env");

DataSource ds = (DataSource)envContext.lookup("jdbc/TestDB ");Connection conn = ds.getConnection();

Or javax.naming.InitialContext ctx = new javax.naming.InitialContext();

DataSource ds = (DataSource) ctx.lookup("java:comp/env/DataSourceAlias");

Test DataSource Reference

Add a new Servlet within the web module. Write the doGet method as follows:

public void doGet(HttpServletRequest req, HttpServletResponse resp)throws ServletException, IOException {

javax.sql.DataSource ds = null;java.sql.Connection con = null;java.io.PrintWriter out = resp.getWriter();

resp.setContentType("text/html");

try {out.println("Looking up DataSource<br>");javax.naming.InitialContext ctx = new

javax.naming.InitialContext();ds = (javax.sql.DataSource)

ctx.lookup("java:comp/env/DataSourceAlias");out.println("Getting connection<br>");con = ds.getConnection();con.close();

} catch (Exception e) {e.printStackTrace(out);

}out.println("Done<br>");

}