Summary

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 application 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 application 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 application 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:

• Don't use entity beans if your EJB container supports only EJB 1.1 Entity beans as specified in EJB 1.1 were inadequate to meet most real-world requirements.

• Use CMP, not BMP The greater control over the management of persistence offered by BMP is largely illusory. BMP entity beans are much harder to develop and maintain than CMP entity beans, and usually deliver worse performance.

• Use ejbHome() methods to perform any aggregate operations required on your data ejbHome() methods, which can act on multiple entities, help to escape the row-level access imposed by the entity bean model, which can otherwise prevent efficient RDBMS usage.

• Use fine-grained entity beans The "Composite Entity" pattern, often recommended for EJB 1.1 development, is obsolete in EJB 2.0. Implementing coarse-grained entities requires a lot of work, and is likely to deliver a poor return on investment. If fine-grained, EJB 2.0 style, entity beans don't meet your requirements, it's likely that use of entity beans is inappropriate.

• Don't put business logic in entity beans Entity beans should contain only persistence logic. When using EJB, business logic should normally go in session beans.

• Investigate your EJB container's locking and caching options for entity beans Whether or not entity beans are a viable option depends on the sophistication of your EJB container's support for them. How you structure your entity bean deployment may have a big effect on your application's performance.

The following guidelines apply primarily to distributed applications:

• Never allow remote clients to access entity beans directly; mediate entity bean access through session beans, using the Session Façade pattern If remote clients access entities directly, the result is usually excessive network traffic and unacceptable performance. When any components outside the EJB tier access entity beans directly (even within the same JVM), they arguably become too closely coupled to the data access strategy in use.

• Give entity beans local interfaces, not remote interfaces Accessing entity beans through remote interfaces has proven too slow to be practical. Remote clients should use a session façade.

• Create Value Objects in session beans, not entity beans As we discussed in Chapter 7, value objects are often related to use cases, and hence to business logic. Business logic should be in session beans, not entity beans.

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 application server market and would help JDO become a single strong J2EE standard for accessing persistent data. But that's just my opinion!

Important 

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 application as shown in practice in the next chapter.