Being persistent: Tackling Entity JavaBeans

Enterprise Java Beans (EJB) allow for greater code reuse and design flexibility. Our EJB series continues with a look at Entity Beans and what it means to objects that live beyond the life of a session.

To take full advantage of J2EE's Enterprise JavaBeans (EJB) architecture, your applications shouldn't rely solely on Session Beans—beans symbolic of actions, tasks, or processes performed. The most effective apps combine transient functionality and persistent objects. A method to change a user's password, for instance, applies the transient (the change of password) to the persistent (the user.) To leverage EJB functionality in application development, objects lasting beyond the length of a session need to exist. Entity Beans serve this purpose.

Entity encapsulation
Entity JavaBeans encapsulate properties and methods of business objects, much as other object-oriented designs do. The main distinction of Entity Beans lies in their inherent persistent nature. Since Entity Beans persist through storage, their value comes from the extension of the object’s lifecycle. Once created and stored, an Entity Bean outlasts even the lifetime of the EJB container in which it resides. This means that even if the EJB container—or the server running it—crashes, a record of the last version of the object exists for summary use.

Here's a general design rule to follow: If an object in a J2EE application requires storage of its data, and methods of the object modify that data, use an Entity Bean.

Entity Beans best represent business objects that may undergo change, but infrequently. For example, a "user" object in an e-commerce system makes a good Entity Bean. Information like user name, address, and billing preferences remains relatively static. When a user changes his or her address, an Entity Bean reflects the modification, storing it for future reference. The next time the user logs in, the new address appears. Persistence allows the user to interact with the application without entering information multiple times; persistence also allows the developer to concentrate on how components interact instead of worrying about their details.

Taking a couple of steps back
The first two articles in our series will provide some background on working with EJBs:

Storage, not necessarily cold
Although the means of storage for an Entity Bean usually takes the form of a database record, any other form of persistent storage suffices—such as a file on the file system. For the purposes of this article, we assume database storage. The only necessity for storage of an Entity Bean is the ability to determine its unique identity. When reconstituted into an object, the bean exists as it once did. This concept, using a primary key, will appear familiar to those who use databases in their development.

For the primary key philosophy to work properly, the container needs to find specific instances of the bean. The findByPrimaryKey() method takes an object representing the bean's primary key as an argument, returning the bean's remote interface. The primary key class often serves only as a wrapper for another class, as shown in Listing A. In addition to this Entity Bean requirement, developers may implement various other finder methods. Any way to locate a specific instance of a bean works, such as a user name, a zip code, or a product identifier. Finder methods may also return a java.util.Enumeration or java.util.Collection of Entity Beans that match the passed criteria.

Visions of persistence
When building Entity Beans, developers face a choice regarding how to regulate persistence. Beans may either use bean-managed persistence (BMP) or container-managed persistence (CMP). The differences are fairly straightforward. Either the bean or the EJB container takes responsibility for maintaining persistence, primarily retrieving the bean and committing it to storage. Determination of this choice takes place in the deployment descriptor, ejb-jar.xml. Listing B shows the deployment descriptor for a bean using BMP.

Developers should also try to keep the objects “pure” encapsulations of data. Good Entity Bean design incorporates ancillary classes to help provide functionality for the bean. Using separate data access objects to provide communication between database and bean serves as an example. Designing beans this way removes some of the workload from the container when creating or retrieving beans, since helper classes do not need persistence and avoid the overhead.

A bit about BMP
With BMP, the developer must code all database transactions. This includes managing database connections, determining selection logic, and choosing data members to store. Listing C shows an example of a BMP EJB. While a greater degree of control may appeal to the developer's tastes, the choice inherits potential problems. Performance penalties in communication with the database, more time spent coding JDBC logic, and dependencies on schemas of certain databases are issues you may have to contend with.

A bit about CMP
CMP Entity Beans avoid these complexities by requiring the EJB container to handle persistence. Again, this choice occurs in the deployment descriptor, by the line:

When deploying a CMP bean, the container must know which data members to store. Not all data members of an Entity Bean need storage, just the ones that would constitute a complete object. This information, as shown in Listing D, appears in ejb-jar.xml.

Using CMP simplifies development of Entity Beans, removing the complexity of database transactions from the code. CMP also increases the portability of Entity Beans, freeing them from the constraints of a particular database structure. When deploying a CMP bean, the container uses a mapping utility that matches object data members to their corresponding database columns, sometimes creating the tables on the fly. This eases the database design phase of application construction. Unfortunately, allowing the container to manage persistence incurs a big performance hit. Also, some containers, such as those representing multiple data members across multiple tables, may not handle complex objects.

Get the code
You can download the code for this article here.

Entity Beans form the building blocks of a J2EE application by symbolizing autonomous persistent objects. Understanding the relationship between persistent storage, helper classes, and Entity Beans helps developers turn abstract business ideas into a usable application foundation.

Beans, beans, and more beans
Would you like to see more EJB topics? Tell us what you want us to cover by or post a comment below.


Editor's Picks