EJB Architecture—Overview

The Enterprise JavaBeans architecture provides for enabling standard portable solutions to enterprisewide business problems using the Java programming language, thereby leveraging the Write Once, Run Anywhere concept advocated by Java. The standards-based solution enables you to build distributed object-oriented applications by breaking down business rules into components that represent the business model as closely as possible. Component models provide the technology for application developers to build applications based on components driven by their interfaces rather than building new components every time one needs a new function. Let's take a classic business case: the shopping cart example that's used widely in online bookstores, grocery stores, and so forth. Some of the most common components that make up this enterprise application include the customer, shopping cart, and more. These are components that should be readily available in the component market in an easily deployable mode for any application server and can be used to build the complete enterprise application.

Enterprise JavaBeans is based on distributed object technologies, and object middleware usually enables communication between the distributed objects. The object middleware is also responsible for providing the services necessary for transparent access to the different layers of the component irrespective of distributed system complexities (that is, the heterogeneous software/hardware platforms). Distributed component technologies combine the power of middleware technology and the characteristics of components to provide for an interaction between components and they are leveraged well in the EJB implementation.

The architecture also provides services such as transactions, connection management, and location transparency to make it easier for developers to concentrate on the business logic when developing components and leave the management of the infrastructure services to the application server. The architecture also addresses the deployment and life cycle properties of an enterprise bean.

With all these properties, the EJB framework provides an effective solution to most complex business problems; for example, an airline reservation system. These business problems can typically be effectively addressed by breaking them down into different components depending on each component's role within the business solution. For example, in an airline reservation system, the important elements are data components such as customers, tickets, and flights, and the business processes are activities such as making a reservation and so on. The requirements of the business processes and entities are different. The EJB framework addresses this issue very effectively by mapping the business elements into different types of EJBs depending on the mapped business component. We'll look at how these mappings are achieved with the help of the different EJB types when we cover them in the next section.

EJB Types

Enterprise JavaBeans come in three flavors: Session, Entity, and Message-Driven. The EJB types help model the business processes and entities effectively. Apart from this, these beans also differ in what Java technology they use. The underlying Java technology implementing Session and Entity beans is RMI. Different client types can access these objects (servlets or standard Java applications) using distributed object protocols. On the other hand, the Message-Driven bean introduced in EJB 2.0 is based on the Java messaging infrastructure—JMS. Message-Driven beans are asynchronous whereas the other two types respond to synchronous requests. Let's look at each of the EJB types in detail.

Session Beans

Session beans represent business processes. In other words, they represent workflow that describes the steps involved in finishing a business flow or task, such as booking an airline ticket. Session beans usually work with one or more Entity beans or directly with the database itself to implement the workflow. Session beans help to create the interactions between the different entities that make up a business process. In the airline reservation system business case, customer, credit card, and ticket will not make sense without defining the interactions between them, such as customer's reservation, authorization of the credit card, and so on.

Session beans come in two distinct flavors: Stateless and Stateful. The flavor of session bean is based on the type of conversation involved in the business task being executed.

Stateless

In the Stateless type of session bean, the conversations between the client and the EJB are limited to one interaction at a time. A Stateless Session bean does not store any state information pertaining to the client that invoked it. This high-performance bean type is used for business processes that finish the defined task in one method invocation. All information required for the execution of the business task is passed to the method. Although passing all necessary information could be construed as a disadvantage, Stateless Session beans offer a host of other advantages:

• Stateless Session beans are less resource-intensive because they don't store information about clients or the previous requests they handled.

• A Stateless Session bean instance is not attached to a single client, thereby enabling multiple clients to share a few instances of the bean (pooling). As soon as a Stateless Session bean completes a request, it's available to process another client request.

• Because the Stateless Session bean is not attached to a particular client, there's no information about the client on the EJB server to store in a temporary store for use at a later time when the same client comes back to process another request. In EJB terms, the Stateless Session bean need not be passivated when the request is complete or activated when a client comes back. This reduces the overhead involved in swapping the bean to another client or pushing it back to the free bean pool. The processes of activation and passivation are explained in detail later in this section.

Although Stateless Session beans do not maintain client state information, they can cache information that can be shared between the clients such as by using a logging file handle or a database connection. But this information does not pertain to a particular client.

In the airline reservation business case, the payment process using credit card is a Stateless Session bean (ChargeCustomerEJB). The only task of this EJB is to charge the customer for a successful reservation. After the bean charges a customer for the reservation, it moves to other customers but retains no information from the first client.

All Stateless Session bean instances of a particular type (for example, ChargeCustomerEJB) are considered to be the same. Their internal state information does not enable identifying them distinctively by either the client that is accessing them or by the container in which they run. A client does not care which instance of the Stateless Session bean is processing the request because any free instance can do so. This behavior drives the high-performance behavior of beans of this type because they can be pooled, swapped, and reused for multiple clients.

Stateful

Stateful Session beans are used to model business processes that span multiple interactions between the client and the EJB server. Every bean instance of this type is associated with a client for the life of the bean instance. In other words, Stateful Session beans can be seen as extensions of the client inside the server. A session bean acts as if it were part of the client inside the server. So, whatever the bean does will be specific to the client that created it. This kind of bean holds client state and is not shared across different client instances. Stateful Session beans store conversational state; that is, client identification data that can be used to identify the client between the multiple method calls that define a single business process. This client state information is volatile and is not persisted to a permanent data store as in the case of Entity beans, which are described next.

