6.1 EJBs Revisited

As in the chapters before this one, I here assume that you have a basic understanding of Enterprise JavaBeans. Chapter 9 provides an introduction to Enterprise JavaBeans that you should review if you do not have this foundation. Nevertheless, I want to start off with a review of the basic elements of the EJB architecture. If you have no experience with Enterprise JavaBeans, you will find this review lacking. I therefore recommend going through a book on the subject such as Enterprise JavaBeans (O'Reilly) by Richard Monson-Haefel to go in depth into EJB programming.

6.1.1 The Components of a Bean

Figure 6-1 is a UML class diagram that shows all of the elements of a single entity bean.

Figure 6-1. The classes that make up a single EJB

Each EJB requires three classes:

• A home interface

• A remote interface

• An implementation class

Though coding three classes to manage one basic business concept can be tedious, many IDEs manage that tedium for you these days.

The home interface identifies the metaoperations that control the bean at a class level. It manages the creation of new instances, the deletion of instances, and the searching for bean instances. It is basically your gateway to the bean.

The remote interface defines the public business operations supported by the bean. You include in this interface only those operations you want clients to be able to trigger.

Finally, the implementation class is where your attention should be focused. It is not an implementation of either the home or remote interfaces—though you do have to implement some of the methods they prescribe. The EJB container generates classes to implement your home and remote interfaces. Those container-generated classes delegate their behavior to the actual business logic that you write in the implementation class. It also handles the persistence operations I will be describing later in the chapter.

You create the server side of an EJB application by putting together a set of session and entity beans to support your business transactions and the logic behind them. Session beans manage the business transactions and entity beans manage the persistent concepts involved in those transactions. For example, in Chapter 5, I introduced two entity beans: a book and an author. If we were to create a library system that enabled you to manage books in a library, you might have a "front desk" session bean to handle check-in and check-out operations. Figure 6-2 illustrates these dynamics.

Figure 6-2. Session and entity beans working together

6.1.2 Kinds of Beans

The core persistent elements in any EJB system are the entity beans. They represent the concepts in your problem domain that transcend the particulars of workflow. If you were to build a travel reservations system, for example, you would have core concepts like a seat on a plane, a room in a hotel, or a rental car. No matter what kind of travel agency you have—business travel or leisure travel, major agency or a one-person shop—these concepts will not vary.

In an enterprise system, entity beans represent those timeless concepts that operate independent of the particulars of the workflows in which they are managed. What vary are the workflows that describe the way in which these timeless things interact. For example, the rules governing the booking of travel for business travel vary greatly from the rules for leisure travel. Session beans are the EJB tools for describing those rules.

6.1.2.1 Entity beans

Under the initial EJB paradigm published by Sun, an entity bean was any persistent object. As people began developing EJBs, they found that treating entity beans so narrowly resulted in unworkable applications. Looking back to the example of the card catalog from the previous chapter, a client application listing books might be inclined to call getBookID( ) and getTitle( ) on each book to display the list in a table.

While elegant in theory, this approach is unworkable in practice. The first problem is that long lists of entities end up being loaded into memory on the server when only a subset of data from a handful of them is required. For a travel reservations system in which a client will pull from a list of thousands of flights, the result is a system that cannot meet performance demands.

Another problem with this approach is the need to make multiple network calls to get the necessary data. For each book in the list, the client makes two network calls—one for each method. It also needs to make a network call for the initial bean lookup and another call for the subsequent book search.

These days, EJB developers hide entity beans from clients using a variety of techniques I will cover throughout this chapter. The entity bean is still the ultimate representation of transcendental business concepts. Instead of being the business concept as it was originally intended, it can now be thought of as the soul of the business concept.

BEST PRACTICE: Never access entity beans from client applications.

6.1.2.2 Session beans

As entity beans were designed as persistent business objects, session beans were designed as nonpersistent business objects. A nonpersistent business object is a business object that exists, at most, for the lifetime of the application instance. A user session in a web application is the eponymous example of a concept that should be represented as a session bean. The user session exists only as long as the user is logged in. When the user goes away, the session goes away.

As we shall see as we dive deeper into this chapter, session beans have become the windows through which client applications access the system. Through them, you execute transactions and gain access to the information encapsulated in entity beans.

6.1.2.3 Message-driven beans

The EJB 2.0 specification introduced a new kind of bean, the message-driven bean. Unlike regular beans, message-driven beans are asynchronous. In other words, a client calls one of their methods and returns immediately. The logic—generally involving sending messages to external systems—happens in another thread. Practically speaking, message-driven beans enable you to build EJB components that interact with Java Message Service (JMS) API-supported messaging services like IBM Websphere MQ.