J2EE pathfinder: Persistent data management, Part 2

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 works.

Overview of JDO
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 interfaces.

J2EE persistence technologies
Entity 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 JDO
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.

A powerful combination
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 PersistenceManager is simple and incredibly intuitive. A developer makes an object persistent by calling the 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: begin(), commit(), and rollback(), as well as the ability to indicate whether an optimistic or pessimistic transaction management approach should be taken by the PersistenceManager instance.

Advantages
As a 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 one.
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 instance.

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.

Disadvantages
From the 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 this approach:

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 development efforts.
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 business process.

Entity beans
We've 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 persistence mechanism:

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 tools.
Container-managed services. The EJB container relieves developers from managing common enterprise functions such as security, transaction handling, connection pooling, and external resource management.
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 rolled-back.
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 disadvantages:

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 system resources.

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.

Points of comparison
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 the 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 technology.
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.

Conclusion
In this 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 pathfinding!

Resources

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 JDO.
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 "Get 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 JAXB.
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:
- Part 1 explains all about CMP/CMR.
- Part 2 describes the three varieties of component managed relationships: one-to-one, many-to-many, one-to-many.
- Part 3 introduces EJB QL.
- Part 4 focuses on advanced finder methods and more complex EJB QL queries.
Srikanth Shenoy offers best practices for EJB exception handling (developerWorks, May 2002).
developerWorks offers two tutorials by Robert Brunner that detail JDBC.
- 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 JDBC.
The tutorial "Getting started with Enterprise JavaBeans technology" (developerWorks, April 2003) is a comprehensive introduction to EJB technology.
Kyle Brown's "Choosing the Right EJB Type: Some Design Criteria" (WebSphere Developer Domain, August 2000) is a careful comparison of EJB types.
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.

About the author
Photo of Kyle Gabhart

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:kyle@gabhart.com.

developerWorks > Java technology

About IBM | Privacy | Terms of use | Contact