The following overview of EJB 1.1 container-managed persistence is pretty much duplicated in Chapter 6, but for EJB 1.1 readers who have not read Chapter 6, the overview is important to understanding the context of entity beans and container-managed persistence.

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, customers, 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 Ship EJB encapsulates the data and business rules associated with a ship, and so on. 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 a Ship EJB in this chapter. Titan could clearly make use of a Customer EJB, 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 really 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 ship’s name by calling ShipRemote.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 ship, for example, is used in many areas of Titan’s business, including booking, scheduling, and marketing. A Ship EJB provides Titan with one complete way of accessing ship information, and thus it ensures that access to the information is consistent and simple. Representing data as entity beans makes 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, and they are distinguished by how they manage persistence. Container-managed persistence beans have their persistence automatically managed by the EJB container. The container knows how a bean instance’s persistence fields and relationships 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.