"Before I begin, a little doublethink is in order. Over the last two months, I've tried to convince you that naming and directory services are roughly the electronic equivalent of the card catalogs found in libraries. Now as we begin our tour of the advanced features of JNDI, I want you to forget this analogy completely -- it grossly underillustrates the power of JNDI."
"This month, I introduce the Java Naming and Directory Interface (JNDI). JNDI provides a common-denominator interface to many existing naming services. As such, JNDI was not designed to replace existing technology; instead, it provides a common interface to existing naming services. Let's begin by taking a look at some of these services."
"Directory services are simple databases. Like their relational cousins, many common directory services provide search and filter functionality. Instead of locating an entry only by name, these directory services allow you to locate entries based on a set of search criteria."
"You may recall from March's column that there are three techniques for storing Java objects in a JNDI service: as serialized data, as a reference to an object, and as the attributes on a directory context. Storing an object as serialized data is the simplest of the three techniques. Storing an object as a reference is useful in situations in which it doesn't make sense (or isn't possible) to store actual objects. Finally, storing objects as attributes on a directory context is useful when other, non-Java applications need access to the object's information. The application I've developed uses the first two methods of object storage."
"Lightweight Directory Access Protocol (LDAP) is increasingly popular because it simplifies what has been complex, namely, accessing directory services. In this article you will learn what you can do with LDAP and how Java handles LDAP with its Java Naming and Directory Interface (JNDI) API. At the end of the article, you will find a project that provides a white pages service built with LDAP and JNDI."
"JNDI filters are Java classes that can be invoked in response to a request for a resource in an intercepted JNDI object. They are very similar to Servlet filters but are used on the server-side."
"The DNS service provider enables JNDI-based applications to access information stored in the DNS. The DNS service provider presents the DNS namespace as a tree of JNDI directory contexts, and the DNS resource records as JNDI attributes."
"The next bits of information your client needs are values for some properties. First, you'll need some value for java.naming.factory.initial. This property points to a class that provides an initial context factory. A typical value for this property, which we'll be using for these examples, would be com.sun.jndi.cosnaming.CNCtxFactory; this class exists in rt.jar and as such is part of the base JVM. This factory is for use by CosNaming nameservers, but the JVM includes an LDAP factory as well. Different application servers provide their own initial context factories, as we'll see later."
"This <resource-ref> tag associates the JNDI name to the resource object's type, which in this case is javax.mail.Session. If it looks familiar, it's because it's the same tag used to declare the object types of other resources like data sources (for JDBC) or connection factories (for JMS). Both of these resource types have already been used elsewhere in the example application. Listing 2 contains the tag needed in the corresponding Geronimo-specific plan."
"In the previous three steps, you learned how to embed Crystal Reports in your Web applications that use JDBC connections at design time and run time. This step explains how to use JDBC at design time and switch to JNDI at run time. To use JNDI at run time, first you have to create a data source. Then you will re-visit the Standard Report Creation Wizard, sub-step 9 of Step 2, to use this data source for making the JNDI connection at run time. Because your project is targeted to the WebSphere V 6.0.2.5 test environment, you can use the Rational Application Developer Enhanced EAR editor to create this data source."
"Configuring the descriptor files is important, because it's the mechanism that allows these components to be used in Geronimo. It's also how JNDI names get associated with a given Java object. Components deployed in Geronimo typically have two deployment files: the standard Java deployment descriptor and the Geronimo-specific deployment plan. The primary resource is the CustomerServiceDatabase. The data source, CustomerServicePool, provides a number of connections to access this database. To store customer information, the user first accesses the Web interface and types information in the fields. Those fields are passed to a Java bean that references a session bean. This session bean acts on the customer data by referencing an entity bean to perform the basic database operations. The entity bean is the Java object representation of one row in the customer's table, and it's the component that references the CustomerServicePool to access the database. Listing 2 contains the standard Java deployment descriptor for this entity bean."
"In addition to being more clear (at least in my opinion) the factory-optimized EJB lookup above will perform much faster over time. The first time you use the new class, you'll incur all the usual lookup penalties (assuming another portion of the application hasn't already paid them) but all future JNDI lookups should hum right along. It's also worth pointing out that the home-interface factory will not interfere with your container's bean management. Containers manage bean instances, not the home interfaces of those instances. Your container will still be in charge of instance swapping, as well as any other optimizations you want it to perform."
"The factory and receivingTopic are both obtained from JNDI and correspond to the resources CustomerServiceConnectionFactory and CustomerServiceTopic, respectively. Both of these resources were created using the Geronimo console. Listing 9 shows how to use these JMS resources to send a message to a destination."
"Dolly could have avoided this dilemma if she had developed her application with knowledge of the J2EE roles. The J2EE specification delegates responsibilities into numerous development roles: Component Provider, Application Assembler, Deployer, and System Administrator. (In many organizations, the Component Provider and Assembler roles are merged, as are the Deployer and System Administrator roles.) Before JNDI's role in J2EE can be truly understood, it's important to grasp what the J2EE roles do."
"JNDI provides a uniform API into a naming or directory service. You can use any naming or directory service through JNDI as long as you have access to a Service Provider implementation for that service."
"For the most part, these features are entirely transparent to developers. In fact, support for connection pooling and distributed transactions requires almost no new knowledge on the part of the developer. This article explores the part of the JDBC 2.0 Standard Extension that will have the most impact on developers, the JNDI support."
