Chapter 5: Entity Beans

Introduction

An entity bean is an object that represents persistent data. In most cases the data are stored in a database. An entity bean, however, is more than a simple device for storing data. Rather, an entity bean may be thought of as an enterprise object with its own functionality. It allows a number of clients simultaneous access to transaction-secure data. A graphical overview of entity beans is given in Figure 5-1.

Figure 5-1: Overview of entity beans.

Entity beans have been given an ever greater significance in the course of the development of the Enterprise JavaBeans specification. While entity beans were still defined in version 1.0 as an optional component, in version 1.1 they became a necessity for every EJB container. Version 2.0 changed the definition of entity beans in a number of particulars and extended their functionality considerably. To ensure the compatibility of version 2.0 with earlier versions, both types of entity beans (1.1 and 2.0) are part of specification 2.0 and must be supported by EJB containers. Version 2.1 added some extra enhancements to specification 2.0. The overall structure between 2.0 and 2.1 is largely the same with some extra functions available to be used in EJB-QL (described within this chapter). Throughout this chapter any reference to capabilities of version 2.0 entity beans can also be applied to version 2.1 entity beans. Any differences will be clearly distinguished.

An application works with entity beans when it stores information over several program runs, and so the state of the object is not lost if the server is stopped and later restarted. An entity bean exists until a client explicitly deletes it. In contrast, session beans, about which we have spoken earlier, are not persistent. Therefore, the state of a session bean is always lost when the client or server are terminated.

Since entity beans enable several clients to access the same data in parallel, they are seen as a central resource. Every client of an entity bean works almost as if it had exclusive access to the bean. The EJB container avoids the usual problems that result from parallel access through partial serialization of accesses and by the implementation of transactions (see also Chapter 7).

Entity beans are distinguished from session beans by this parallel access by several clients. With stateful session beans, every client uses a separate bean instance. The state of a session bean is thus always available exclusively to a single client. If clients access the same data set in parallel, they all use the same entity bean. The state of an entity bean that represents a particular data set is available to all clients.

An entity bean defines methods, attributes, relationships, and a primary key. As with session beans, the methods realize the functionality of the bean and thereby determine its behavior. The attributes hold the data and thus determine the state of an entity bean. Relations define dependencies among entity beans. One or more attributes of an entity bean are collected into a primary key, which makes it possible to identify each instance of the class uniquely. The home object (which we met in Chapter 3 as the EJBHome object) and the value of the primary key together determine the identity of the entity bean. They identify a particular bean that models an object, for example, a customer or an item of stored merchandise.

The modeling of complex structured data by relationships among entity beans in conjunction with the local client view has been satisfactorily supported by the EJB container only since version 2.0 of the specification. Previously, the mapping of complex data structures had to be programmed by hand or with proprietary tools. Another alternative was the use of so-called OR mapping tools from third-party producers. However, when OR mapping tools were implemented an Enterprise Bean became no longer easily portable.

The persistence mechanism of the EJB container has the job of writing the state of an entity bean to a database or another storage system. When the bean is needed again, the persistence mechanism reads out the persistent data and places an entity bean instance in active memory. In this way every entity bean can always be identified with its home object and primary key.

With the use of a persistence manager (container-managed persistence) the task of implementation is simplified. The bean provider can also implement the persistence mechanism in the entity bean (bean-managed persistence) to gain flexibility.

An EJB container offers one or more persistence managers. Each persistence manager implements a particular persistence mechanism that stores the persistent data using a particular methodology. In the case of container-managed persistence the query language EJB-QL enables access to persistent data independently of the methodology used.