What Are Entity Beans?

Entity beans are representations of information that's persisted in some kind of data store. Although the main focus of a Session bean is to represent business logic, an Entity bean's main objective is to represent persisted business objects. Examples of persisted business objects include orders, order details, customer accounts, and partner information. Although this information is usually stored in a relational database (RDBMS), it can also be stored in many alternative forms, such as a flat file, an object-oriented database, or as XML.

An Entity bean usually represents a row in the database. An Entity bean manages an in-memory copy of the persisted information. This cached version of the information can be used to reduce the number of times that the actual data store must be accessed. When the in-memory version of the data is modified, the Entity bean, in conjunction with the EJB container, updates the underlying data store.

Entity beans shield their clients from understanding the implementation of the underlying data store and the architecture of the persisted information. For instance, clients of an OrderInfo Entity bean do not need to know whether the information is stored in a database or in VMS files. They also do not have to understand the underlying data schema. Entity beans offer their clients an object-oriented view of persistent application data. When the underlying data store is an RDBMS, the Entity beans are said to provide an object-relational (O-R) mapping. Entity beans provide a mechanism for representing complex object dependencies or object graphs in an object-oriented format. Figure 22.1 shows a set of relational tables that can be modeled using Entity beans.

EJB clients can access EJBs as remote objects. Therefore, when designing and implementing applications that use EJBs remotely, it's important to keep in mind the number of round trips that are required to perform an operation. For example, if the client requests all 100 Order Entity beans related to a customer and only one EJB is returned on each round trip, 100 round trips are required to complete this operation. Most likely, the network overhead will be prohibitively expensive and will force a redesign of the application. Making EJB methods coarse-grained (each method performs a lot of functionality) rather than fine-grained (each method performs very little) can have an enormous impact on how many EJB methods are involved in a business operation and, therefore, how much overhead EJB clients will experience.

Container-Managed Persistence and Bean-Managed Persistence

There are two types of Entity beans: Container-Managed Persistence (CMP) and Bean-Managed Persistence (BMP). In CMP, the EJB container is responsible for knowing when and how to insert, update, retrieve, and remove information in the data store. In BMP, the Entity bean itself must provide code for that. The decision of whether to use CMP or BMP is discussed later in this chapter. For now, understand that BMPs can give the developer more flexibility in the design and implementation of Entity beans, but they require a much larger amount of code to accomplish that flexibility. In general, we recommend using CMP wherever possible. However, in certain cases where complex relationships must be managed or some other optimizations have to be performed, BMP might be your only choice.