The first (and likely most common) alternative to using EJB is to write straight JDBC functions. While EJB provides you with many niceties, there are situations in which JDBC makes more sense. The simplest case is when your application is only reading (and not writing) data from a database table in a row-column format (list displays, for example). In this scenario, using EJB would not only be more complex but also quite a bit slower than straight JDBC.

If you are writing only simple rows of data without parent-child or foreign key relationships it may be better to use JDBC—especially if your application is built for a single user working with a single database or multiple users using a single database with little chance of contention while writing (relatively rare writes). This case is a little more ambiguous, because you are writing as well as reading data. But if the way you’re using the database is simple, JDBC may end up being easier.

However, there is one scenario in which people often go with JDBC when EJB might make their lives easier. Say that you have no need of transactional support and the data with which you are interacting does not involve parent-child or foreign key relationships, but you still need to represent that data as an object (potentially in relation to other objects that also represent data). To be more specific, suppose your application handles only contact management. The application may not write data very often and there may be little need for the transactional support or security provided by EJB. However, your application needs to represent contacts (and their affiliated phone numbers, addresses, and so on) as business objects. The ease with which EJB can help you represent this data as business objects, specifically as entity beans, may save a great deal of time.

The situations in which straight JDBC is preferable to EJB are not concrete. You should use straight JDBC when the need for speed outweighs the need for transactional support or security provided by EJB. Here’s a simple example that uses JDBC:

import java.sql.*;
 
public class JDBCExample {
 
 public static void main(java.lang.String[] args) {
   try {
     // Load driver
     Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
   } 
   catch (ClassNotFoundException e) {
     System.out.println("Cannot load driver.");
     return;
   }
  
   try {
     // Connect to database.
     Connection con = DriverManager.getConnection("jdbc:odbc:contactdb",
              "", "");
  
     // Create SQL Statement and execute.
     Statement stmt = con.createStatement( );
     ResultSet rs = stmt.executeQuery("SELECT name FROM contacts");
 
     // Display the SQL Results.
     while(rs.next( )) {
       System.out.println(rs.getString("name"));
     }
 
     // Release database resources.
     rs.close( );
     stmt.close( );
     con.close( );
 
     } 
     catch (SQLException se) {
       // Display error message upon exception.
       System.out.println("SQL Exception: " + se.getMessage( ));
       se.printStackTrace(System.out);
      } 
    } 
}

JDBC is very straightforward; it allows you to access your data repository directly. However, you must understand a fair amount of the underlying mechanics in order to use it (SQL, database connection properties, and so on). Now, in a “real” application using JDBC, you centralize most of this code into a few classes, but you still must write all the SQL yourself.

Java Data Objects or JDO is a recent Sun specification for database persistence and access with Java. According to the JDO specification (JSR 12), its objectives are:

This description sounds very similar to the objectives laid out for JDBC or EJB. Why another specification to allow for database connectivity and use? For one thing, after setting up a mapping file, you need not deal with database information again; you can access data as you would access Java objects. You can edit and delete data using a “persistence manager” (more on this in a moment) that insulates you from having to deal directly with the SQL involved.

But EJB does these things as well. Once you have set up your EJB and created a suitable descriptor file, you deal with the data through the use of the objects representing the data (as opposed to through result sets as in JDBC, for example). However, JDO allows for a simpler mapping (JDO mapping files are simpler than EJB descriptor files); in addition, there’s no mucking about with remote and home interfaces. JDO classes look like any other classes.

There are six basic steps to using JDO in your applications:

The best way to demonstrate this process is through a brief example. We’ll create a very simple Contact class and uses JDO to persist it to a database. We use the LIBeLIS LiDO JDO implementation (community edition). In this implementation, the generation of a database schema involves the use of a separate application from the JDO enhancer:

package com.oreilly.ejb.jdoexample;

public class SimpleContact {
        public String name;
        public String ssn;
        
        public AddressImpl(String pName, String pSsn){
                this.name = pName;
                this.ssn = pSsn;
        }
        
        public String getName( ) {
                return this.name;
        }

        public String getSsn( ) {
                return this.ssn;
        }