The specification suggests that once the Stateful Session bean is instantiated, it is associated with the client for its entire life cycle. But to increase performance, most EJB containers (including WebLogic Server) implement a passivation mechanism with Stateful Session beans. The passivation mechanism is explained later in the chapter when we get to EJB life cycle management. In a common business case—the XYZ store sells books online—the customer task (choosing the books he needs), payment option (the customer choosing from the list of options presented to him), and placing the order are good candidates for implementing as a Stateful Session bean. The Stateful Session EJB encapsulates the business logic of assembling the order and placing it on the server, thereby enabling the client to be thin. The bean also stores the conversational state of the client. Table 20.1 lists some of common examples of session beans.

Table 20.1. Session Bean Examples

Business Case	Session Bean Type
Credit card verification	Stateless
Shopping cart: online grocery, book store, and so on	Stateful
Online banking: multi-page account management	Stateful
Online airline reservation: travel agent	Stateful
Online sports scoreboard	Stateless
Stock quotes	Stateless

Entity Beans

So far, we've looked at the components that can be used to define application logic: Session beans. These components represented actions; that is, verbs. Session beans help model business processes and also manage workflow. Stateful Session beans provide a framework for storing the client state information that can be used for long-running conversations between the client and the EJB component, which might span multiple method calls. But they cannot be used as persistent data components. The Enterprise JavaBeans specification defines Entity beans for mapping business objects, such as customer and account, into the EJB world. In other words, Entity beans provide a framework for persistent data. They model business processes that are usually expressed as nouns. In the airline reservation business case, credit card, and customer are excellent candidates for modeling as Entity beans because they represent persistent data objects. Let's look at some of characteristics of Entity beans:

• Entity beans have the capability to persist the entity to a permanent storage such as a database.

• Entity beans encapsulate business data such as the customer and credit card. They do not implement any workflow logic—that's done by Session beans.

• Entity beans represent the object form of a database record, thereby providing a convenient and effective mechanism for manipulating the data because these components come with setters and getters (getLastName() and setLastName() are simpler than the equivalent SQL commands).

When a new Entity bean is created, it actually creates a new record in the persistent store and the bean instance is associated with that record. As the EJB state undergoes state transition, it affects the underlying data record as well. That is, the record is inserted, modified, or removed depending on the operation being performed on the bean instance. The process of keeping the data object, represented by the bean, and the corresponding database record in sync is defined as persistence. The type of persistence logic chosen by the bean implementer determines the type of the Entity bean. There are two flavors of Entity beans: bean-managed persistence (BMP) and container-managed persistence (CMP).

Bean-Managed Persistence

In this type of Entity bean, the bean implementer has to take care of writing the logic in the Entity bean for all the database operations he wants to perform. All manipulations of the database are manual. The container provides only a basic framework with which it communicates to the bean as to when a database operation such as insert, delete, or update can be performed. From the implementation point of view, BMP involves more effort because the data persistence logic is left to the implementer, unlike CMP, which is discussed next. Although writing the logic for database inserts, updates, and deletes can be construed as a major disadvantage, BMP provides better control in complex database situations, such as heterogeneous data sources in the backend or the use of a complex legacy system where the CMP mechanism isn't adequate for mapping the data objects to Entity beans. Additionally, the implementer has to take care of database changes, such as structure/type changes, because the implemented bean instance is tied to the specific database design.

Container-Managed Persistence

In this Entity bean type, the container manages the relationship between the bean instance and the underlying data it represents. The container performs the database manipulations—insertion, deletion, and updating the data records—because it is aware of the relationship of the database fields and the corresponding Entity bean data objects. Container-managed persistence was one of the most key topics that underwent considerable change in the EJB 2.0 specification. One of the major drawbacks in the earlier version was the loosely defined Entity bean relationship. The EJB 2.0 CMP model addresses this requirement very well and now Entity beans can have relationships with other Entity beans, while being fully portable to all EJB containers that implement the EJB 2.0 specification. In addition to bean-to-bean relationships, EJB 2.0 also introduced the Enterprise JavaBeans Query language (EJB-QL), which helps defining the query methods (finder and select) in CMP.

Message-Driven Beans

Message-Driven is a new type of Enterprise JavaBean introduced in EJB 2.0 specification. Although Session and Entity beans are used for synchronous request/response, Message-Driven bean (MDB) is an asynchronous enterprise bean that processes JMS messages from configured topics or queues.

Message-Driven beans are based on the Java Messaging Service (JMS) technology that forms an integral part of the J2EE platform. JMS provides the infrastructure and well-defined APIs for implementing enterprise-messaging applications. Being asynchronous, JMS allows for designing enterprise applications, which do not need a reply immediately. This loosens the links between the client requests and the availability of the application server for processing requests immediately. In the JMS messaging model, a client sends messages asynchronously to a configured destination. The destination determines how the requests are processed. The JMS specification defines two types of messaging models: publish and subscribe (pub/sub) and point to point (ptp).

The pub/sub messaging model is used when the message is to be sent to multiple recipients (for example, stock quotes) and the ptp model is used when the message is to be processed only once (for example, a ticket reservation). The destination type in the pub/sub messaging model is a topic, and in the case of the ptp messaging model, it is a queue.

In both messaging models, JMS clients send messages to a configured destination. Message-Driven beans pick up the messages asynchronously for processing. It is a common pattern to see an MDB, after processing, put a reply back in a reply destination, and to see that reply picked up by the client that posted the original message. For a detailed description of JMS and about using them, refer to the chapter on JMS (see Chapter 12, “Enterprise Messaging with JMS”).

Message-Driven beans are a special type of JMS component that provides a stateless component for processing JMS messages. Being part of the Enterprise JavaBeans framework, the EJB container provides the necessary infrastructure and services such as transactions, security, and concurrency. The container also manages the Message-Driven bean environment and life cycle, including acknowledging messages.

For example, in the online bookstore application, a ShipmentEJB could be a Message-Driven bean that processes shipment orders. The orders are sent asynchronously as JMS messages.