Sun Microsystem Inc

9.1.2 Granularity of entity beans

This section provides guidelines to the Bean Providers for modeling of business objects as entity beans.

In general, an entity bean should represent an independent business object that has an independent identity and lifecycle, and is referenced by multiple enterprise beans and/or clients.

A dependent object should not be implemented as an entity bean. Instead, a dependent object is better implemented as a Java class (or several classes) and included as part of the entity bean on which it depends.

A dependent object can be characterized as follows. An object B is a dependent object of an object A, if B is created by A, accessed only by A, and removed by A. This implies, for example, that if B exists when A is being removed, B is automatically removed as well. It also implies that other programs can access the object B only indirectly through object A. In other words, the object A fully manages the lifecycle of the object B.

For example, a purchase order might be implemented as an entity bean, but the individual line items on the purchase order should be implemented as helper classes, not as entity beans. An employee record might be implemented as an entity bean, but the employee address and phone number should be implemented as helper classes, not as entity beans.

The state of an entity object that has dependent objects is often stored in multiple records in multiple database tables.

In addition, the Bean Provider must take into consideration the following factors when making a decision on the granularity of an entity object:

•Every method call to an entity object via the remote and home interface is potentially a remote call. Even if the calling and called entity bean are collocated in the same JVM, the call must go through the container, which must create copies of all the parameters that are passed through the interface by value (i.e. all parameters that do not extend the java.rmi.Remote interface). The container is also required to check security and apply the declarative transaction attribute on the inter-component calls. The overhead of an inter-component call will likely be prohibitive for object interactions that are too fine-grained.

•The EJB deployment descriptor does not provide a mechanism for describing object schemas (the relationships among the fine-grained objects, and how fine-grained objects are mapped to the underlying database). If these relationships need to be visible at deployment time, the information describing the relationships must be passed from the Bean Provider to the Deployer through some means outside of the EJB specification.

9.1.3 Entity persistence (data access protocol)

An entity bean implements an object view of an entity stored in an underlying database, or an entity implemented by an existing enterprise application (for example, by a mainframe program or by an ERP application). The data access protocol for transferring the state of the entity between the entity bean instances and the underlying database is referred to as object persistence.

Sun Microsystems Inc.

The entity bean component protocol allows the entity Bean Provider either to implement the entity bean’s persistence directly in the entity bean class or in one or more helper classes provided with the entity bean class (bean-managed persistence), or to delegate the entity bean’s persistence to the Container Provider tools used at deployment time (container-managed persistence).

In many cases, the underlying data source may be an existing application rather than a database.

Figure 22 Client view of underlying data sources accessed through entity bean

(a) Entity bean is an object view of a record in the database

(b) Entity bean is an object view of an existing application

9.1.3.1 Bean-managed persistence

In the bean-managed persistence case, the entity Bean Provider writes database access calls (e.g. using JDBC API technology or SQLJ) directly in the entity bean component. The data access calls are performed in the ejbCreate(...), ejbRemove(), ejbFind<METHOD>(), ejbLoad(), and ejbStore() methods; and/or in the business methods.

The data access calls can be coded directly into the entity bean class, or they can be encapsulated in a data access component that is part of the entity bean.

Sun Microsystem Inc

We expect that most enterprise beans will be created by application development tools which will encapsulate data access in components. These data access components will probably not be the same for all tools. This EJB specification does not define the architecture for data access objects or strategies.

Directly coding data access calls in the entity bean class may make it more difficult to adapt the entity bean to work with a database that has a different schema, or with a different type of database.

If the data access calls are encapsulated in data access components, the data access components may optionally provide deployment interfaces to allow adapting data access to different schemas or even to a different database type. These data access component strategies are beyond the scope of the EJB specification.

9.1.3.2 Container-managed persistence

In the container-managed persistence case, the Bean Provider does not write the database access calls in the entity bean. Instead, the Container Provider’s tools generate the database access calls at the entity bean’s deployment time (i.e. when the entity bean is installed into a container). The entity Bean Provider must specify in the deployment descriptor the list of the instance fields for which the container provider tools must generate access calls.

The advantage of using container-managed persistence is that the entity bean can be largely independent from the data source in which the entity is stored. The container tools can generate classes that use JDBC API or SQLJ to access the entity state in a relational database, or classes that implement access to a non-relational data source, such as an IMS database, or classes that implement function calls to existing enterprise applications.

The disadvantage is that sophisticated tools must be used at deployment time to map the entity bean’s fields to a data source. These tools and containers are typically specific to each data source.

The essential difference between an entity with bean-managed persistence and one with container-man- aged persistence is that in the bean-managed case, the data access components are provided as part of the entity bean, whereas in the container-managed case, the data access components are generated at deployment time by the container tools.