Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JNDI overview, Part 3: Advanced JNDI

Use JNDI to store your distributed applications' objects

  • Print
  • Feedback
I need to cover a lot of ground this month, so I'll leave out the fluff and cut right to the bullet points. First, the Java Naming and Directory Interface plays an important role in several Java technologies. We're going to take a look at this role to better understand JNDI's strategic position in the overall Java picture. Next, in recognition of your need for a working JNDI service to play with, I'll introduce you to a freely available, portable LDAP implementation, and I'll teach you how to connect to and use a JNDI service provider. Finally, I'll take you in for a close look at binding objects to entries in JNDI.

TEXTBOX:

TEXTBOX_HEAD: JNDI overview: Read the whole series!

:END_TEXTBOX

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.

Let's begin with a look at how JNDI appears in other Java technologies.

JNDI everywhere

JNDI plays a role in a number of Java technologies. Let's consider three of them: JDBC (the Java Database Connectivity package), JMS (the Java Messaging Service), and EJB (Enterprise JavaBeans).

JDBC is the Java technology for relational databases. JNDI first appeared in the JDBC 2.0 Optional Package (see Resources) in conjunction with the DataSource interface. A DataSource instance, as its name implies, represents a source of data -- often from a database but not always. A DataSource instance stores information about a data source -- such as its name, the driver to load and use, and its location -- and allows an application to obtain a connection to the data source without regard to the underlying details. The JDBC specification recommends using JNDI to store DataSource objects.

JMS is the Java technology for messaging. The JMS specification describes administered objects -- objects that contain JMS configuration information and are used by JMS clients to locate specific message queues and topics. As is the case with JDBC, the specification recommends locating JMS administered objects via JNDI.

Finally, consider Enterprise JavaBeans. All enterprise beans publish a home interface -- the single location through which clients locate a specific enterprise bean -- via JNDI.

What does JNDI bring to the table that causes it to be so highly regarded?

First, JNDI promotes the notion of a centrally managed information source -- a key requirement for enterprise applications. A centrally managed information source is easier to administer than a distributed collection of information sources. It's also simpler for clients to locate needed information if they only have to look in one place.

  • Print
  • Feedback

Resources