JNDI overview, Part 4: the Doc-u-Matic, a JNDI application

Pull together your JNDI knowledge with a JNDI-enabled application

By Todd Sundsted, JavaWorld.com, 03/31/00

Let's dive in. I've spent the last three months describing the Java Naming and Directory Interface (JNDI). By now, you should feel comfortable with naming and directory services and the operations they support. It's now time to build on that foundation. I've developed a JNDI-enabled document publication and distribution application -- called Doc-u-Matic -- that illustrates and utilizes the material I've presented in the past three How-To Java columns.

TEXTBOX:

TEXTBOX_HEAD: JNDI overview: Read the whole series!

Part 1. An introduction to naming services

Part 2. Use JNDI directory services to better manage your distributed applications

Part 3. Use JNDI to store your distributed application's objects

Part 4. Pull together what you've learned with a JNDI-enabled application

:END_TEXTBOX

The Doc-u-Matic application illustrates JNDI's support for:

Centralized information administration
Network-wide information distribution
Object persistence

Note: To download the complete source code for this article, see Resources.

Keep the objects around

Doc-u-Matic is first-and-foremost a demonstration of JNDI-supported object persistence. Therefore, I think it makes sense to begin with a review of JNDI's support for stored objects.

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.

The functional units

Figure 1, below, illustrates Doc-u-Matic from a functional perspective. Doc-u-Matic consists of three major functional units: the JNDI service (of course), a library service, and one or more clients.

Figure 1. Doc-u-Matic: A functional view

A library is a place to which you publish objects and from which you retrieve them. An object can be any Java instance, as long as it supports one of the storage methods mentioned above -- it can be a String, a JavaBean, and so on.

JNDI plays two roles in Doc-u-Matic. It provides a single, well-known location where clients can locate the library service (standard address-book functionality), and it supports the implementation of the library service itself. On the latter point, it's worth noting that nothing in the design of a library implies that it has to be implemented on top of JNDI -- that's just the direction I took (since this is an article on JNDI). You could implement a library on top of any technology that provides support for publishing and retrieving information, including HTTP, JDBC, NNTP, or IMAP. Best of all, the clients would never know the difference.

Before you proceed...

Doc-u-Matic assumes you have obtained, or have access to, and have configured an LDAP service. The application should support any naming and directory service that provides a JNDI service provider. However, I will assume you're using LDAP.

Before you proceed, make sure you've obtained, installed, and configured the following (if necessary, refer back to my earlier columns):

1 | 2 | 3 | 4 | Next >