Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

Simplify enterprise Java development with EJB 3.0, Part 2

POJO persistence made easy

By Michael Juntao Yuan, JavaWorld.com, 09/12/05

In Part 1 of this series, I discussed the annotation-driven POJO (plain-old Java objects) programming model in Enterprise JavaBeans 3.0 (EJB). I explained how to develop POJO services, how to deliver container services to POJOs, and how to assemble applications using dependency injection. Those POJO services are typically used to encapsulate an application's business logic. Behind the business logic, most of today's enterprise applications have a data-model layer backed by a high-performance relational database.

In Part 2, I discuss how EJB 3.0 entity beans leverage POJO and annotations to greatly simplify your data model and its persistence-to-backend relational databases. Before we get into the details of EJB 3.0 entity beans, let's first discuss why data modeling and persistence are such big challenges in enterprise Java.

Object-relational mapping (ORM)

Inside the JVM, all data is modeled and encapsulated in a tree of classes and objects. However, in the backend relational database, the data is modeled as relational tables, which are interlinked via shared key fields. Those two different views of the same data represent a difficult challenge for enterprise Java developers: when you must save or retrieve data to or from the persistence datastore, you must convert the data back and forth between the object and relational representations, a process called object-relational mapping (ORM). In Java EE (Java Enterprise Edition, previously called J2EE), you can complete object-relational mapping in two ways:

  • Manually: You can use Java Database Connectivity to handle persistence directly—a straightforward solution for simple applications. The JDBC API's classes are closely modeled after tables, rows, and columns in the relational database. You must manually convert data between the application's internal object model to the JDBC object model. The JDBC approach is best if your application's internal model already resembles 2D relational tables.
  • Automatically: You can delegate the ORM task to a framework. The framework typically provides an API for you to work with arbitrary data objects. Through that API, you can save, retrieve, and search the database. The framework completes the object-relational conversion behind the scenes. Since the relational-specific SQL query does not fit the object interface, the ORM framework typically defines its own query language and automatically generates the correct SQL statements for the current relational database. For applications with complex data models, the framework-based approach could save you a lot of time and reduce errors.


Object database
An object database stores, retrieves, and searches objects directly in the datastore, which could be a good fit for Java applications since no ORM is needed. Unfortunately, today's object database technology remains relatively immature and slow compared with relational databases. You could reasonably say that a good ORM framework essentially provides an object database interface for a relational database. It gives you the best of both worlds.


In this article, I focus on the automated framework approach for ORM in enterprise Java applications. In the next section, I cover several popular ORM frameworks and the key innovations in EJB 3.0.

ORM frameworks

The EJB entity bean is the "official" ORM solution in Java EE. However, in EJB 1.x and 2.x, the entity beans are notoriously difficult to use for two reasons:

  • The EJB 1.x and 2.x entity beans must conform to a rigid component model. Each bean class must implement a home and a business interface. They must inherit from certain abstract classes and implement all methods even if many are empty. Such a rigid component model makes building object-oriented data models from EJB 1.x and 2.x entity beans impossible.
  • The EJB 1.x and 2.x container requires extremely verbose XML configuration files to map the entity beans to tables in the relational database. Those files are tedious and error prone.


In short, the EJB 1.x and 2.x entity bean is a poorly designed ORM framework that addresses the needs of neither the Java object data model nor the relational table data model. Unsatisfied with EJB 1.x and 2.x entity beans, developers look to other solutions for ORM. In the real world, the open source Hibernate (developed by JBoss) and Oracle's TopLink are the two most successful Java ORM frameworks. Both Hibernate and TopLink are POJO-based: they do not rely on any predefined component model. Instead, they take POJO data objects (in simple JavaBeans style) and automatically decipher how to map them, as well as the relationships among them, to relational databases. Usually one JavaBeans class maps to one database table, and relationships between the classes are mapped via foreign key fields in the tables. You can specify ORM metadata, such as the JavaBeans class's corresponding table name and the property's corresponding column name, in a simple and intuitive XML configuration file. You operate on those POJOs (e.g., saving, retrieving, and searching) via a utility class in the framework (e.g., the Session class in Hibernate).

The EJB 3.0 entity bean builds upon the ideas and success of Hibernate and TopLink. It provides a standard POJO ORM framework for Java EE. In addition, EJB 3.0 has two crucial innovations over existing POJO persistence solutions:

  • Instead of using XML files to specify ORM metadata, EJB 3.0 allows developers to annotate the mapping information directly in the POJO code. For instance, you can use annotations to specify the corresponding relational column name for each JavaBeans property. You will see more examples later in this article. Annotations make the mapping more intuitive and easier to maintain.
  • EJB 3.0 defines a new archive format for entity beans. Each archive defines a persistence context, with an independent set of configurations for the backend database and the ORM behaviors. I will discuss the persistence context later in this article.


Now, let's check out how EJB 3.0 accomplishes POJO ORM via several simple examples.

1 | 2 | 3 | 4 |  Next >

Discuss

Start a new discussion or jump into one of the threads below:

Subject Replies Last post
. Stolen article
By Anonymous 		2 10/05/06 08:10 AM
by Anonymous
. Too little too late..
By Anonymous 		2 10/05/06 03:37 AM
by Anonymous
. Annotations = fancy hard-coding
By Anonymous 		7 10/04/06 10:14 AM
by Anonymous
. EJB3
By Dahrmaraja 		0 10/04/06 07:12 AM
by Anonymous
. Simplify enterprise Java development
By JavaWorldAdministrator 		1 10/03/06 01:44 PM
by Anonymous


Resources