        public void setName(String pName) {
                this.name = pName;
        }

        public void setSsn(String pSsn) {
                this.ssn = pSsn;
        }
}

The SimpleContact class contains no details on how the information will be persisted to the database, nor the fact that it will implement the PersistenceCapable interface.

Next, we create a metadata file for SimpleContact, called SimpleContact.jdo:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jdo SYSTEM "file:/c:/work/jdo.dtd">
<jdo>
   <package name="com.oreilly.ejb.jdoexample">
      <class name="SimpleContact" identity-type="datastore">
      </class>
   </package> 
</jdo>

This code is pretty straightforward. The metadata points to the location of the JDO DTD (which you can get from your implementation), the package name for your class, and the name of the class itself.

We’ll assume you compile your SimpleContact.java file to SimpleContact.class. Now you must “enhance” the SimpleContact.class file so that it implements the JDO PersistenceCapable interface like so:

java com.libelis.lido.Enhance -metadata SimpleContact.jdo

This command reads the SimpleContact.jdo file, uses it to find SimpleContact.class, and modifies its bytecodes to implement the JDO PersistenceCapable interface. Next, you can build a schema like this:^[72]

java com.libelis.lido.ds.jdbc.DefineSchema
     -driver org.gjt.mm.mysql.Driver
     -database jdbc:mysql://localhost/jdoexample
     -metadata metadata.jdo

This generates a series of SQL files (not shown) that you can use to generate the database for your SimpleContact data. All that’s left is to create an application that allows you to use your new persistent object. The following class allows you add a new SimpleContact instance to the database:

package com.oreilly.ejb.jdoexample;

import javax.jdo.PersistenceManagerFactory;
import javax.jdo.PersistenceManager;
import javax.jdo.Transaction;

public class Test1 {
    public static final String DBURL = "jdbc:mysql://localhost/jdoexample";
    public static final String DBDRIVER = "org.gjt.mm.mysql.Driver";

    public static void main(String[] args) {
        try {
            // Use a factory class to generate PersistenceManager.
            // You are using the LIBeLIS JDO implementation
            // of the PersistenceManagerFactory and PersistenceManager
            // classes.
            PersistenceManagerFactory pmf = (PersistenceManagerFactory)
              Class.forName("com.libelis.lido.PersistenceManagerFactory")
                   .newInstance( );
            pmf.setConnectionURL(DBURL);
            pmf.setConnectionDriverName(DBDRIVER);
            PersistenceManager pm = pmf.getPersistenceManager( );

            // Grab the current transaction.
            Transaction t = pm.currentTransaction( );

            // Start a new transaction
            t.begin( );

            SimpleContact a =
            new SimpleContact("Gern Blanston", "222334444");
            pm.makePersistent(a);
            // Commit the transaction.
            // All changes made between the begin and 
            // commit are persisted to the DB.
            t.commit( );

            pm.close( );
        } catch (Exception e) {
            e.printStackTrace( );
        }
    }
}

You start by instantiating a PersistenceManagerFactory, which then generates a PersistenceManager for your use. Finally, you create an instance of our SimpleContact class and then tell the PersistenceManager to write it (by committing the transaction begun earlier.

There is much more to JDO than this very simple example demonstrates (such as editing, deleting, and querying using the JDO query language). For more information about JDO, see Java Data Objects, by David Jordan and Craig Russell (O’Reilly). JDO is worth investigating, especially if you have no need for the extra transactional and security features provided by EJB.

While JDO is an alternative to EJB, the context in which it is used must be seriously considered. EJB is designed for high-traffic transaction-centric systems. These types of applications are not a very good fit for JDO because it doesn’t have the enterprise level support for transactions, security, clustering and sessions that EJB does. Smaller systems can frequently be built using JDO, but really big systems are best left to EJB.

There are, of course, other alternatives to EJB than straight JDBC and JDO. Here are a few worth reviewing for suitability, should you determine that your application does not require EJB or that certain requirements (speed, for example) demand an alternative approach.

As you can see, there are several alternatives to EJB. If your application doesn’t need the complexity or some of the features of EJB, take a look around. Data persistence with Java has been around for some time and there is a wide assortment of approaches.