Sharad Acharya takes a comparative look at JPA, Entity EJBs, Hibernate, and TopLink, to help you understand which is right for your needs.
Java persistence frameworks compared
Java programmers have a number of persistence frameworks to choose from, and far from being redundant, each is based on significantly different beliefs, assumptions, and ideal use-cases. In this article, Sharad Acharya takes a comparative look at JPA, Entity EJBs, Hibernate, and TopLink, to help you understand which is right for your needs.
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
Let me discuss these frameworks in more detail.
Entity Enterprise Java Beans
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
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.
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
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
When to Consider Adopting EJB as Persistence Framework
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.
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
interface model. Consider adopting entity EJBs only if there is
no resource restriction, to achieve the required level of
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
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.
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.
A data source other than a relational database, although rare,
would prevent you from using a container-managed persistence
If you are already using or plan to use EJBs as your persistence
framework, here are the benefits and liabilities you can
What Are the Entity EJB Benefits?
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.
You will achieve excellent scalability: EJBs scale up nicely
because the container can pool the instances, activating and
passivating if necessary.
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?
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.
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.
Achieving an acceptable level of performance for entity beans
has always been a challenge, especially in the remote interface
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
"http://jcp.org/en/jsr/detail?id=220">JSR 220 , this
specification provides features like
"http://en.wikipedia.org/wiki/POJO">Plain Old Java Object
(POJO) support, dependency injection, and annotations. A completely
new set of APIs are now introduced as the
Persistence API (JPA) to allow developers to manage relational
data from Java EE (or even SE) applications. Further, Sun
that the Java Persistence API draws some of the best ideas from
the Hibernate, TopLink (both discussed later), JDO, and EJB
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
"https://glassfish.dev.java.net/">GlassFish community page . Do
not confuse TopLink Essentials with TopLink, which is the relational
mapping tool currently owned by
Corporation . I will discuss the TopLink framework later in this
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
You prefer to adopt a standards-based framework with "nice to
have" features from popular frameworks like Hibernate, TopLink, and
You need a lightweight persistence framework and don't
necessarily need EJB's container-provided services.
You need a persistence framework that can be used in a standard
or enterprise Java application.
When to Consider Alternatives to JPA
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.
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
What Are the JPA Benefits?
JPA is standards-based. More and more vendors are expected to
offer the JPA implementation in the near future.
It offers the best features from Hibernate and TopLink.
It can be used with both Java SE and Java EE
applications, with or without an EJB container.
What Are the JPA Liabilities?
Being fairly new, the JPA specification may go through
significant evolution before becoming stable.
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 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
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
When to Use Hibernate as Your Persistence Framework
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.
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.
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
You don't want yet another framework. Although simple, the
Hibernate framework has its own learning curve, maintenance/upgrade
cycle, and so forth.
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?
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.
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.
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
initialization and optimizing Java reflection via the
"http://cglib.sourceforge.net/">CGLIB runtime byte code
What Are the Hibernate Liabilities?
Hibernate is another framework that has its own adoption and
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
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
"http://en.wikipedia.org/wiki/TopLink">TopLink's Wikipedia page ), TopLink has been part of the Oracle Fusion middleware since
In 2006, Oracle donated source code from the TopLink product and
development resources to the java.net
"https://glassfish.dev.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
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
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
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?
TopLink is the ideal persistence framework choice if your chosen
software lineup already has a substantial presence of Oracle
It is a pretty mature and time-tested framework, supported by
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?
It is proprietary; its future direction is dictated by Oracle.
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.
"Persistence Frameworks Selection Matrix">
(If your application needs)
(You will get these benefits)
(You will get these liabilities)
|Java Persistence API
||Simple persistence framework for standard or enterprise Java
- It is standards-based
- It incorporates several "nice to have" features from other
- It is a specification: you need to adopt an implementation from a
- It cannot be used with versions of Java earlier than 5.0
|Container-managed Entity EJB
||Container-provided services such as security and transaction
management, in addition to persistence management
- Distributed component-based
- Nice scalability
- Complex to learn and use
- Less flexible
||You want a simple, flexible framework
- No acquisition or maintenance fees
- Integrates nicely with other frameworks
- Easy to learn and use
- Flexible: can be used with or without EJBs, in standard or
enterprise Java applications
||Your software systems already use a substantial amount of
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
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
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.
Comparative Study of Persistence Mechanisms for the Java
- JSR 220
- EJB product
"http://www.oracle.com/technology/products/ias/toplink/index.html">TopLink Product page
Research on Java EE Market Share Data "
width="1" height="1" border="0" alt=" " />