E-mail    Print       Blog

Adopting a Java Persistence Framework: Which, When, and What?

For developing new software systems, Object-Oriented Programming is undeniably the most widely used programming paradigm today. For commercial data persistence needs, the Relational Database Management System (RDBMS) is the most widely used system of choice. RDBMSes use a relational model, which is different than the domain object model of the software system. When your software system is developed using an object-oriented programming language and data persisted in RDBMS, a data persistence framework can be a very critical and important component of your application architecture to hide the underlying complexity of application data persistence.

Over the years, several persistence frameworks have evolved that help you manage your object-relational mapping and data persistence needs. Selecting a framework that suits your requirements is, however, not a trivial task, because several factors influence this decision. In this article, I intend to discuss some of the more widely used Java persistence frameworks against three fundamental criteria: Which, When, and What. In Which, I will introduce a framework; in When, I will discuss some of the scenarios when should you consider adopting it and some scenarios when should you look for an alternative; and finally, in What, I will discuss what benefits and what liabilities the framework has if you decide to adopt it. Let's begin with the following frameworks that are best known in the Java persistence landscape.

• Entity Enterprise Java Beans
• Java Persistence API
• Hibernate
• TopLink

Let me discuss these frameworks in more detail.

Entity Enterprise Java Beans

Enterprise JavaBeans (EJB) technology is a managed, server-side component architecture for the Java platform, Enterprise Edition (Java EE). In this definition, "managed" and "server-side" are the key terms. In EJB architecture, an application server manages the lifecycle of one or more deployed EJBs and provides common runtime services via an EJB container. Security, concurrency control, transactions, and persistence management are a few examples of container-provided services.

The EJB specification categorizes three types of enterprise beans: Session, Entity and Message Driven. Each type has some distinct characteristics and is used for different purposes. Since this article is about Java Persistence frameworks, let me briefly discuss the persistence aspect of the EJB architecture, which involves using Entity EJBs to manage the persistence requirements of your Enterprise Java application.

With EJBs, you can design your application such that an EJB represents an entity in your business domain model. For example, think about an Account entity of a commercial banking application. The Account entity bean will be deployed into the J2EE application server that will provide several runtime services to this entity bean via the EJB container. One such service is automatic persistence, which I will discuss in bit more detail.

Based on how the persistence is achieved, Entity EJBs are further classified into two categories: Bean-Managed Persistence (BMP) and Container-Managed Persistence(CMP). With BMP, the bean instance is responsible for persistence of its state, which is achieved by JDBC code. With Container-Managed Persistence, the EJB container provides the ability to automatically manage persistence of entity beans: saving the state to or loading the state from the underlying database as and when needed.

Now let's discuss some scenarios where you may want to adopt EJB framework in general and use CMP for data persistence in particular.

When to Consider Adopting EJB as Persistence Framework

1. The need for container-provided services is the first thing you should consider. If your application needs other container-provided services such as transaction management, security, and concurrency control in addition to persistence management, then the EJB framework is a better choice.

2. Resource requirement is another factor to consider. The EJB framework provides excellent scalability for demanding applications. This, however, comes with a price: intensive resource requirements, especially with the remote interface model. Consider adopting entity EJBs only if there is no resource restriction, to achieve the required level of performance.

3. A de facto framework is another factor in play. If you are doing some serious EE development based on the Java platform, then chances are that the EJB container is already available as part of your application server. "Why not use what is already available?" might be the first question asked in your architectural decision-making process. I consider this as a "political" advantage over other frameworks, because it is already available.

When to Consider an Alternative to EJB as Persistence Framework

1. The feature requirements of the persistence layer is the first factor that may prompt you to look for an alternative. If your application does not require every feature an EJB framework provides, then that is the first indication that you should look for an alternative.

2. Resource availability outweighing performance requirements is another situation in which you may want to look for another alternative. Although it provides excellent performance and scalability, the EJB framework is notorious for resource consumption. But the bottom line question is: do you really need this? A well-written data access object or the Hibernate framework will provide an excellent alternative to EJB in many situations.

3. A data source other than a relational database, although rare, would prevent you from using a container-managed persistence framework.

If you are already using or plan to use EJBs as your persistence framework, here are the benefits and liabilities you can expect.

What Are the Entity EJB Benefits?

1. The distributed component-based model makes it network-neutral--the EJB components can be deployed in the same JVM that serves the rest of the application, or in the JVM of an application server located in a different geographical location.

2. You will achieve excellent scalability: EJBs scale up nicely because the container can pool the instances, activating and passivating if necessary.

