In practice, entity beans provide a basic O/R mapping described in the EJB specification. This mapping has the virtue of standardization. However, it doesn't presently approach the power of leading proprietary O/R mapping products. Nor is O/R mapping always the best solution when using an RDBMS. Entity beans were foreshadowed in EJB 1.0 and have been a core part of the EJB specification since EJB 1.1. The EJB 2.0 specification introduces important enhancements in entity bean support, with more sophisticated container-managed persistence and the introduction of local interfaces. EJB 2.1 makes incremental enhancements. The EJB 2.0 specification helps to settle some of the uncertainties regarding how to use entity beans. For example, the debate as to the granularity of entity beans seems to have been settled in favor of fine-grained entities. Such entities can be given local interfaces allowing session beans to work with them efficiently. EJB 2.0 CMP supports the navigation of relationships between fine-grained entities. EJB 2.0 entities can also use methods on their home interfaces to perform persistence logic affecting multiple entities. However, entity beans have a checkered record in practice. In particular, their performance is often disappointing. The future of entity beans as a technology probably depends on the quality of available CMP implementations. The EJB 2.0 specification requires app servers to ship with CMP implementations; we are also seeing the emergence of third-party implementations from companies with a strong track record in O/R mapping solutions. Such implementations may go beyond the specification to include features such as high-performance caching, optimistic locking, and EJB QL enhancements. Entity beans can be valuable in J2EE solutions. However, it's best to treat the use of entity beans as one implementation choice rather than a key ingredient in app architecture. This can be achieved by using an abstraction layer of ordinary Java interfaces between session beans and entity beans. I feel that a strategy of data access exclusively using entity beans is unworkable, largely for performance reasons. On the other hand, a strategy of data access from session beans (using helper classes) is workable, and is likely to perform better. It's vital that components outside the EJB tier don't work directly with entity beans, but work with session beans that mediate access to entity beans. This design principle ensures correct decoupling between data and client-side components, and maximizes flexibility. EJB 2.0 allows us to give entity beans only local interfaces, to ensure that this design principle is followed. There's also a strong argument for avoiding direct entity bean access in session beans themselves; this avoids tying the app architecture to entity beans, allowing flexibility if required to address performance issues or to take advantage of the capabilities of the data source in use. If using entity beans, I recommend the following overall guidelines:

The following guidelines apply primarily to distributed apps:

A personal note: I was enthusiastic about the idea of entity beans when they were first described as an optional feature of EJB 1.0. As recently as the first draft release of EJB 2.0 in June 2000, I was hopeful that the limitations that I and other architects had encountered working with entity beans in EJB 1.1 would be overcome, and that entity beans would become a strong feature of EJB. However, I have become progressively disillusioned. Entity bean performance has proven a problem in most systems I have seen that use entity beans. I have become convinced that remote access to entity beans and the transaction and security management infrastructure for entity beans is architecturally gratuitous and an unnecessary overhead. These are issues to be handled by session beans. The introduction of local interfaces still leaves entity beans as unnecessarily heavyweight components. Entity beans still fail to address the hardest problems of O/R mapping. My feeling is that JDO will supplant entity beans as the standard-based persistence technology in J2EE. I think that there's a strong case for downgrading the status of entity beans to an optional part of the EJB specification. Entity bean support accounts for well over a third of the EJB 2.0 specification (as opposed to slightly more than a fifth of the much shorter EJB 1.1 specification), and much of the complexity of EJB containers. Removing the requirement to implement entity beans would foster competition and innovation in the app server market and would help JDO become a single strong J2EE standard for accessing persistent data. But that's just my opinion!


I prefer to manage persistence from session beans, using an abstraction layer of DAOs comprising a persistence façade. This approach decouples business logic code from the details of any particular persistence model.

We will use this approach in our sample app as shown in practice in the next chapter.