In this chapter, we’ll take a thorough look at the process of developing entity beans. A good rule of thumb is that entity beans model business concepts that can be expressed as nouns. Although this is a guideline rather than a requirement, it helps determine 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 abstractions such as reservations. 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. That’s
ultimately the purpose of an entity bean: to provide programmers with
a simpler mechanism for accessing and changing data. It is much
easier to change a customer’s name by calling
Customer.setName( ) than by executing an SQL
command against the database. In addition, using entity beans
provides opportunities for 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, accounts
receivable, 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 entity 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 (frequently called CMP 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.
This chapter and the two that follow focus on entity beans that use container-managed persistence. In EJB 2.1 and EJB 2.0, the data associated with an entity bean can be much more complex than in earlier versions. Container-managed beans can have relationships with other entity beans, a function that was not well supported in the older version—as a result, vendors sometimes offered proprietary solutions that were not portable. In addition, container-managed beans can be finer in granularity so that they can easily model things such as the address, line item, or cabin. The Customer EJB that we’ll define in this chapter 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 use EJB’s support for 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 select methods should behave at runtime.
In CMP, the container automatically manages the entity beans’ state. The container takes care of enrolling the entity bean in transactions and persisting its state to the database. The 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 refer to the abstract accessor methods and not to actual fields declared in the classes.
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.
The CMP entity bean classes are defined using abstract accessor methods that represent virtual persistence and relationship fields. As already mentioned, the actual fields themselves are not declared in the entity classes. Instead, the characteristics of these fields are described in the XML deployment descriptor used by the entity bean. The abstract persistence schema is the set of XML elements in the deployment descriptor that describe the relationship fields and the persistence fields. Together with the abstract accessor methods and some help from the deployer, the container tool will have enough information to map the entity and its relationships to other entity beans to the database.
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 classes may include database access logic optimized for a particular database, database schema, or database configuration. Persistence classes may employ optimizations such as lazy loading and optimistic locking to further improve performance. Because the EJB container generates the persistence classes at deployment time, including the database access logic, bean developers do not have to write the database access code themselves. As an EJB developer, you will never have to deal with database access code when working with CMP 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 and aren’t available to the bean developer.
Figures Figure 6-2 and Figure 6-3 show different container tools, both of which are being used to map the Customer entity bean to a relational database.
