By Richard Monson-Haefel
1-56592-605-6, Order Number: 6056
344 pages, $32.95
The Enterprise Bean Component
Using Enterprise Beans
The Bean-Container Contract
Summary
As you learned in Chapter 1, Enterprise JavaBeans is a component model for component
transaction monitors, the most advanced type of business application server available
today. To effectively use Enterprise JavaBeans, you need to understand the EJB
architecture, so this book includes two chapters on the subject. This chapter explores the
core of EJB: how enterprise beans are distributed as business objects. Chapter 3 explores
the services and resource management techniques supported by EJB.
To be truly versatile, the EJB component design had to be smart. For application
developers, assembling enterprise beans is simple, requiring little or no expertise in the
complex system-level issues that often plague three-tier development efforts. While EJB
makes it easy for application developers, it also provides system developers (the people
who write EJB servers) with a great deal of flexibility in how they support the EJB
specification.
The similarity of component transaction monitors (CTMs) allows the EJB abstraction to
be a standard component model. Each vendor's CTM is implemented differently, but they
all support the same primary services and similar resource management techniques. The
primary services and resource management techniques are covered in more detail in
Chapter 3, but some of the infrastructure for supporting them is addressed in this chapter.
equipment, an item in inventory, or even a place. In other words, entity beans model real- world objects; these objects are usually persistent records in some kind of database. Our hypothetical cruise line will need entity beans that represent cabins, customer, and ships.
Session beans are an extension of the client application and are responsible for managing
processes or tasks. A Ship bean provides methods for doing things directly to a ship but
doesn't say anything about the context under which those actions are taken. Booking
passengers on the ship requires that we use a Ship bean, but also requires a lot of things
that have nothing to do with the Ship itself: we'll need to know about passengers, ticket
rates, schedules, and so on. A session bean is responsible for this kind of coordination.
Session beans tend to manage particular kinds of activities, for example, the act of
making a reservation. They have a lot to do with the relationships between different
enterprise beans. A TravelAgent session bean, for example, might make use of a Cruise, a
Cabin, and a Customer--all entity beans--to make a reservation.
The activity that a session bean represents is fundamentally transient: you start making a
reservation, do a bunch of work, and then it's finished. A session bean doesn't represent
something in a database. Obviously, session beans have lots of side effects on the
database: in the process of making a reservation, you might create a new Reservation by
assigning a Customer to a particular Cabin on a particular Ship. All of these changes
would be reflected in the database by actions on the respective entity beans. Session
beans like TravelAgent, which is responsible for making a reservation on a cruise, can
even access a database directly by performing reads, updates, and deletes to data. But
there's no TravelAgent record in the database--once the reservation is made, it's done.
What makes this distinction difficult is that it's extremely flexible. The relevant
distinction for Enterprise JavaBeans is that an entity bean has persistent state; a session
bean models interactions but doesn't have any persistent state.
A good way to understand the design of enterprise beans is to look at how you'd go about
implementing one. To implement an enterprise bean, you need to define two interfaces
and two classes:
The remote interface for an enterprise bean defines the bean's business methods:
the methods a bean presents to the outside world to do its work. The remote
interface extendsjavax.ejb.EJBObject, which in turn extends
The bean class actually implements the bean's business methods. Surprisingly, the
bean class usually does not implement the bean's home or remote interfaces.
However, it must have methods matching the signatures of the methods defined in
the remote interface and must have methods corresponding to some of the
methods in the home interface. If this sounds perfectly confusing, it is. We'll try to
clarify this as we go along. An entity bean must extendjavax.ejb.EntityBean;
a session bean must extendjavax.ejb.SessionBean. BothEntityBean and
The primary key is a very simple class that provides a pointer into the database.
Only entity beans need a primary key; the only requirement for this class is that it
implementsSerializable.
The complexity--particularly all the confusion about classes implementing the methods of
an interface, but not implementing the interface itself--comes about because enterprise
beans exist in the middle between some kind of client software and some kind of
database. The client never interacts with a bean class directly; it always uses the methods
of the bean's home and remote interfaces to do its work, interacting with stubs that are
generated automatically. (For that matter, a bean that needs the services of another bean is
just another client: it uses the same stubs, rather than interacting with the bean directly.)
There are also lots of interactions between a bean and its server. These interactions are
managed by a "container," which is responsible for presenting a uniform interface
between the bean and the server. (Although it's incorrect, many people use the terms
"container" and "server" interchangeably. We won't promise consistency ourselves. But
it's helpful to understand the difference.) The container is responsible for creating new
instances of beans, making sure that they are stored properly by the server, and so on.
Tools provided by the container's vendor do a tremendous amount of work behind the
scenes. At least one tool will take care of creating the mapping between entity beans and
records in your database. Other tools generate a lot of code based on the home interface,
the remote interface, and the bean class itself. The code generated does things like create
the bean, store it in the database, and so on. This code (in addition to the stubs) is what
actually implements the two interfaces, and is the reason your bean class doesn't have to.
Before going on let's first establish some conventions. When we speak about an
enterprise bean as a whole, its remote interface, home interface, bean class, and so forth,
we will call it by its remote-interface name, followed by the word "bean." For example,
an enterprise bean that is developed to model a cabin on a ship will be called the "Cabin
bean." Notice that we didn't use a constant width font for "Cabin." We do this because we
are referring to all the parts of the bean (remote interface, home interface, bean class,
etc.) as a whole, not just one particular part like the remote interface or bean class. When
we are talking about the remote interface of the Cabin bean we will use constant width.
For example, the remote interface for the Cabin bean is called theCabin remote interface.
Likewise, we use constant width for the names of the classes that make up the other parts
