Enterprise JavaBeans 101 - Entity Beans

Introduction

In the first installment in the EJB 101 series, I provided a brief overview of Enterprise JavaBeans (EJB) technology followed by an introduction of one of the EJB types � the Session Bean. In this installment, I will discuss another type of EJB, the Entity Bean. Specifically, I provide an overview of the different types and then describe their relevance within Excellus.

Entity Beans

Entity Beans are another type of EJB that provide interaction various data sources on behalf of a client program. One can think of Entity Beans as the I/O modules of the Java world. There are two types of Entity Beans. The first type is the Container-Managed Persistence (CMP) Bean and the second is the Bean-Managed Persistence (BMP) bean. I will describe each of those in the following sections.

CMP Beans

War Story

In a previous job with a now remnant of a dot-com company, we did much of our web development with proverbial spears and stones. Specifically, we wrote our applications with the C language in order to maximize portability between disparate UNIX platforms and to ensure performance would be acceptable. We created and supported a large public job search database so performance was foremost on our minds.[1]

One of my responsibilities was to be the keeper of the data model and to maintain a core library of �classes� that could be used for higher-level functionality. A key part of this library was what we called the rdb (relational database) series of modules that we wrote for each type. Each rdb module was capable of performing all the key database operations (select, insert, update, delete) with the particular type. If we had a data type called customer_t, we would have a customer_rdb module to support the I/O operations to the database. At first, we hand wrote this code. That worked for the first six to ten data types. Then our hands started to hurt from all the typing! Furthermore, since we were using a lower-level language like C, the propensity to introduce errors into the code was much higher especially when working sixty hours a week fueled solely by pizza, caffeine, and the occasional chicken vindaloo.

After the first release of a particular product, we decided that there was a better way to make a living. We also realized that we were going to have nearly 100 data types in a future release of the product so we needed a solid strategy to save our fingers from cramping on the keyboard.

Enter my buddy D. D was many years my junior, wore his hair much longer than mine and was really, really smart. Smart like he could do hexadecimal math in his head and recite almost a hundred places for PI. D created a way to read the database catalog tables and generate the necessary code to perform the database operations. It was really slick! All I needed to do was to modify the data model, generated the SQL code and then modify the database. Once those tasks were complete I ran D�s magic code generator and POOF! out came the code ready to compile and distribute to the rest of the development team.

Back to Reality

With CMP beans, we have the same advantage that I had with D�s magic code generator except there are many D�s working within companies like IBM solely devoted to the task of writing the code generators. With CMPs, the developer is not required does not write the code to select, insert, update, or delete an object from a database. Rather, the developer configures the bean using a series of IDE wizards and generates what is known as deployment code. The benefit of this approach is the developer is liberated from having to write repetitive (and thus error-prone) I/O code. Not only does this practice make for a happy WebSphere Application Server (WAS) administrator, but it also makes for happy database administrators (DBA) because us pesky Java folks aren�t hogging all the database threads with bad code. Another benefit is that it�s just plain faster to create a CMP bean to interact with one or more database tables.

The disadvantage with CMP beans is that the developer has less control over what is happening. Basically, the developer is at the mercy of the application server vendor to create proper database I/O code. Also, in some limited cases, CMPs do not fulfill the functional requirements of a particular aspect of a system. Fortunate for us, there is still a way to hand-code a solution using something called a BMP bean.

BMP Beans

MP beans are still first-class EJBs in that they are eligible for nearly the same manageability features of other EJB types. However, they require the developer to code all interactions with the data source. In some respects, we travel back prior to the creation of D�s magic code generator. However, there may be valid reasons for the developer to choose BMP beans. For instance in order to optimize database access, accommodate intricate search requirements, or deal with non-relational data stores such as a flat file, IMS database, or other persistent data store. The developer may also need to integrate a non-EJB I/O class into an EJB framework for proper transaction and/or security control (more on these features in a future article).

Like CMP beans, BMP beans have a particular way of being written and the literature on the topic spells out exactly how this should be done. The developer is not left to his own devices to create random bits of code and hope it works.

Entity Beans in the Field

Within Excellus, two projects are currently using CMP beans while another project is using both CMP and BMP beans. The PIMS and Contract Development System (CDS) use CMP beans as the primary mechanism for RDBMS I/O. The Product Central system uses a mix of BMP and CMP beans for persistence.

Regardless of type, Entity Beans are generally used within a Session Bean. The rationale behind this approach is to shield the client layer of the application (usually the presentation layer) from the intricacies of the database that stores the data. By employing this type of layers technique, one dramatically increases the maintainability of a system. This maintainability is achieved by allowing database structures to vary without adversely affecting other layers of the application. There are other benefits to this approach described in [4].

Summary

In this article, I provided a very brief overview of Entity Beans. I described the two types of beans, the CMP and the BMP bean, while including some rationale around the choice of each type. In the next article, I will describe Message-Driven Beans that can be used with asynchronous messaging systems like WebSphere MQ messages.

If you have additional questions or are interested in more information on how your team can begin learning J2EE technology, please contact me at the email address listed below. I would be happy to visit teams to discuss any J2EE-related topic in further detail.

References

1. Shirah, Joe Sam. Getting Started with Enterprise JavaBeans Technology. http://ibm.com/developerworks/java/edu/j-dw-java-gsejb-i.html.

2. Sun Microsystems. Enterprise JavaBeans 2.0 Specification. http://java.sun.com/j2ee/1.3/docs.

3. Roman, Ambler, Jewell. Mastering Enterprise JavaBeans 2/e. Available in the Excellus iSpace Teamroom.

4. Sun Microsystems. Session Fa�ade Design Pattern. http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html.