3. The EJB has been around for long enough to mature as a proven technology. Also, it has evolved to provide more useful services and features. For example, the timer service is one of my favorites; with it, you can schedule the execution of a job in specific intervals (such as nightly, weekly, or monthly). Another nice feature in EJB 3.0 is Java language metadata annotations support that eliminates all required interfaces for entity persistence, and enhancements in EJB's query language.

What Are the Entity EJB Liabilities?

1. The EJB architecture is non-trivial to learn and use. You should prepare to learn terms like remote interface, home interface, activation, passivation, and so on, most of which are applicable only to the EJB world.

2. The EJB architecture does not provide persistence independence. Since the classes are used in their own way within an EJB container, there is no easy way you can take EJB classes and use them in another framework.

3. Achieving an acceptable level of performance for entity beans has always been a challenge, especially in the remote interface model.

Java Persistence API

Right from the time when EJB technology became available for adoption, there has been general sense of skepticism on its usefulness in real-world applications. In my view, complexity and resource intensiveness are two of the most important reasons for this phenomenon. Consequently, simpler frameworks that have a smaller resource footprint, like Spring and Hibernate, appeared later than EJB but gained popularity more quickly. To address this, we have witnessed a major shift in the direction of EJB 3.0 specification from its predecessors. Created as part of JSR 220, this specification provides features like Plain Old Java Object (POJO) support, dependency injection, and annotations. A completely new set of APIs are now introduced as the Java Persistence API (JPA) to allow developers to manage relational data from Java EE (or even SE) applications. Further, Sun claims that the Java Persistence API draws some of the best ideas from the Hibernate, TopLink (both discussed later), JDO, and EJB frameworks.

Currently, the GlassFish project provides a reference implementation of the JPA as "TopLink Essentials," part of the GlassFish application server. You can find the JPA reference implementation on the GlassFish community page. Do not confuse TopLink Essentials with TopLink, which is the relational mapping tool currently owned by Oracle Corporation. I will discuss the TopLink framework later in this article.

Let's discuss some of the scenarios in which you should consider adopting JPA as your persistence framework.

When to Consider Adopting JPA as Persistence Framework

1. You prefer to adopt a standards-based framework with "nice to have" features from popular frameworks like Hibernate, TopLink, and EJB.

2. You need a lightweight persistence framework and don't necessarily need EJB's container-provided services.

3. You need a persistence framework that can be used in a standard or enterprise Java application.

When to Consider Alternatives to JPA

1. The version of Java that you are using determines if you can actually adopt JPA. JPA is part of the EJB 3.0 specification, which is part of the Java EE 5 release. If you are not up to Java EE 5, it is not possible to use JPA.

2. Your application requires services that JPA cannot provide, such as those provided by an EJB container, in which case you are pretty much tied to EJB.

Before ending discussions on this framework, let me list some benefits and liabilities of using JPA as your persistence framework.

What Are the JPA Benefits?

1. JPA is standards-based. More and more vendors are expected to offer the JPA implementation in the near future.

2. It offers the best features from Hibernate and TopLink.

3. It can be used with both Java SE and Java EE applications, with or without an EJB container.

What Are the JPA Liabilities?

1. Being fairly new, the JPA specification may go through significant evolution before becoming stable.

2. JPA is a specification instead of a product. You need a vendor to provide an implementation to get meaningful advantages from these standard-based APIs.

Hibernate

Hibernate is an object persistence framework that simplifies object-relational mapping between a Java application and an underlying relational database. It does so by providing transparent persistence of POJOs, working as a "mediator" layer to provide automatic persistence and loading of objects from a Java application to database tables. With Hibernate, saving object state to and loading object state from a database is as easy as calling methods in Java objects. You don't have to manage low-level database operations from your application code; the Hibernate framework takes care of all the intermediate steps for you.

Let's discuss some of the scenarios where you would consider adopting Hibernate as your persistence framework and those in which you should look for an alternative.

When to Use Hibernate as Your Persistence Framework

1. You are looking for a simple persistence framework that is easy to learn and use. You just need to understand a couple of mapping configuration files before you can actually start persisting your Java objects into the target database.

2. You are looking for a highly generic and flexible persistence framework. Hibernate is pretty flexible in terms of its usage: it can be used with or without an application server, and with or without relational database systems.

3. You don't want to pay acquisition and maintenance fees. Hibernate is open source and free.

The Hibernate framework is very compelling for adoption because it is simple and flexible, yet powerful. However, here are some scenarios when you may want to consider adopting a different framework.

When to Consider an Alternative Framework to Hibernate

1. You don't want yet another framework. Although simple, the Hibernate framework has its own learning curve, maintenance/upgrade cycle, and so forth.

2. You need container-provided services, such as those provided by EJB, in which case your choices are pretty much limited to EJB.

If you are using or plan to use Hibernate as your persistence framework, here are some of the benefits and liabilities.

