Persistent Entity Beans:

What Is an Entity Bean?

An entity bean represents a business object in a persistent storage mechanism. Some
examples of business objects are customers, orders, and products. In the J2EE SDK, the
persistent storage mechanism is a relational database. Typically, each entity bean has an
underlying table in a relational database, and each instance of the bean corresponds to a
row in that table. For code examples of entity beans, please refer to chapters 5 and 6.

What Makes Entity Beans Different from Session Beans?

Entity beans differ from session beans in several ways. Entity beans are persistent, allow
shared access, have primary keys, and may participate in relationships with other entity
beans.

Persistence

Because the state of an entity bean is saved in a storage mechanism, it is persistent.

Persistence means that the entity bean's state exists beyond the lifetime of the application
or the J2EE server process. If you've worked with databases, you're familiar with
persistent data. The data in a database is persistent because it still exists even after you
shut down the database server or the applications it services.

There are two types of persistence for entity beans: bean-managed and container-
managed. With bean-managed persistence, the entity bean code that you write contains
the calls that access the database. If your bean has container-managed persistence, the
EJB container automatically generates the necessary database access calls. The code that
you write for the entity bean does not include these calls. For additional information, see
the section Container-Managed Persistence.

Shared Access

Entity beans may be shared by multiple clients. Because the clients might want to change
the same data, it's important that entity beans work within transactions. Typically, the
EJB container provides transaction management. In this case, you specify the transaction
attributes in the bean's deployment descriptor. You do not have to code the transaction
boundaries in the bean--the container marks the boundaries for you. See Chapter 14 for
more information.

Primary Key

Each entity bean has a unique object identifier. A customer entity bean, for example,
might be identified by a customer number. The unique identifier, or primary key, enables
the client to locate a particular entity bean. For more information see the section Primary
Keys for Bean-Managed Persistence.

Relationships

Like a table in a relational database, an entity bean may be related to other entity beans.
For example, in a college enrollment application, StudentEJB and CourseEJB would be
related because students enroll in classes.

You implement relationships differently for entity beans with bean-managed persistence
and those with container-managed persistence. With bean-managed persistence, the code
that you write implements the relationships. But with container-managed persistence, the
EJB container takes care of the relationships for you. For this reason, relationships in
entity beans with container-managed persistence are often referred to as container-
managed relationships.

Container-Managed Persistence

The term container-managed persistence means that the EJB container handles all
database access required by the entity bean. The bean's code contains no database access
(SQL) calls. As a result, the bean's code is not tied to a specific persistent storage
mechanism (database). Because of this flexibility, even if you redeploy the same entity
bean on different J2EE servers that use different databases, you won't need to modify or
recompile the bean's code. In short, your entity beans are more portable.

In order to generate the data access calls, the container needs information that you
provide in the entity bean's abstract schema.

Abstract Schema

Part of an entity bean's deployment descriptor, the abstract schema defines the bean's
persistent fields and relationships. The term abstract distinguishes this schema from the
physical schema of the underlying data store. In a relational database, for example, the
physical schema is made up of structures such as tables and columns.

You specify the name of an abstract schema in the deployment descriptor. This name is
referenced by queries written in the Enterprise JavaBeans Query Language ("EJB QL").
For an entity bean with container-managed persistence, you must define an EJB QL
query for every finder method (except findByPrimaryKey). The EJB QL query
determines the query that is executed by the EJB container when the finder method is
invoked. To learn more about EJB QL, see Chapter 8.

You'll probably find it helpful to sketch the abstract schema before writing any code.
Figure 3-1 represents a simple abstract schema that describes the relationships between
three entity beans. These relationships are discussed further in the sections that follow.
Figure 3-1 A High-Level View of an Abstract Schema

Persistent Fields

The persistent fields of an entity bean are stored in the underlying data store.
Collectively, these fields constitute the state of the bean. At runtime, the EJB container
automatically synchronizes this state with the database. During deployment, the container
typically maps the entity bean to a database table and maps the persistent fields to the
table's columns.

A CustomerEJB entity bean, for example, might have persistent fields such as
firstName, lastName, phone, and emailAddress. In container-managed persistence,
these fields are virtual. You declare them in the abstract schema, but you do not code
them as instance variables in the entity bean class. Instead, the persistent fields are
identified in the code by access methods (getters and setters).

Relationship Fields

A relationship field is like a foreign key in a database table--it identifies a related bean.
Like a persistent field, a relationship field is virtual and is defined in the enterprise bean
class with access methods. But unlike a persistent field, a relationship field does not
represent the bean's state. Relationship fields are discussed further in Direction in
Container-Managed Relationships.
Multiplicity in Container-Managed Relationships

There are four types of multiplicities:

One-to-one: Each entity bean instance is related to a single instance of another entity
bean. For example, to model a physical warehouse in which each storage bin contains a
single widget, StorageBinEJB and WidgetEJB would have a one-to-one relationship.

One-to-many: An entity bean instance may be related to multiple instances of the other
entity bean. A sales order, for example, can have multiple line items. In the order
application, OrderEJB would have a one-to-many relationship with LineItemEJB.

Many-to-one: Multiple instances of an entity bean may be related to a single instance of

the other entity bean. This multiplicity is the opposite of a one-to-many relationship. In
the example mentioned in the previous item, from the perspective of LineItemEJB the
relationship to OrderEJB is many-to-one.

Many-to-many: The entity bean instances may be related to multiple instances of each
other. For example, in college each course has many students, and every student may take
several courses. Therefore, in an enrollment application, CourseEJB and StudentEJB
would have a many-to-many relationship.

Direction in Container-Managed Relationships

The direction of a relationship may be either bidirectional or unidirectional. In a

bidirectional relationship, each entity bean has a relationship field that refers to the other
bean. Through the relationship field, an entity bean's code can access its related object. If
an entity bean has a relative field, then we often say that it "knows" about its related
object. For example, if OrderEJB knows what LineItemEJB instances it has and if
LineItemEJB knows what OrderEJB it belongs to, then they have a bidirectional
relationship.

In a unidirectional relationship, only one entity bean has a relationship field that refers to
the other. For example, LineItemEJB would have a relationship field that identifies
ProductEJB, but ProductEJB would not have a relationship field for LineItemEJB. In
other words, LineItemEJB knows about ProductEJB, but ProductEJB doesn't know
which LineItemEJB instances refer to it.

EJB QL queries often navigate across relationships. The direction of a relationship

determines whether a query can navigate from one bean to another. For example, a query
can navigate from LineItemEJB to ProductEJB, but cannot navigate in the opposite
direction. For OrderEJB and LineItemEJB, a query could navigate in both directions,
since these two beans have a bidirectional relationship.

When to Use Entity Beans

You should probably use an entity bean under the following conditions:

• The bean represents a business entity, not a procedure. For example,

CreditCardEJB would be an entity bean, but CreditCardVerifierEJB would be
a session bean.
• The bean's state must be persistent. If the bean instance terminates or if the J2EE
server is shut down, the bean's state still exists in persistent storage (a database).