Sun Microsystems Inc

Chapter 11 Entity Bean Component Contract for Bean Managed Persistence

The entity bean component contract for bean managed persistence is the contract between an entity bean and its container. It defines the life cycle of the entity bean instances and the model for method delegation of the client-invoked business methods. The main goal of this contract is to ensure that a component using bean managed persistence is portable across all compliant EJB Containers.

This chapter defines the enterprise Bean Provider’s view of this contract and the Container Provider’s responsibility for managing the life cycle of the enterprise bean instances. It also describes the Bean Provider’s responsibilities when persistence is provided by the Bean Provider.

11.1 Overview of Bean Managed Entity Persistence

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.

Entity Bean Component Contract for Bean Managed PersistenceEnterprise JavaBeans 2.0, Public Draft Overview of Bean Managed

The entity bean component protocol for bean managed persistence allows the entity Bean Provider 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. This chapter describes the contracts for bean managed persistence. Container managed persistence, which allows the entity Bean Provided to delegate the entity bean’s persistence to the Container Provider and Persistence Manager Provider tools used at deployment time, is discussed in Chapter 10.

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

Figure 37 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

11.1.1 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.

Sun Microsystems Inc

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 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.

11.1.2 Entity Bean Provider’s view of persistence and relationships

Using bean-managed persistence, the entity Bean Provider writes database access calls (e.g. using JDBCTM or SQLJ) directly in the entity bean component. The data access calls are performed in the ejbCreate<METHOD>(...), 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. 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.

Sun Microsystems Inc.

Entity Bean Component Contract for Bean Managed PersistenceEnterprise JavaBeans 2.0, Public Draft Overview of Bean Managed

We expect that most enterprise beans with bean managed persistence 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. Further, if the data access calls are encapsulated in data access components, the data access components may require deployment interfaces to allow adapting data access to different schemas or even to a different database type. This EJB specification does not define the architecture for data access objects, strategies for tailoring and deploying data access components or ensuring portability of these components for bean managed persistence.

In contrast to container managed persistence, the entity bean provider does not provide a description of the relationships and dependent classes in the deployment descriptor. With bean managed persistence, it is the responsibility of the bean provider to maintain relationships within the code that he or she supplies. With bean managed persistence, it is also the responsibility of the bean provider to locate related beans by utilizing JNDI lookup. The bean provider knows about the mapping of the primary keys and handles to objects and must consider how a schema should be persisted since with bean managed persistence the container does not provide help in this area.

11.1.3 Runtime execution model

This section describes the runtime model and the classes used in the description of the contract between an entity bean with bean managed persistence and its container.

Sun Microsystems Inc

Figure 38 Overview of the entity bean runtime execution model

container

EJBHome

EJB objects

EJB objects

enterprise bean instances

EJBObjects

enterprise bean 2

An enterprise bean instance is an object whose class was provided by the Bean Provider.

An entity EJBObject is an object whose class was generated at deployment time by the Container Provider’s tools. The entity EJBObject class implements the entity bean’s remote interface. A client never references an entity bean instance directly—a client always references an entity EJBObject whose class is generated by the Container Provider’s tools.

An entity EJBHome object provides the life cycle operations (create, remove, find) for its entity objects as well as home business methods, which are not specific to an entity bean instance. The class for the entity EJBHome object is generated by the Container Provider’s tools at deployment time. The entity EJBHome object implements the entity bean’s home interface that was defined by the Bean Provider.