From the developer’s point of view, bean-managed persistence (BMP) requires more effort than container-managed persistence, because you must explicitly write the persistence logic into the bean class. In order to write the persistence-handling code into the bean class, you must know what type of database is being used and the how the bean class’s fields map to that database.
Given that container-managed persistence saves a lot of work, why would anyone bother with bean-managed persistence? The main advantage of BMP is that it gives you more flexibility in how state is managed between the bean instance and the database. Entity beans that use data from a combination of different databases or other resources such as Enterprise Resource Planning (ERP) or legacy systems can benefit from BMP. Essentially, bean-managed persistence is the alternative to container-managed persistence when the container tools are inadequate for mapping the bean instance’s state to the backend databases or resources. In most cases, you won’t need to use BMP because most projects use relational databases which are supported by CMP, but BMP remains an excellent alternative when you need to represent data as entities from unsupported resources. When you do use BMP is likely that you will create entity beans that wrapper a J2EE Connector API that is accessing an ERP (e.g., SAP, PeopleSoft, etc.), legacy system (e.g., CICS, IMS, etc.), or proprietary resource of some type. You may also employ the JDO API (Java Data Object) to access an object-oriented database or some other resource. Its also possible that you will use more than one API to present a single view of data from two or more resources.
The primary disadvantage of
BMP is obvious: more work is required to
define the bean. You have to understand the structure of the database
or resource and the APIs that access them, and you must develop the
logic to create, update, and remove data associated with entities.
This requires diligence in using the EJB callback methods (e.g.,
ejbLoad( ) and ejbStore( ))
appropriately. In addition, you must explicitly develop the find
methods defined in the bean’s home interfaces.
Tip
The select methods used in container-managed persistence are not supported in bean-managed persistence.
Another disadvantage of BMP is that it ties the bean to a specific database or resource type and structure. Any changes in the database or in the structure of data require changes to the bean instance’s definition, and these changes may not be trivial. A bean-managed entity is not as database independent as a container-managed entity, but it can better accommodate a complex or unusual set of data.
To help you understand how BMP works, we
will create a new Ship EJB that is similar to the one used in Chapter 7. For BMP, we need to implement the
ejbCreate( ), ejbLoad( ),
ejbStore( ), and ejbRemove( )
methods to handle synchronizing the
bean’s state with the database.
We will need a remote interface for the Ship EJB. This interface is basically the same as any other remote or local interface. It defines the business methods used by clients to interact with the bean:
package com.titan.ship;
import javax.ejb.EJBObject;
import java.rmi.RemoteException;
public interface ShipRemote extends javax.ejb.EJBObject {
public String getName( ) throws RemoteException;
public void setName(String name) throws RemoteException;
public void setCapacity(int cap) throws RemoteException;
public int getCapacity( ) throws RemoteException;
public double getTonnage( ) throws RemoteException;
public void setTonnage(double tons) throws RemoteException;
}We will not develop a local interface for the bean-managed Ship bean in this chapter; however, bean-managed entity beans can have either local or remote component interfaces, just like container-managed entity beans.
The ShipRemote definition uses a series of
accessor methods whose names begin with
"
set” and
“get.” This is not a required
signature pattern, but it is the naming convention used by most Java
developers when obtaining and changing the values of object
attributes or fields. These methods are often referred to as
setters
and
getters.
These methods should be defined independently of the anticipated
storage structure of the data. In other words, you should design the
remote interface to model the business concepts, not the underlying
data. Just because there’s a getCapacity( ) method doesn’t mean that there has to be
a capacity field in the bean or the database; the
getCapacity( ) method could conceivably compute
the capacity from a list of cabins by looking up the
ship’s model and configuration, or with some other
algorithm.
Defining entity business methods according to the business concept and not the underlying data is not always possible, but you should try to employ this strategy whenever you can. The reason is twofold. First, the underlying data doesn’t always clearly define the business purpose or concept being modeled by the entity bean. Remote and local interfaces are often used by developers who know the business but not the database configuration. It is important to them that the entity bean reflect the business concept. Second, defining the properties of the entity bean independently of the data allows the bean and data to evolve separately. This is important because it allows a database implementation to change over time; it also allows for new behavior to be added to the entity bean as needed. If the bean’s definition is independent of the data source, the impact change is limited.