What Are the Hibernate Benefits?

1. Hibernate is easy to learn and use. As I mentioned earlier, you just need to understand a couple of simple, self-described configuration files before before you can use it.

2. It is very flexible. You can use Hibernate in any application architecture that needs persistence service. You can use it in standard Java applications, in Enterprise Java applications with servlets, and/or with Enterprise Java Beans. It also integrates very nicely with the Spring framework.

3. It scales up pretty well, as it was designed from the ground up to work in a cluster environment. The performance of the latest version of Hibernate is also enhanced by techniques like lazy initialization and optimizing Java reflection via the CGLIB runtime byte code generation library.

What Are the Hibernate Liabilities?

1. Hibernate is another framework that has its own adoption and maintenance cycle.

2. Although active community support is available, sometimes the absence of a single vendor who specializes in the product makes it difficult to influence architectural reasons to adopt this framework.

TopLink

TopLink is another object-relational mapping framework for Java that provides a powerful and flexible framework for storing and loading Java objects to and from databases and XML documents. After several mergers and acquisitions (see a brief history on TopLink's Wikipedia page), TopLink has been part of the Oracle Fusion middleware since 2002.

In 2006, Oracle donated source code from the TopLink product and development resources to the java.net GlassFish project. This project was named TopLink Essentials and became the Java EE EJB 3.0 JPA reference implementation. It is a scaled-down version of the TopLink product from Oracle, missing some features such as cache synchronization between clustered applications, cache validation policy, and query cache. Also in 2007, Oracle donated the source code from the TopLink product and development resources to the open source EclipseLink project.

Here are some scenarios in which you may want to adopt TopLink as your persistence framework and some of the scenarios where you may want to look for alternatives.

When to Adopt TopLink as Persistence Framework

1. Although TopLink can be adapted to work with other software systems, it is a better choice if your software systems have a substantial presence of Oracle software products, because this creates a homogeneous software product suite from same vendor.

When to Consider Alternatives to TopLink as a Persistence Framework

1. You are a non-Oracle shop. If you have only a few software systems from Oracle, then you may have several other options more suited for your needs. This may be fairly typical for EE-based application servers because at the time of this writing, WebSphere, JBoss, and WebLogic are the top three leading application server vendors in terms of market share.

Let's finally evaluate some benefits and liabilities of adopting TopLink as your persistence framework.

What Are the TopLink Benefits?

1. TopLink is the ideal persistence framework choice if your chosen software lineup already has a substantial presence of Oracle products.

2. It is a pretty mature and time-tested framework, supported by Oracle.

3. Advanced features such as cache synchronization between clustered applications, cache validation policy, and query cache makes it suitable to adopt in applications that are clustered and require high performance.

What Are the TopLink Liabilities?

1. It is proprietary; its future direction is dictated by Oracle.

2. As with any new framework, it has its own learning curve.

Persistence Frameworks Selection Matrix

Before moving forward, let me summarize in the following table the frameworks discussed so far. In it you will see a general context (When), the framework you should consider (Which), and the benefits and liabilities you get (What). You should consider these as the starting points for the process of selecting persistence framework. Your final selection should be based on these and other application-specific requirements, if any.

Other Persistence Frameworks

Before summarizing, let me list some other persistence frameworks worth exploring before you actually adopt one. More detailed discussion on these frameworks is beyond the scope of the article.

• Castor: A free open source data binding framework.
• Kodo: An object-relational persistence engine from BEA Systems.
• Torque: An object-relational mapper for the Java platform, developed as an Apache DB project.
• iBatis: A data mapper framework that can be used with both Java and .NET applications.

Summary

It is obvious that which persistence framework you will adopt for your next Java application will be influenced by several factors such as features required, acquisition and maintenance costs, and non-functional requirements (its maintainability, performance, etc). Several proprietary and open source frameworks are now available, each with its own advantages (benefits) and liabilities (weaknesses).

In this article, I've presented some of the more popular Java persistence frameworks in terms of three criteria: which (defining the framework), when (when should you consider adopting and when should you look for an alternative), and what (what are the benefits and liabilities) of adopting it. The scenarios presented in this article are intended to assist you make a more informed decision before you actually select a framework for adoption. Therefore, you should adopt your next Java persistence framework based on the criteria discussed in this article in addition to other current and future needs specific to the application.

Resources

• A Comparative Study of Persistence Mechanisms for the Java Platform (PDF)
• JSR 220
• EJB product page
• Hibernate.org
• Java Persistence API
• TopLink Product page
• "BZ Research on Java EE Market Share Data"

Sharad Acharya has more than eight years of experience in the software engineering field in multiple business domains including supply chain, insurance, banking, and mortgage.

View all java.net Articles.