J2EE Persistence from JDBC to CMP (Continued)

Ease of development, flexibility, and the ability to build applications with ordinary Java objects have made POJO solutions popular, as has its widespread availability among commercial and open source solutions. Developers can build and test their persistent models outside of the J2EE container, which speeds development time, reduces application server dependencies, and makes it easier to switch server vendors or use the same application logic in a model outside of the J2EE container. Also, using POJO solutions within a J2EE server either in the Web tier or EJB tier (wrapped by Session Beans) is a completely standards-compliant J2EE application solution, although not yet specified in itself. Using POJO persistence with Enterprise JavaBeans is currently being developed in the EJB 3.0 specification, where Oracle is playing a significant role in defining the new model. However, JSR 220 (EJB 3.0) is still in the early stages, making it subject to change; it is not expected to be complete until some time in 2006.

The BMP solution, though far less popular, should not be simply ignored. BMP developers create entity beans—integrated J2EE components—that are managed by the J2EE container, but defers its persistence operations to the bean author. Although this puts the responsibility back on the developer, it does offer an EJB entity bean solution that enables portability across multiple application server vendors.

BMP is typically implemented through hand-coded JDBC interaction that must be developed and maintained at great cost. But it's not the only way to address BMP. Many commercially available persistence layers address BMP either through code generation or, more ideally, though an ORM solution. If you want the benefits of entity beans and don't mind writing the persistence code yourself, or require the application server portability, consider BMP.

Despite its negative, and sometimes unfair, publicity the CMP solution remains popular with some developers. The EJB 2.1 specification addressed a number of the persistence-related limitations that plagued the initial versions. These changes have allowed application server vendors to produce full-featured persistence layers and allowed developers choosing this approach to function within the specification—something that simply was not possible for applications of any complexity prior to EJB 2.1.

Some CMP solutions today provide very sophisticated persistence support. Many of these features, including caching, database locking, query extensions, and optimized SQL generation go beyond what is in the EJB 2 specification. In most cases the improved performance and functionality far outweigh the decreased flexibility introduced through these vendor-specific dependencies.

Meeting of the Minds
An EJB entity bean using CMP has more run-time and developer overhead than its equivalent POJO. However, it also offers more than just persistence: It provides benefits such as security, instance pooling/management, remote access, load balancing, and failover. If you need these extra features, or if working within proven and widely adopted standards is important to you, CMP entity beans may be a good choice. Its additional development costs and issues are being addressed by richer development environments and planned enhancements to the standard.

There is a growing division between those in the Java community who support and are successful with CMP entity beans and those supporting POJO style solutions. We will see a convergence between the ORM persistence offered by CMP and POJO with the upcoming changes proposed in EJB 3.0. This solution combines the best of both approaches that will simplify the challenge and the solution fragmentation we're seeing today. We will look at EJB 3.0 in more depth in a future article.

When you're evaluating persistence solutions, and the vendors that provide them, there are a number of selection criteria to consider (see Table 1). Often the corporate culture and vendor commitment determines the selected solution. What's important to know is how to build and prioritize your shopping list of features and requirements when tasked with selecting an ORM solution.

POJO is the simplest usage model while providing a great deal of flexibility. It has the largest number of third-party commercial and open source solutions available. Vendor stability is a key decision criterion. Selecting a POJO solution can also be very strategic, as it will provide a natural migration path to EJB 3.0 if the vendor you select is working toward this target. However, EJB 3.0 is also expected to provide a good migration path for those using today's CMP solutions.

BMP is useful for EJB entity beans solutions that need application server portability but use a persistence layer in conjunction with this approach. If you do not use a persistence layer, you'll be forced to deal with all of the development and maintenance costs of a data-centric JDBC solution, as well as that of EJB development.

CMP offers more than just persistence. You can be successful with it; although, using some advanced persistence features may go beyond the specification and couple you to the target application server and its vendor.

Different projects often have unique requirements in the area of persistence. Selecting a solution and vendor that can support multiple architectures and provides a migration path to support future specifications is the best way to leverage your investment across your current and future projects.

About the Author
Doug Clarke is principal product manager for Oracle TopLink and has a background in development and professional services with a focus on interfacing object-oriented applications with relational databases. Contact Doug at .