email article printer friendly

Leverage Today's JDO for Tomorrow's EJB
Compare and contrast promised features of EJB 3.0 with those that are mature and available in the JDO 2.0 specification
by Robert Greene

February 24, 2005

Few among us can discount the impact of the Java 2 Platform, Enterprise Edition (J2EE) on application programming and deployment in IT infrastructures. Companies investing in this Java-based technology need to keep pace with this specification to obtain the scalability and flexibility they've been promised with their investments. The changes coming in the new Enterprise JavaBean (EJB) 3.0 specification for J2EE are substantial but essential for addressing the productivity and scalability concerns that have kept the critics ranting about the difficulty in using these platforms.

Let's take a look at these EJB 3.0 changes by providing a perspective on how they overlap with the Java Data Objects (JDO) 2.0 specification. You'll want to be ready to adopt the new EJB 3.0 specification when it reaches the maturity required for your production applications, and you can do that by leveraging the mature JDO standard today. Recent announcements from the specification leads of both JDO and EJB indicate that these two groups are now combining to provide a common API for Java persistence that addresses needs both inside and outside of the application server container.

It is worth noting that as of this writing the new EJB 3.0 specification is not complete and is in early draft review. There will be many clarifications of the proposed changes in behavior as the specification matures. However, one change in the new EJB 3.0 specification stands out fundamentally. The EntityBean is no more—well, at least in spirit. For obvious reasons there will be some continued support until organizations can switch over to the Plain Old Java Object (POJO) model of persistence.

Airy Persistence
The major goal of the EJB 3.0 specification is to provide a simpler persistence mechanism that is more aligned with the proper use of Java as an object-oriented language. The newer, lighter-weight persistence mechanism, POJO persistence, is an approach that will eliminate the heavyweight interfaces associated with EntityBeans and facilitate the use of object models found in today's model-driven designs. The plain old Java object behaves in a persistent way and adheres to the transactional semantics of a database application.

This POJO approach proposed in EJB 3.0 is the same approach that JDO has taken since its inception in 1999. This point, along with JDO's proven maturity and acceptance as a scalable, flexible persistence solution in the Java community, is what is driving these two initiatives together. Let's take a look at the specific features proposed in the EJB 3.0 draft and note how these coincide with features in JDO 2.0.

Key to the elimination of the EntityBean is the introduction of an object that is responsible for the life-cycle management of the domain objects exhibiting persistent characteristics. This new interface in the EJB 3.0 specification is referred to as the EntityManager. The EntityManager will be responsible for tracking the state of POJO objects that are persistent within the context of a database transaction. The EntityManager wraps a JDBC connection or data source and interface with the application server's transaction manager to achieve a unified transactional context across all POJO accesses. The application server will pool these EntityManagers just as it now pools data sources and JDBC connections.