o you're interested in object-oriented databases (OODBs), but you're still not quite sure how you'd use them. My previous article, "Object-Oriented Databases Are Worth a Closer Look", discussed the pros and cons of OODBs but didn't provide any practical examples of how the technology works. Luckily, a major benefit of many OODB solutions is the ability to start coding an application without immediate integration or prior knowledge of the OODB itself.

In this article, I'll walk you through the evolution of a simple application from a pure Java app to an OODB-enabled Java app. I'll demonstrate how to create the database on the fly and give you the source code for the whole solution so you can better understand how to tie an OODB into your apps.

First Things First
Before I get to the source code, let's get a few details out of the way:

• The required tools
  
• The design of the system
  
• An introduction to the OODB we'll use for the demonstration

Required Tools
First, I assume you have access to a fairly recent Unix or Windows OS. If you need to duplicate a Unix environment on your Windows machine, you could look into cygwin, although the Windows scripts I have provided run under Windows command prompt configurations (tested only on Windows 2000 and Win95). Table 1 lists all the required tools.

The Design of the System
For our demonstration, I will build a simple online phone book that manages phone entries, allowing query, insertion, update, and delete functionality. Since the migration from a database-independent design to an OODB design is fairly seamless, your system shouldn't be disrupted. The UML diagram shown in Figure 1 is a first stab at the design, before I planned for a specific OODB solution.

Figure 1. The PhoneApp Design Before Employing an OODB

Because the application is such a simple one, the design is not overly elegant. The application runs from the Admin class and the data layer consists of just four classes: Phonebook, PhonebookEntry, PhoneRegion, and PhoneRegionList. All this information should be persistent and managed by some form of database management system. That's where our OODB will come in. (I skipped a business rules layer altogether to keep the demonstration simple.)

As you probably noticed in Table 1, I also decided to use an XML parser. The XMLPhoneEntries class manages parsing and retrieval of phone entries that have been stored in an XML file for batch upload. It uses Xerces-J, a very fast and popular XML parser. (Find more information on XML parsers in my previous DevX article "XML Parsers: DOM and SAX Put to the Test.")

Picking the OODB
Choosing an OODB for this demo was not trivial. No two OODBs work identically and they have major functional differences amongst them. Whereas most relational databases are fairly similar in their functionality, each OODB vendor implements its database product quite differently.

I ended up choosing ObjectStorePSE from ObjectDesign Inc.. ObjectStore is one of the more popular OODBs. It has a fairly compact installation and can be downloaded for a 30-day trial. However, ObjectStore certainly shared some of the OODB disadvantages I discussed in "Object-Oriented Databases Are Worth a Closer Look".

Building the Application

In this Article
Introduction	Creating A Persistent Class
Building the Application	Performing Updates