When it comes to implementing a persistence layer, J2EE application developers seem to be spoiled for choice, with an almost bewildering range of data access technologies available. This section provides an overview of some of the more common mechanisms employed on projects for implementing one of the most important layers in the application:
The foundation of all these technologies is the JDBC API, which we discuss first.
Java Database Connectivity (JDBC)
The ability to write code for data access using the JDBC API is a skill most Java developers possess. JDBC enables us to communicate directly with the database, pushing and pulling information to and from the relational world into that of the object-oriented, forming a bridge between the two paradigms.
The strengths of JDBC lie in its popularity, as it is perhaps the most common method of database access for Java applications. By coding to the JDBC API, developers can
Here are some of the main advantages of using a JDBC driver for database access:
JDBC enables the use of SQL as a domain-specific language for simplifying data manipulation with convenient and easily understandable language constructs. With a suitable database driver, the developer has the option of constructing SQL statements within the code and executing them against the database at runtime.
This approach, in addition to being time consuming and error prone, is very sensitive to database change. Changes to table names, column names, or the order of columns within a table require the data access code to be updated. Worse still, differences between data access code and the database schema are only detected at runtime, as embedded SQL statements are not validated at compile time. The careful use of stored procedures is one method of alleviating the impact of the runtime detection issue.
Some of the problems associated with the use of the JDBC API for object persistence include the following:
The next sections look at database access technologies that use JDBC as a base but attempt to avoid some of these pitfalls.
Object/Relational Mapping Tools
One technology that has grown in maturity and sophistication in recent years is object/relational (O/R) mapping. Mapping tools offer a method of storing an object-oriented domain model transparently to the database without the need to write a line of JDBC data access code or SQL.
The task of persisting an object's state is handled by the O/R mapping product, which generates the JDBC calls on our behalf. All that is required of the developer is to specify, usually via an XML-based configuration document, the mapping rules for a particular class. Based on the rules in the configuration document, the O/R mapping tool undertakes all data access, leaving the developer free to concentrate on implementing critical business functionality within the application instead of writing boilerplate data access code. Defining the mapping rules can be done by hand but is more commonly generated by the O/R mapping tool.
The benefits of O/R mapping technology include these:
The ability to operate O/R mapping tools outside of the J2EE server has excellent implications for evolutionary prototyping.
For example, a persistence layer can be used either as part of a prototype built as a Web application, using only the Web container, or as part of a two-tier application developed using Swing for the GUI.
The persistence layer for either prototype scenario can then be evolved to an EJB architecture by having session beans make use of the O/R mapping tool.
During this chapter, we look at an example of an open source O/R mapping tool. First, let's look at two Java technologies that build on the services of the JDBC API, but with an O/R mapping approach to object persistence.
Entity beans are a form of O/R mapping technology and are a member of the Enterprise Java-Beans family. Entity beans provide an object-oriented view of business domain model entities held in persistent storage, where persistent storage can be either a database or an existing application. By providing a wrapper around the underlying data, entity beans attempt to simplify the process of data access and retrieval. Entity beans are a core part of the EJB specification and so can be considered the official persistence layer for J2EE applications.
An entity bean is a shareable, in-memory representation of a row in a database table. The combination of being both shareable and in-memory allows entity beans to operate as a caching mechanism for application data. The responsibility of controlling concurrent access to the cached data in the bean and refreshing or writing the cache when needed is the responsibility of the EJB container. The EJB container also safeguards the state of an entity by ensuring it can survive a server crash.
While the EJB container manages the state of an entity bean and ensures support for concurrent access, the mechanism by which the underlying row in the database is accessed and updated is the responsibility of the developer. The decision as to how data access is managed is dictated by two different flavors of entity bean:
Here is a list of some of the main benefits entity beans offer as an object-persistence mechanism:
Although the inclusion of entity beans within the EJB specification would seem to make them the persistence technology of choice, the reaction of developers to the merits of entity beans has been less than favorable. Some of the complaints raised regarding entity beans include these:
The hostile reaction of the Java community to entity beans has seen other technologies spring to the fore. One such technology is Java Data Objects.
Java Data Objects
Somewhat confusingly, Java also has a second O/R mapping technology that competes with entity beans. Java Data Objects (JDO) is a specification defined under the Java Community Process by JSR-012, Java Data Objects. A second iteration of the JDO technology is currently under review, which is covered by JSR-243.
Find the JDO specifications for JSR-012 and JSR-243 at http://jcp.org/en/jsr/detail?id=012 and http://jcp.org/aboutJava/communityprocess/edr/jsr243/index.html respectively.
The JDO specification has a set of objectives similar to O/R mapping products in that the stated aim of the technology is to provide Java developers with a transparent Java-centric view of persistent information residing in a variety of data sources.
The scope of JDO is wider than providing a purely object/relational mapping technology. JDO implementations cover a range of data storage mediums, including object databases and enterprise information systems. In this way, JDO provides an object view of persistent storage regardless of the underlying persistence technology, whether relational, object-based, or otherwise.
Here are some of the main features and benefits JDO technology brings to the Java platform:
Unfortunately, the JDO specification has failed to strike a chord with O/R mapping tools vendors, presumably because products such as CocoBase from Thought Inc. and TopLink from Oracle have already carved themselves a sizeable market niche.
The JDO architecture also faces an uncertain future. The first draft release of the EJB 3.0 specification under JSR-220 announced that the next incarnation of the EJB architecture would provide yet another standard for a Java O/R mapping technology.
Since that time, Sun Microsystems has announced that as both the EJB and JDO specifications are undergoing further revision under the Java Community Process, members of both the JSR-220 and JSR-243 Expert Groups will collaborate to define a single specification for providing transparent Java object persistence. Only time will tell what this move means for the future of JDO and entity beans.