A comparison of Java Data Objects and EJB
data management, Part 2)
Consultant, Gabhart Consulting
Last month's pathfinder introduced J2EE's
technologies for data persistence: entity beans, JDBC, and Java Data
Objects (JDO). Turning the focus away from the more established JDBC and
EJB technologies, Enterprise Java expert Kyle Gabhart puts the bright
lights on JDO. While it's a relatively immature technology, you'll find
that JDO offers some unique benefits.
Application components fulfill requests for business services. To
fulfill these requests, they often must change the state of the underlying
datastore. It is imperative that those changes do not compromise the
integrity of the persistent datastore. (In the first
article on data persistence, we defined a persistent datastore
as an independent data repository capable of preserving its data even in
the event of a server crash or network failure.) To ensure persistence,
application components must be capable of handling concurrency, connection
management, data integrity, and synchronization. All three of J2EE's data
management technologies handle these functions for the developer, although
each one has its own way of doing so.
Last month we explored the pros and cons of entity beans versus JDBC.
This month we'll see how Java Data Objects can be combined with stateless
session beans and how that solution compares with the standard entity bean
application. Since JDO is still a rather new technology (the youngest of
J2EE's persistence solutions), we'll start with an overview of how it
Historically, the relationship between Java applications
and persistent data management has been awkward at best. Many persistence
mechanisms store data in a relational way rather than an object-oriented
way. That is, data is stored in tables consisting of records with fields,
rather than as self-contained objects that possess internal data and
references to other objects, also possessing internal data and references.
Translation from an object-oriented representation to a relational one has
traditionally been cumbersome, error prone, and degrading to application
performance. Until recently the few persistence mechanisms that weren't
relational in nature (such as SQL BLOBs and Java serialization) were
awkward to work with. Most made the developer responsible for handling
persistence, or used a non-Java language (such as SQL) to interface with
the back-end datastore.
The beauty of JDO is in its simplicity. Developers use the Java
language to persist object instances as well as to retrieve instances from
storage. The processing logic, synchronization, failover, and so on, are
all handled transparently. Rather than using SQL or the awkward
serialization mechanism provided by the Java language, developers simply
work with POJOs (plain ordinary Java objects), passing object references
into and retrieving object references out of storage using the JDO
technologiesEntity beans provide robust data
persistence. The bean container handles most of the data integrity,
resource management, and concurrency functions, letting developers
focus on business logic and data processing rather than these
low-level details. With Bean Managed Persistence (BMP) entity beans,
the developer writes the persistence code but the container
determines when to execute that code. With Container Managed
Persistence (CMP) entity beans, the container generates the
persistence code as well as managing the persistence logic.
JDBC when combined with session beans provides the
ease of EJB development and platform-neutral deployment, without the
resource usage and memory overhead that is common with EJB
technology. Like BMP entity beans, this solution requires the
developer to write the persistence code. Unlike BMP beans, it also
requires the developer to write the persistence logic. Thus, the
developer is responsible for determining when to persist data to and
load from the datastore.
Java Data Objects (JDO) is
the newest persistence mechanism. JDO provides an object-oriented
persistent datastore. Developers use POJOs (plain ordinary Java
objects) to load and store persistent data.
JDO has also adopted much of the high-level architecture used by JDBC.
It uses a pluggable architecture in which developers write their code to a
set of standard interfaces (the JDO API), and vendors supply
implementations for those interfaces. This allows applications that use
the JDO interface to "plug in" any datastore that supports the JDO API. As
with JDBC, this eases portability and increases competition among vendors,
which in turn leads to better products as vendors strive to provide more
efficient and powerful implementations.
Session beans and
Session beans are the backbone of any J2EE architecture
that incorporates EJB technology. This is especially true of stateless
session beans. As previously discussed, the stability and predictability
of stateless session beans makes them particularly well-suited to managing
persistent enterprise data.
Session beans are powerless to access persistent datastores on their
own, however. They must be combined with other technologies, such as
entity beans, JDBC, or JDO, to create a mechanism for persistent data
management. Combining session beans with JDO is similar to combining them
with JDBC, but JDO approaches the problem from a much more object-oriented
and Java-centric perspective.
Enterprise beans obtain access to external
resources by requesting resource manager connection factories from the EJB
container. This is true of EJB components using JDBC and it also true of
EJB components using JDO. The first thing a session bean must do is to
obtain a reference to a
PersistenceManagerFactory by making a
JNDI lookup call. Instances of
PersistenceManager can then be
obtained from the factory. If the session bean is using container-managed
transactions, then each business method will use the factory to obtain a
new instance of
PersistenceManager, and then close the
instance before exiting the method. If bean-managed transactions are
employed, the developer will determine under what conditions a transaction
should begin and end. Consequently, the same
PersistenceManager instance can be used across multiple
business method invocations. Likewise, multiple transactions can be opened
and managed within a single business method. The
PersistenceManager API supports all of these scenarios.
The JDO API for interacting with the
simple and incredibly intuitive. A developer makes an object persistent by
makePersistent() method. Moreover, this method
signature is overloaded allowing a variety of object types to be treated
as persistent objects (single object, an array of objects, or a collection
of objects). Retrieving objects is just as simple. The
getObjectById() method uses a unique value (analogous to a
primary key) determined by the developer to distinguish between object
instances. JDO also supports type-based queries, which are capable of
retrieving a single object or a collection of objects based on a specified
type (that is, subclasses and classes that implement a common interface).
Like JDBC, JDO supports the basic transactional controls:
as well as the ability to indicate whether an optimistic or pessimistic
transaction management approach should be taken by the
combined-technology solution, session beans and JDO offers some advantages
that are derived from session beans and others that are derived from JDO.
As we learned last month, using session beans rather than entity beans for
delivery yields two primary advantages:
- Design simplicity. From an architectural design standpoint,
handling data management directly through session beans is much simpler
than using entity beans.
- Fine-grained control. Because session beans are generic
worker components, they allow the developer complete control over the
entire persistence process, including caching, persistence, concurrency,
synchronization, and more.
These advantages are not unique to the session bean/JDO combination:
they also apply to the pairing of session beans with JDBC. JDO does offer
some unique advantages, however:
- Coding simplicity. The JDO architecture shields developers
from the low-level persistence details, allowing them to focus on
managing objects from a business process point-of-view, rather than
getting bogged down in the minutia of data persistence logic.
- Enhanced productivity. JDO programmers are able to operate
entirely within an object-oriented paradigm. This typically results in
cleaner, smoother, less error-prone development, because programmers
aren't constantly switching between a relational-mindset and an
- Object-oriented persistence. JDO's object-oriented nature not
only enhances developer productivity, but it also allows for a richer
persistence mechanism than is available with relational persistence. JDO
doesn't just persist Java objects; it transparently handles the
persistence of the entire relevant object graph. Thus when an instance
is persisted, any internal references that it maintains to other object
instances are also persisted (unless they've been declared transient).
JDO also stores full knowledge of a type's hierarchy and is capable of
fulfilling requests based on type (parent classes and interfaces),
rather than only understanding the specific local type of the persisted
In summary, using session beans in concert with JDO produces three key
benefits: simplicity (both in design and development), productivity, and
increased control over data persistence.
sound of things, session beans and JDO are a perfect combination to solve
all of your persistence woes! But let's consider some of the drawbacks to
- JDO is immature. JDO is still in its infancy. The JDO 1.0
specification was released less than one year ago at the time of this
writing. As a result, the JDO community is still very small, with the
largest and most well-respected JDO portal boasting a membership of just
over five thousand. While these numbers don't suggest that JDO is a bad
technology, they do suggest it's still on the cutting edge. Few
companies have yet been willing to try using JDO in business-class
implementations. All of this leaves JDO developers and architects with
few proven design patterns or case studies to guide their JDO
- Session beans aren't transactional. JDO objects cannot be
accessed directly by a J2EE client. A servlet or session bean must
handle incoming requests. So, although JDO objects can easily be
declared as transactional, they must still be accessed using
non-transactional components. When coding transaction semantics directly
into a session bean's application code, developers must take every
precaution to ensure that the business rules, flow control, and
transactional integrity of each function are preserved and are fault
tolerant. Although this can be greatly mitigated by using
container-managed transactions, doing so limits the developer's control
over the persistence process and removes much of the architectural
flexibility that comes from controlling the granularity of transactions.
In summary, the combination of session beans and JDO has two
significant disadvantages: JDO is a relatively unproven technology, and
session beans introduce an inherently non-transactional layer to the
already discussed both the advantages and the disadvantages of using
entity beans in some detail (in the previous article), so I'll just
summarize the most relevant points here.
Entity beans offer five essential advantages as an enterprise data
- Standardization. The EJB specification is mature, yielding
the benefit of well-known design patterns, case studies, and best
practices, as well as a rich set of vendor-supported development
- Container-managed services. The EJB container relieves
developers from managing common enterprise functions such as security,
transaction handling, connection pooling, and external resource
- Transparent persistence. Entity beans provide two transparent
options for handling persistence. Container-managed persistence (CMP)
entity beans handle all of the persistence semantics automatically, in
the container. Bean-managed persistence (BMP) entity beans allow
developers to write the persistence logic, but still ease the
responsibility for ensuring data integrity and concurrency, by
allocating these tasks to the container.
- Transaction support. Entity beans provide two models of
transaction support. In CMP beans, the transaction semantics are
declared. In BMP beans, the semantics are implemented directly by the
developer. In both cases, the container manages the transactions and
determines whether or not a given transaction should be committed or
- Component-based design. Entity beans are designed to be
self-contained components that are configured with a deployment
descriptor and can be deployed into any J2EE application server without
any code changes.
On the other side of the coin, entity beans suffer from four basic
- Design complexity. Container-managed services and automatic,
transparent persistence introduce complexity to the overall application
design. Entity beans are also typically accessed through session beans,
which means each transaction involves at least two enterprise beans and
often many more.
- Long build cycles. A single EJB iteration
(design/build/test/integrate/test/deploy) can take two to three times
longer than comparable Java persistence solutions.
- Response time. Entity beans are tied to the granularity of
the bean instance. As a result, the developer must always choose between
loading the bean as is and accounting for the poor response times
elsewhere, or breaking up the data into smaller entities, thus creating
a more complicated system architecture.
- Resource usage. Entity beans consume enormous quantities of
In summary, entity beans benefit from standardization and industry best
practices, ease some of the complexities of enterprise development, and
provide a solid component-based design. The price of these benefits
however, is that entity beans often introduce complexity and long build
cycles, making the design and development of systems that include them
more difficult. Entity beans also are notorious for hogging resources and
responding slowly to concurrent requests for large entities.
It's important when comparing any two
technologies to consider not only their differences, but their
similarities. As J2EE technologies, entity beans and Java Data Objects
have several features in common. We'll start by considering those, then
proceed to the unique pros and cons of each solution.
Entity beans and JDO share the following characteristics:
- Transparent persistence. The freedom afforded by transparent
persistence, in which developers do not know or care about the technical
persistence details, is priceless. Both JDO and entity beans deliver
this luxury to Java programmers.
- Portability. JDO and entity beans are both based on a
vendor-neutral standard. Applications that are written using the
respective standard APIs will be portable across vendor implementations
of the APIs.
- Flexible transaction management. Both JDO and entity beans
provide developers with the option of managing transactions
programmatically, or having transactions managed automatically. JDO uses
PersistenceManager to manage the transactions, whereas
entity beans delegate transaction management to the EJB container.
When deciding between entity beans and JDO, consider the following pros
and cons for each technology:
- Best practices versus design complexity. Enterprise JavaBeans
technology has a rich body of literature, documented design patterns and
best practices, sophisticated tools, and a large pool of J2EE
programmers with EJB technology experience. On the downside, the
complexity of entity beans ensures you'll need to use all of these
assets if you want your project to succeed. Architects and developers
must balance the availability of experienced programmers, design
patterns, and industry best practices against the sheer magnitude of EJB
- Inexperience versus simplicity. What JDO lacks in best
practices it makes up for in simplicity. It is straightforward, easy to
use, and POJOs are much easier to comprehend than the notion of an
"entity." While there are few Java programming professionals with actual
JDO experience, the technology is easy to grasp. J2EE architects and
developers must weigh the lack of patterns, best practices, and case
studies against the inherent simplicity of JDO.
- Lack of legacy support. At present, none of the major
relational database management systems (RDBMS) vendors support JDO.
Consequently, the developer must either migrate system data to a vendor
that does support JDO, or only use JDO for new projects or components
whose functionality isn't dependent on a legacy RDBMS datastore.
- A new persistence paradigm. JDO allows for a rich
object-oriented persistence mechanism, taking full advantage of object
composition (objects that contain other objects) as well as inheritance
(recognizing object types through their full type hierarchy). Although
the object-oriented persistence paradigm of JDO is a boon to application
developers, it can frustrate and confuse database administrators (DBAs).
JDO currently does not provide a mechanism for tying into stored
procedures, leaving DBAs with the egregious task of learning how to
declare constraints using XML, or instruct Java developers in how to
manage the data. Once again we find that JDO lends itself more to new
projects, new components, or existing applications that are independent
of legacy RDBMS.
- Resource usage. Although there are very few performance
benchmarks available, we can assume that applications that rely on
entity beans for their transparent persistence will consume more server
resources than those based on JDO.
installment of the J2EE pathfinder series, we have completed our
examination of one of the trickiest areas of Java development -- data
persistence. While J2EE does offer three strong technologies for handling
data persistence, none of them is perfect.
JDBC has remained the standard for data access among Java developers
for many years. It is a solid, proven technology that allows architects
and developers to leverage an existing relational database infrastructure
and existing expertise in producing database queries. Over time, it has
evolved to provide sophisticated database drivers complete with caching
and resource pooling mechanisms that transparently benefit developers. As
an enterprise persistence technology, JDBC come up somewhat short in that
it leaves all the responsibility of managing concurrency and data
integrity to the developer or database. In spite of this drawback, it is
used extensively due to its maturity, ubiquity, and performance.
Entity beans are a bit less mature than JDBC, but still offer a trusted
solution for enterprise data persistence. As is the case with JDBC,
architects and developers are able to leverage an existing relational
database infrastructure and existing expertise in producing database
queries when working with entity beans. Entity beans can ease the process
of developing robust data persistence code because the EJB container
provides many life cycle enterprise services such as security, resource
management, transaction control, and transparent persistence. Entity beans
offer a powerful data persistence solution that handles much of the
semantics and details transparently for developers. The price of this
power and ease of development is that entity beans are resource intensive
and can be complicated to properly set up and difficult to debug.
Java Data Objects is a compelling alternative to the more mature but
less Java-centric technologies in the J2EE lineup. JDO's pure
object-oriented approach and simplicity-by-design lend it a faster ramp-up
time than the other two persistence technologies. But JDO is also much
less mature JDBC or EJB technology, which leaves developers and architects
out in the cold when it comes to making design and deployment decisions.
Furthermore, for all the ease-of-use it offers to Java developers, JDO
requires a significant time commitment from DBAs, who must assimilate a
brand new data-management paradigm in order to work with it.
Next month, we will conclude our first expedition into the world of EJB
technology, with an exploration of enterprise messaging. Until then, happy
- See the complete J2EE
pathfinder series by Kyle Gabhart.
- The J2EE home page is the
place to start if you want to learn more about the Java 2 platform,
Enterprise Edition and related technologies.
- JDOCentral is the leading
portal for developers, architects, and managers interested in
- In "Hands-on
Java Data Objects" (developerWorks, July 2002) senior Java
architect Paul Monday shows you how JDO -- the first standardized,
completely object-oriented approach to object persistence -- can
simplify your Java database programming.
- Castor JDO is an open source implementation of Java Data Objects. In
started with Castor JDO" (developerWorks, August 2002), Bruce
Snyder explains the essential concepts of object-relational data
mapping, then uses live code and a product example to demonstrate some
of Castor's most exciting features.
- The combination of XML and Java is proving quite popular as a data
management solution. In the recent article "Data
binding, Part 1: Code generation approaches" (developerWorks,
January 2003), a follow-up to "Data
binding with Castor" (developerWorks, April 2002), Java
developer Dennis Sosnoski discusses several data-binding solutions that
are based in XML and applicable in Java applications -- including
- The developerWorks
XML zone is an essential resource for those in search of Java
technology-compatible data-management solutions.
- Brett McLaughlin's EJB
best practices series introduces some of the basic patterns and
uses associated with Enterprise JavaBeans technology.
- Rick Hightower details container-managed persistence in this
four-part tutorial series:
1 explains all about CMP/CMR.
2 describes the three varieties of component managed
relationships: one-to-one, many-to-many, one-to-many.
3 introduces EJB QL.
4 focuses on advanced finder methods and more complex EJB QL
- Srikanth Shenoy offers best practices for EJB
exception handling (developerWorks, May 2002).
- developerWorks offers two tutorials by Robert Brunner that
- In "Building
Web-based applications with JDBC (December 2001) you'll learn the
fundamentals of Web application programming using three separate
techniques: a servlet approach, a JSP approach, and combined JSP,
JavaBeans, and servlet approach (also known as Model 2).
- In "Advanced
database operations with JDBC" (November 2001) you'll learn
several advanced database operations, including stored procedures and
advanced datatypes, that can be performed by a Java application using
- The tutorial "Getting
started with Enterprise JavaBeans technology"
(developerWorks, April 2003) is a comprehensive introduction to
- Kyle Brown's "Choosing
the Right EJB Type: Some Design Criteria" (WebSphere
Developer Domain, August 2000) is a careful comparison of EJB
- The J2EEOlympus.com portal
is an excellent repository of J2EE information (particularly the EJB pages).
- See the developerWorks
Java technology tutorials page for a complete listing of free Java
technology-related tutorials from developerWorks.
- You'll find hundreds of articles about every aspect of Java
programming in the developerWorks
Java technology zone.
Kyle Gabhart is an independent consultant and
subject matter expert with J2EE, XML, and Web services technologies.
Kyle is a popular public speaker, recognized for his enthusiasm and
dynamic analysis and presentation of emerging technologies. For
information on his recent and upcoming presentations or industry
publications, visit Gabhart.com
. Kyle can be reached at mailto:firstname.lastname@example.org.