Introduction to Entity Beans
Entity beans are Java 2 Platform, Enterprise Edition (J2EE) components that have been designed specifically to represent data in a persistent store, which is typically a database. These business objects are primarily involved in the manipulation of this data to better match the needs of its clients, so there is more to the typical entity bean than just providing database accessor methods.
Generally speaking, data required by the client should come from entity beans rather than building separate data access objects. By using these EJBs, access and synchronization with the database are already provided for you. As a valuable plus, entity beans automatically provide the ability to share both state and behavior across multiple clients concurrently. They also provide other built-in features, like mechanisms to recover from a system crash.
Coarse-Grained Business Objects
Entity beans can provide much added value to enterprise applications, especially in systems dealing with complex data manipulations. However, just like other EJBs, there is a certain amount of overhead associated with using entity beans. As such, they are best suited to represent what we'll call coarse-grained business objects.
Coarse-grained objects are often those that represent a single logical record in a database, typically involving data that can exist completely on its own and still make sense. For example, a customer order would likely be something well suited to be represented by an entity bean. An individual item within the order is likely to be identified as more of a fine-grained object because the information provided by the individual item possibly has little value when taken outside the context of a customer order.
Identifying whether an object is coarse- or fine-grained is really dependent on the type of data you are dealing with and the enterprise application you are trying to build. For example, even a single customer order might be too fine-grained for you to consider. You might be more interested in the collection of every order a particular customer has made within a certain period. Maybe specific items in an order are more significant for you, and your entity bean is used instead to track complicated shipping details or return information for that item alone.
Figure 13-1 shows an example where it makes more sense for the single items to be identified within the context of the complete customer order, so they are pulled in as part of it.
Figure 13-1. Customer order entity bean with individual items included
Increasing Popularity
Historically, entity beans have seen less adoption in the industry when compared to session beans. There are several reasons for this:
Data access methods are generally easier to write than good transaction management code, so entity beans are sometimes viewed as less critical to use than session beans.
Like any new technology, the perceived added value has to greatly outweigh the cost of learning how to use it effectively. It can be argued that entity beans are more difficult to implement correctly than other EJB types and offer fewer direct benefits.
Entity bean support by some application servers has been problematic or poorly documented in the past.
Entity beans can have a significant impact on performance, especially when they are improperly used in the design (e.g., fine-grained).
The final details of the database to be used with an enterprise application are often not known until late in the development cycle.
Most of these issues are gradually being overcome by a better understanding of how to employ entity beans, by better overall support now being offered by J2EE compliant application servers, and by some technology improvements being incorporated in the J2EE 1.3 release.
Entity bean use is gradually increasing as these issues are being addressed and a greater overall understanding of appropriate and inappropriate entity bean design strategies is being developed.
J2EE Versions
As is the case with all EJB component types, entity beans are deployed with the help of an EJB container, which in turn is hosted by an application server. The particular capabilities and level of J2EE compliance of the server determines which version of the EJB specification you need to be working with.
For the rest of this chapter, all points pertain equally well to both J2EE 1.2 and J2EE 1.3 except where noted.