JDBC, JNDI, and EJBs

It seems like JDBC (Java DataBase Connectivity API) has been with us since the dawn of time. It's the reliable old guy who's sitting in the corner smoking his cigar that nobody thinks about any more. But it wasn't always this way. I clearly remember wrestling with so-called “standard” features of JDBC back in 1997. Even getting the JDBC driver to connect to the database was a delicate balancing act and still can be. But assuming your JDBC driver is properly configured, you can be reasonably assured that your Java code can get stuff out of your database and put stuff back in.

JDBC 2.0 went one step beyond the previous version of JDBC in a number of ways, most notably by allowing advanced data types and access to databases through the new Java Naming and Directory Interface (JNDI).

JNDI

Another four-letter acronym beginning with J, and it won't be the last. I wonder why these guys can't come up with more creative names for their specifications, like Viper or Crucible?

Anyway, JNDI, despite its prosaic moniker, is actually exciting because it abstracts the part of your application that requests and instantiates the actual JDBC connection. When you're building J2EE applications, your building blocks are EJBs. These EJBs sit inside containers that are implemented by whatever application server your EJBs are executing in. EJB containers implement an abstraction layer, called the Environment Naming Context (ENC), so that your beans can happily go about their business (encapsulating business logic or representing specific real-world objects) without having to worry about questions like “What kind of JDBC driver am I supposed to be using, and where do I get it?” Your EJB can use JNDI to ask the ENC for a connection to the JDBC data source hooked up to your J2EE application server (there will be a quiz on this later) by implementing a method like the following:

  private Connection getConnection()
         throws SQLException {

     InitialContext jndiContext = new InitialContext();
     DataSource source = (DataSource)
           jndiContext.lookup("java:comp/env/jdbc/myDatabase");
     return source.getConnection();
     }

In this example, we're looking up the connection to a database and returning that connection. The difference with JNDI is that you can ask the application context for the connection, and it'll return the most appropriate connection as set up in that context. This means that your code doesn't have to worry about it; it can all be configured within the application server. With straight JDBC, you have to specify the driver and a hard-coded URI to a particular database, so what JNDI gives you is code portability for the code modules that you write.

Bean Persistence

The amount of work this abstraction layer can do for you depends on what your application server supports. For instance, some application servers support container-managed persistence of EJBs, which means that you never write a line of JDBC code. The EJB container manages all your database activity for you. Call me old-fashioned, but this level of abstraction makes me a little squeamish, especially when I start to think about performance tuning.

With bean-managed persistence, the EJB code you write manages synchronizing its state with the database as directed by the container. You can use JDBC to read from and write to the database, but the EJB container tells your bean when to do each synchronization operation. Bean-managed persistence gives you more flexibility and makes more sense when you're talking about building beans that access partially decomposed XML.

The example entity EJB presented previously uses bean-managed persistence. In that example, the bean populated some fields by simply performing a SQL select through JDBC to get the title of the document from one of the partial decomposition tables. However, the get method for the body might first extract the whole XML instance, then parse it, and finally return the result of a XSLT transformation. In order to implement the example described previously (in the section Building Java Objects for XML Instances with DOM), you need to use bean-managed persistence.

JDBC Advanced Data Types

Advanced data types mean that JDBC now supports all the kinds of data types defined in the SQL:1999 specification. Most notable among these data types are the CLOB (Character Large OBject ) and BLOB (Binary Large Object) types, the array type, and more structured types. CLOBs are important because the CLOB type is perfect for storing large XML documents. If you don't know how big your XML documents are going to get, then use CLOB data types. Using Arrays and Structs can help you take care of sophisticated logic inside the database (assuming you have a database that can support it). For instance, you can request a movie review from your database and have it return a Struct, which can encapsulate the XML document itself, the title, the abstract, the author, and an array of the links contained in the text (all extracted via individual selects from partially decomposed data in SQL tables). Then you could hold that in memory and parse the XML document, only if it's actually needed.

The benefit of advanced data types is efficiency: The alternative is to make several selects from your application to the database so what JDBC advanced data types give you is a layer of abstraction that simplifies how your application interacts with the database.

On the Near Horizon: XML Data Binding

An interesting up-and-coming specification, still being worked on at this writing, is XML data binding. The idea is to be able to suck in an XML Schema and automatically generate a set of Java classes to deal with XML data of that format. This specification and framework promises to provide an abstraction layer on top of your XML data. If you plan on building a Java framework for managing your XML documents, you should take a serious look at XML data binding.

For more up-to-date information on using XML in Java (and specifically within the J2EE framework), go to JavaSoft's page on XML at http://java.sun.com/xml/.