Data Access Options

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 JDBC API

• Object/Relational mapping tools

• Entity beans

• Java Data Objects

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

• Establish database connections

• Execute SQL statements

• Invoke database-stored procedures

• Process database results

• Achieve a degree of portability between different database products

Here are some of the main advantages of using a JDBC driver for database access:

• Most Java developers are familiar with the JDBC API.

• Developers skilled in SQL and relational database technology can construct highly optimized SQL statements.

• JDBC drivers are available for all major DBMS products.

• JDBC resources are managed by the J2EE server.

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 process of writing code to map objects to a relational database is time consuming and error prone.

• Embedding SQL within Java code results in a brittle data access layer that is easily broken by database schema changes.

• The writing of highly optimized SQL statements is a skill not all Java developers possess.

• Poorly written SQL statements can have a catastrophic effect on database performance.

• Although the JDBC API is common between DBMS products, SQL syntaxes vary to the degree that JDBC data access code is not portable between databases.

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:

• Increased developer productivity, as the O/R mapping tool generates the JDBC calls necessary for object persistence

• A flexible persistence layer, as database changes can be reflected in the application by regenerating all data access code

• Simpler software architectures, as the persistence concern is handled by the O/R mapping tool

• Better system performance, as the generated data access code is optimized for the target DBMS

• The ability to operate both outside or inside the confines of a J2EE server, applicable to both the EJB and Web containers

• Portability, as the SQL generated by the O/R mapping tool can target a specific DBMS

Tip

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

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:

Bean-Managed Persistence (BMP).

BMP entity beans rely on the developer implementing framework methods on the bean, such as ejbLoad() and ejbStore(), for managing data access. Typically, data access code takes the form of calls to the JDBC API.

Container-Managed Persistence (CMP).

CMP is a form of rudimentary O/R mapping that sees the EJB container take on the responsibility for access to the data source. CMP was introduced as part of the EJB 1.1 specification, but unfortunately, the technology was not adequately specified to a workable level until version 2.0 of the EJB specification was released. It is now recommended that entity beans developed for the EJB 2.0 and 2.1 specifications use CMP in preference to BMP.

Here is a list of some of the main benefits entity beans offer as an object-persistence mechanism:

• They are a mandatory part of the EJB specification and are supported by all compliant J2EE servers.

• Entity beans are well supported by development tools.

• They provide higher performance through instance pooling.

• Management of the lifetime of an entity bean instance is the responsibility of the J2EE server.

• Entity beans can survive a server crash.

• The J2EE server manages access to shared entity bean instances from multiple threads.

• As Enterprise JavaBeans, entity beans offer declarative support for security and transactions.

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 CMP O/R mapping functionality offered by entity beans is limited when compared to mature O/R mapping tools such as TopLink and CocoBase.

• It is not possible to model the inheritance relationship.

• Entity beans, like all enterprise beans, are heavyweight components and require considerable amounts of framework code (boilerplate).

• Components are more suited to business objects than persistent domain model objects.

• Entity beans are complex to develop and do not align with the domain model, especially if inheritance is involved.

• Entity beans cannot be tested outside of the container.

• Developers have found enterprise beans difficult to work with.

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.

Note

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:

• It provides a standard Java-centric API for true transparent object persistence.

• JDO implementations support the inheritance relationship.

• JDO persistent classes run both inside and outside of a J2EE server.

• A JDO enhancer can add data access code for persistence to standard Java objects (or plain old Java objects, POJOs) at the bytecode level.

• JDO implementations offer access to EIS persistence resources via the J2EE Connector Architecture on the J2EE 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.