Sun Microsystems Inc

This chapter describes the component contract for an entity bean with container managed persistence, and how data independence is maintained between the entity bean instance and its persistent representation. It describes this contract from three viewpoints: from the viewpoint of the entity bean provider, the persistence manager, and the container. It also describes the responsibilities of the bean provider in maintaining the independence of the client view of the entity bean from its persistence view.

The component contract for bean managed persistence is described in Chapter 11.

9.3 Container-managed entity persistence

An entity bean implements an object view of a business entity or set of business entities stored in an underlying database or 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 or application is referred to as persistence.

In container-managed persistence, unlike in bean managed persistence, the Bean Provider does not write database access calls in the entity bean. Instead, persistence is handled by a Persistence Manager that is available to the Container at runtime. The entity Bean Provider must specify in the deployment descriptor those persistent fields and relationships for which the Persistence Manager Provider’s tools must generate data access calls. The Persistence Manager Provider’s tools are then used at the entity bean’s deployment time to generate the necessary database access calls. These persistent fields and relationships constitute the abstract persistence schema of the bean or dependent object class. The deployment descriptor for the entity bean indicates that the entity bean uses container-managed persistence. The Bean Provider of an entity bean with container-manager persistence must code all persistent data access by using the accessor methods that are defined in the bean’s abstract persistence schema. The implementation of the persistent fields and relationships, as well as all data access, is deferred to the Persistence Manager.

A dependent object class is a persistent helper class that is used by one or more entity beans to further model their persistent state. A dependent object is used internally by an entity bean and is itself not directly exposed through the client view. The Bean Provider specifies in the deployment descriptor those persistent fields and relationships of the dependent object class for which the persistence manager provider’s tools must generate data access calls.

It is the responsibility of the Deployer to map the abstract persistence schema of the bean or dependent object class into the physical schema used by the underlying data store (e.g., into a relational schema) by using the Persistence Manager Provider’s tools. The Deployer uses the deployment descriptor as input to the Persistence Manager’s tools to perform this mapping. The Persistence Manager’s tools typically are also used to generate the concrete implementation of the bean’s class and dependent classes, including the code that delegates the bean’s calls to the methods of its abstract persistence schema to the runtime persistent data access layer that is generated by the Persistence Manager Provider’s tools. Typically, the Persistence Manager Provider’s tools take the ejb-jar file produced by the Bean Provider or Assembler and use it to generate a new ejb-jar file that includes the concrete implementations of the entity bean and dependent object classes. This modified ejb-jar file then serves as input to the Container Provider’s tools.

Sun Microsystems Inc.

Entity Bean Component Contract for Container Managed PersistenceEnterprise JavaBeans 2.0, Public Draft Container-managed entity

The EJB deployment descriptor describes logical relationships involving beans and dependent object classes. It does not provide a mechanism for specifying how the abstract bean and dependent object class schemas are to be mapped to an underlying database. This is the responsibility of the Deployer, who, using the Persistence Manager Provider’s tools, uses the logical relationships among beans and dependent object classes that are specified in the deployment descriptor to map to the physical relationships that are particular for the underlying resource or its implementation. It is the responsibility of the Persistence Manager to manage the mapping between logical and physical relationships at runtime and to manage the referential integrity of the relationships.

The advantage of using container-managed persistence is that the entity bean can be logically independent of the data source in which the entity is stored. The Persistence Manager Provider’s tools can generate classes that use JDBC or SQLJ to access the entity state in a relational database; 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. These tools are typically specific to each data source.

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

(a) Entity bean is an object view of a collection of records in the database that are defined by relationships

container

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