5.3 Entity Beans

An entity bean represents an object view of business data stored in persistent storage or an existing application. The bean provides an object wrapper around the data to simplify the task of accessing and manipulating it. This object interface lends itself to software reuse. For example, an entity bean representing user account information can be used by order management, user personalization, and marketing in a uniform way.

An entity bean allows shared access from multiple clients and can live past the duration of client's session with the server. If the state of an entity bean is being updated by a transaction at the time of server crash, the entity bean's state is automatically reset to the state of the last committed transaction.

5.3.1 Guidelines for Using Entity Beans

A Bean Provider can use the following entity bean characteristics as guidelines when deciding whether to model a business object as an entity bean:

• Representing persistent data

If the state of a business object needs to be stored in a persistent storage and its behavior primarily represents manipulation of data represented in its state, then it should be modeled as entity bean.

However, it should be noted that every method call to an entity object via the remote and home interface is potentially a remote call. Even if the calling and called enterprise beans are located in the same Java virtual machine, the call must go through the container, which must create copies of all parameters that are passed through the interface by value. The container also checks security and applies declarative transaction attributes on the inter-component calls. Therefore modeling every object representing a row in the database as an entity bean is not recommended. An entity bean is better suited to represent a coarse-grained business object that provides more complex behavior than only get and set methods for its fields.

• Providing concurrent access by multiple clients

When the state and behavior of a business object needs to be shared among multiple clients, they should be modeled as entity beans. This kind of business object needs to maintain state between method calls. However, this state is not specific to a particular client but is representative of persistent state of the business object, typically stored in a database. By modeling such business objects as entity beans, a Bean Provider can rely on an EJB server to ensure appropriate synchronization for entity beans as they are accessed concurrently from multiple transactions.

• Representing a single logical record (row) of data

The business objects that typically operate on one logical record in the database are excellent candidates to model as entity beans. In fact, entity beans are designed to represent an individual (logical) record in the database. Entity beans provide methods to locate, create, and manipulate one row at a time.

• Providing robust, long-lived persistent data management

A business object that needs to live after a client's session with the server is over or that needs to be present when the server comes back after a crash, should be modeled as an entity bean. Entity beans live even after a client's session with the server is over and can even survive server crashes. If the state of an entity bean is being updated by a transaction at the time of server crash, the entity bean's state is automatically reset to the state of the last committed transaction.

5.3.1.1 Example: A User Account Bean

The concept of a user account is central to all clients in many e-commerce applications. Multiple clients need to share behavior such as creating an account, verifying an existing account, and updating account information. Updates to the state of an account object need to be written to persistent storage and an account object lives even when the client's session with the server is over. Therefore, in the sample application, an account object is modeled as entity bean.

To avoid expensive remote methods to get the value of account objects fields, the sample application uses a value object (discussed in Section 5.5.2) to represent account details. Only one remote call is required to retrieve the value object and then a client's request to query the state of an account object can then be satisfied via local get methods on this details object. Similarly, to avoid fine-grained set methods, the sample application uses a coarse-grained method to update all account information via one remote call. Code Example 5.1 shows the remote interface of the Account enterprise bean and the implementation of AccountDetails.

public interface Account extends EJBObject {
	public void changeContactInformation(ContactInformation info) 
		throws RemoteException;
	public AccountDetails getAccountDetails() 
		throws RemoteException;
}

public class AccountDetails implements java.io.Serializable {
	private String userId;
	private String status;
	private ContactInformation info;

	public String getUserId() {
		return userId;
	}
	...
}

Like most entity beans, the account bean provides an object view of data stored in a database and most of its code revolves around connecting to, accessing, and updating database tables. The next section discusses options for implementing data access logic for entity beans.

5.3.2 Persistence in Entity Beans

The protocol for transferring the state of an entity between the enterprise bean instance and the underlying persistent store is referred to as object persistence. An entity bean can implement persistence in the following ways:

• Directly implementing persistence in the enterprise bean class or in one or more helper objects provided with the enterprise bean class (bean-managed persistence)
• Delegating the handling of its persistence to its container (container-managed persistence)

With bean-managed persistence, the Bean Provider writes database access calls. The data access calls can be coded directly into the enterprise bean class, or can be encapsulated in a data access component that is part of the entity bean. If data access calls are coded directly in the enterprise bean class, it may be more difficult to adapt the entity component to work with a database that has a different schema, or with a different type of database. Encapsulating data access calls in a data access object makes it easier to adapt the enterprise bean's data access to different schemas or different database types. The sample application uses separate data access objects for implementing persistence. Data access objects are discussed in detail in Section 5.5.1.

With container-managed persistence, the Bean Provider identifies the fields to be stored to the database and the Container Provider's tools generate database access calls at deployment time. The type and structure of the data source is transparent to the Bean Provider. The container tools can generate classes that use JDBC or SQL/J to access the entity state in a relational database, classes that implement access to a non-relational data source, or classes that implement function calls to existing enterprise applications. The bean state is defined independently of how and where it will be stored and hence is more flexible across applications. The disadvantage is that sophisticated tools must be used at deployment time to map the enterprise bean's fields to a data source. These tools and containers are typically specific to each data source.

When a container supports container-managed persistence, it simplifies the task of writing entity beans because the container takes the responsibility of generating the code to access the data source. Bean developers should take advantage of this feature and delegate the task of saving the state of an entity bean to the container whenever possible. Some containers may not be capable of handling complex state objects (for example, objects representing multiple joins). In such cases, the Bean Provider may have to use bean-managed persistence.