In Chapter 4, we started developing some simple enterprise beans, skipping over a lot of the details about developing enterprise beans. In this chapter, we’ll take a thorough look at the process of developing entity beans. Entity beans model business concepts that can be expressed as nouns. This is a rule of thumb rather than a requirement, but it helps in determining when a business concept is a candidate for implementation as an entity bean. In grammar school, you learned that nouns are words that describe a person, place, or thing. The concepts of “person” and “place” are fairly obvious: a person EJB might represent a customer or passenger, and a place EJB might represent a city or port-of-call. Similarly, entity beans often represent “things”: real-world objects like ships, credit cards, and so on. An entity bean can even represent a fairly abstract thing, such as a reservation. Entity beans describe both the state and behavior of real-world objects and allow developers to encapsulate the data and business rules associated with specific concepts; a Customer EJB encapsulates the data and business rules associated with a customer, for example. This makes it possible for data associated with a concept to be manipulated consistently and safely.

In Titan’s cruise ship business, we can identify hundreds of business concepts that are nouns and, therefore, could conceivably be modeled by entity beans. We’ve already seen a simple Cabin EJB in Chapter 4, and we’ll develop Customer and Address EJBs in this chapter. Titan could clearly make use of a Cruise EJB, a Reservation EJB, and many others. Each of these business concepts represents data that needs to be tracked and possibly manipulated.

Entities represent data in the database, so changes to an entity bean result in changes to the database. There are many advantages to using entity beans instead of accessing the database directly. Utilizing entity beans to objectify data provides programmers with a simpler mechanism for accessing and changing data. It is much easier, for example, to change a customer’s name by calling Customer.setName() than by executing an SQL command against the database. In addition, objectifying the data using entity beans provides for more software reuse. Once an entity bean has been defined, its definition can be used throughout Titan’s system in a consistent manner. The concept of a customer, for example, is used in many areas of Titan’s business, including booking, scheduling, and marketing. A Customer EJB provides Titan with one complete way of accessing customer information, and thus it ensures that access to the information is consistent and simple. Representing data as entity beans can make development easier and more cost-effective.

When a new EJB is created, a new record must be inserted into the database and a bean instance must be associated with that data. As the EJB is used and its state changes, these changes must be synchronized with the data in the database: entries must be inserted, updated, and removed. The process of coordinating the data represented by a bean instance with the database is called persistence .

There are two basic types of entity beans, distinguished by how they manage persistence: container-managed persistence beans and bean-managed persistence beans. For container-managed persistence beans, the container knows how a bean instance’s persistence and relationship fields map to the database and automatically takes care of inserting, updating, and deleting the data associated with entities in the database. Entity beans using bean-managed persistence do all this work manually: the bean developer must write the code to manipulate the database. The EJB container tells the bean instance when it is safe to insert, update, and delete its data from the database, but it provides no other help. The bean instance does all the persistence work itself. Bean-managed persistence is covered in Chapter 10.

In EJB 2.0, container-managed persistence has undergone a change so dramatic that it is not backward compatible with EJB 1.1. For this reason, EJB 2.0 vendors must support both EJB 2.0’s and EJB 1.1’s container-managed persistence models. The EJB 1.1 model is supported so that application developers can migrate their existing applications to the new EJB 2.0 platform as painlessly as possible. It’s expected that all new entity beans and new applications will use the EJB 2.0 container-managed persistence and not the EJB 1.1 version. Although EJB 1.1 container-managed persistence is covered in this book, it should be avoided unless you maintain a legacy EJB 1.1 system. EJB 1.1 container-managed persistence is covered in Chapter 9.

This chapter and the two that follow focus on developing entity beans that use EJB 2.0 container-managed persistence. In EJB 2.0, the data associated with an entity bean can be much more complex than was possible in EJB 1.1. In EJB 2.0, container-managed persistence entity beans can have relationships with other entity beans, which was not well supported in the older version—as a result, vendors sometimes offered proprietary solutions that were not portable. In addition, container-managed persistence entity beans, in EJB 2.0, can be finer in granularity so that they can easily model things such as the address, line item, or cabin.

This chapter develops two very simple entity beans—the Customer and Address EJBs—which will be used to explain how Enterprise JavaBeans 2.0 container-managed persistence entity beans are defined and operate at runtime. The Customer EJB has relationships with several other entities, including the Address, Phone, CreditCard, Cruise, Ship, Cabin, and Reservation EJBs. In the next few chapters, you’ll learn how to leverage EJB 2.0’s powerful support for entity bean-to-bean relationships and will also come to understand their limitations. In addition, in Chapter 8 you will learn about the Enterprise JavaBeans Query Language (EJB QL), which is used to define how the find methods and the new select methods should behave at runtime.

It is common to refer to EJB 2.0 container-managed persistence as CMP 2.0. In the chapters that follow, we will use this abbreviation to distinguish between CMP 2.0 and CMP 1.1 (EJB 1.1 container-managed persistence).

The Abstract Programming Model

In CMP 2.0, entity beans have their state managed automatically by the container. The container takes care of enrolling the entity bean in transactions and persisting its state to the database. The enterprise bean developer describes the attributes and relationships of an entity bean using virtual persistence fields and relationship fields. They are called virtual fields because the bean developer does not declare these fields explicitly; instead, abstract accessor (get and set) methods are declared in the entity bean class. The implementations of these methods are generated at deployment time by the EJB vendor’s container tools. It’s important to remember that the terms relationship field and persistence field are referring to the abstract accessor methods and not to actual fields declared in the classes. This use of terminology is a convention in EJB 2.0 with which you should become comfortable.

In Figure 6-1, the Customer EJB has six accessor methods. The first four read and update the last and first names of the customer. These are examples of persistence fields: simple direct attributes of the entity bean. The last two accessor methods obtain and set references to the Address EJB through its local interface, AddressLocal. This is an example of a relationship field called the homeAddress field.

Figure 6-1. Class diagram of Customer and Address EJBs

Container Tools and Persistence

One of the responsibilities of the vendor’s container-deployment tool is generating concrete implementations of the abstract entity beans. The concrete classes generated by the container tool are called persistence classes . Instances of the persistence classes are responsible for working with the container to read and write data between the entity bean and the database at runtime. Once the persistence classes are generated, they can be deployed into the EJB container. The container informs the persistence instances (instances of persistence classes) when it’s a good time to read and write data to the database. The persistence instances perform the reading and writing in a way that is optimized for the database being used.

The persistence classes will include database access logic tailored to a particular database. For example, an EJB product might provide a container that can map an entity bean to a specific database, such as the Oracle relational database or the POET object database. This specificity allows the persistence classes to employ native database optimizations particular to a brand or kind of database, schema, and configuration. Persistence classes may also employ optimizations such as lazy loading and optimistic locking to further improve performance.

The container tool generates all the database access logic at deployment time and embeds it in the persistence classes. This means that the bean developers do not have to write the database access logic themselves, which saves them a lot of work; it can also result in better-performing entity beans, because the implementations are optimized. As an entity bean developer, you will never have to deal with database access code when working with CMP 2.0 entities. In fact, you probably won’t have access to the persistence classes that contain that logic, because they are generated by the container tool automatically. In most cases, the source code is not available to the bean developer.

Figures 6-2 and 6-3 show different container tools, both of which are being used to map the Customer entity bean to a relational database.

Figure 6-2. Borland AppServer deployment tool