9.4 Entity Beans and JDO

Having discussed session and message-driven enterprise beans above, let's now turn to another type of enterprise bean, entity beans. As per the EJB specification ^[4] , an entity enterprise bean has the following characteristics:

^[4] http://java.sun.com/products/ejb/

• Provides an object view of data in the database.

• Allows shared access from multiple users.

• Can be long-lived (lives as long as the data in the database).

Two different types of entity beans exist: container-managed persistence (CMP) and bean-managed persistence (BMP) entity beans. Both types of entity beans can be created and removed, and queried with a language named EJBQL. They also have an identity, their primary key. Does this all seem remarkably similar to what you have learned about JDO so far? Well, you're not the only one. Indeed, the debate about when and whether to use entity beans versus JDO arose with the inception of JDO, and the debate is active and ongoing.

One possible motive may be the idea of directly modeling remotely accessible persistent components . As we have seen earlier, JDO itself does not include any notion of remote invocation, but focuses purely on JVM local persistence issues. Entity beans may thus seem tempting at first for this purpose, instead of developing the required calling, pooling, and so on, infrastructure from scratch. However, most of today's EJB literature highly recommends using the so-called session fa §ade pattern, wherein entity beans are accessed from other local enterprise beans only, and although technically possible, are not actually exposed to remote clients . An often-cited and well-documented reason for this architectural choice is performance issues with fine-grained remotely accessed entity beans. So if you use entity beans only locally from session and message-driven beans anyway, why would you not rather forget about entity beans altogether and simply use the JDO API from within session and message-driven beans to implement persistence?

Another rationale could be existing entity beans that need to be reused. Given that these entity beans are usually persisted in a relatively straightforward relational schema when using entity beans, it is certainly worth at least evaluating whether it is possible to migrate to an O/R mapping-based JDO implementation that could reverse engineer the existing relational schema while preserving existing legacy data. Chapter 12 provides more information on such a road.

A related possibility would arise should you have a project that uses existing entity beans that do not map data to and from a relational database, but use another, e.g., an EIS-type or TP monitor, backend datastore. Although JDO technically allows and the market aims at providing JDO implementations for such datastores, it may not be available for your EIS of choice yet. It may be worth talking to the EIS vendor about JDO, and checking with independent JDO implementations about the EIS, in such a specific case. However, this is a somewhat theoretical possibility, because most real-world integration projects join together using a higher-level API, likely service-oriented, not on an entity level. A similar and slightly more common scenario is if you have existing entity beans with BMP that do O/R mapping entirely through, e.g., PL/SQL-stored procedure calls rather than direct access to the underlying relational tables. Again, check your JDO implementation for support of stored procedures.

Last but not least, you could be on a project that actually requires an architecture with distributed and transactional persistent components. Read again, distributed transactional persistent objects, not distributable services. If you really are working on an application like this, the remotely accessed entity beans may be a fitting solution.

In short, with the advent of JDO, it is hard to find good reasons to continue using entity beans instead of JDO for modeling and working with persistent objects in new J2EE projects.

9.4.1 Bean-managed persistence (BMP) entity beans and JDO

Bean-managed persistence (BMP) entity beans are components that respect the entity bean API contract, but implement actual persistence code themselves within the BMP implementation class, instead of relying on "transparent" declarative persistence handled by the EJB container, as is the case for container-managed persistence (CMP) entity beans.

Reasons for using BMP instead of CMP enterprise beans could be limitations in (or in early containers, a simple lack of) container-managed persistence (CMP) entity beans, or non-relational datastores.

Should a specific application have a good reason to adopt such an architecture, it is technically feasible to use JDO to implement the ejbCreate , ejbRemove , ejbActivate , ejbPassivate , ejbLoad , and ejbStore methods that a BMP entity bean needs to provide. The JDO 1.0 specification roughly outlines how this could be done in its Chapter 16.2.1. ^[5]

^[5] If you are interested in looking into this issue in more detail, be aware that the initial JDO 1.0 specification from Spring 2002 mistakenly stated that "The ejbActivate() method acquires a PersistenceManager from the PersistenceManagerFactory...." This is wrong because the EJB 2.0 specification does not specify that ejbActivate() will be called within the context of an open transaction. Because persistence managers must be obtained within such a context in order to be bound to the J2EE transaction, acquiring the PM from the PMF should be done in the ejbLoad() method only, with the ejbActivate() method remaining empty. The v1.0.1 maintenance release of the JDO specification has corrected this detail.

However, as argued above, the real question in this context is not "How do you do this?" but rather "Why would you do this?" The authors of this book believe that for most applications, the answer is simply "You wouldn't do this!" We thus do not provide examples of how to use JDO from BMP entity beans in this book.

Using JDO to Implement CMP

Another issue is whether JDO could be used as the underlying technology to implement container-managed persistence (CMP) entity beans in a J2EE application server. The answer is definitely yes; JDO could be used for that purpose. This would, however, be an AppServer implementation decision and is unrelated to the implementation of J2EE applications per se. This scenario, of course, hides JDO features that have no CMP equivalent.

Indeed, at least one (the SunOne AppServer) is reported to work like this. Interestingly, the O/R mapping toolkit that JBoss uses internally to implement CMP is also reported to likely become exposed for local (non-EJB!) persistence, although at the time of this writing, it is not clear whether this AOP-based service will be accessible via a JDO-compliant API.

Note also that using the standard JDO 1.0 API alone leads to some minor issues complicating this slightly in practice; however, vendor extensions could accommodate these. For example, seamless translation of some EJBQL to JDOQL queries may be difficult due to the lack of bi-directional (inverse, managed) relationships as well as projections in JDO queries. See Chapters 24.7 and 24.17 of the JDO 1.0 specification.