2 Understanding Enterprise JavaBeans
Review the different Enterprise JavaBean (EJB) types and the functions they can serve in an application, and how they work with other application objects and WebLogic Server.
It is assumed the reader is familiar with Java programming and EJB 2.x concepts and features.
This chapter includes the following sections:
How Do Applications Use EJBs?
Examine the purpose and capabilities of each bean type.
This section includes the following topics:
Session EJBs Implement Business Logic
Session beans implement business logic. A session bean instance serves one client at a time. There are two types of session beans: stateful and stateless.
Stateless Session Beans
A stateless session bean does not store session or client state information between invocations—the only state it might contain is not specific to a client, for instance, a cached database connection or a reference to another EJB. At most, a stateless session bean may store state for the duration of a method invocation. When a method completes, state information is not retained. Any instance of a stateless session bean can serve any client—any instance is equivalent. Stateless session beans can provide better performance than stateful session beans, because each stateless session bean instance can support multiple clients, albeit one at a time.
Example: An Internet application that allows visitors to click a «Contact Us» link and send an email could use a stateless session bean to generate the email, based on the to and from information gathered from the user by a JSP.
Stateful Session Beans
Stateful session beans maintain state information that reflects the interaction between the bean and a particular client across methods and transactions. A stateful session bean can manage interactions between a client and other enterprise beans, or manage a workflow.
Example: A company Web site that allows employees to view and update personal profile information could use a stateful session bean to call a variety of other beans to provide the services required by a user, after the user clicks «View my Data» on a page:
- Accept the login data from a JSP, and call another EJB whose job it is to validate the login data.
- Send confirmation of authorization to the JSP.
- Call a bean that accesses profile information for the authorized user.
Entity EJBs Maintain Persistent Data
An entity bean represents a set of persistent data, usually rows in a database, and provides methods for maintaining or reading that data. An entity bean is uniquely identified by a primary key, and can provide services to multiple clients simultaneously. Entity beans can participate in relationships with other entity beans. The relationships between entity beans are a function of the real-world entities that the entity beans model. An entity bean’s fields and its relationships to other entity beans are defined in an object schema, which is specified in the bean’s ejb-jar.xml deployment descriptor.
An entity bean can have other bean types, such as message-driven or session beans, as clients, or be directly accessed by Web components. The client uses the entity bean to access data in a persistent store. An entity bean encapsulates the mechanics of database access, isolating that complexity from its clients and de-coupling physical database details from business logic.
Example: The stateful session bean in the previous example, which orchestrates services for an employee accessing personal profile information on a company intranet, could use an entity bean for getting and updating the employee’s profile.
Message-Driven Beans Implement Loosely Coupled Business Logic
A message-driven bean implements loosely coupled or asynchronous business logic in which the response to a request need not be immediate. A message-driven bean receives messages from a JMS Queue or Topic, and performs business logic based on the message contents. It is an asynchronous interface between EJBs and JMS.
Throughout its life cycle, an MDB instance can process messages from multiple clients, although not simultaneously. It does not retain state for a specific client. All instances of a message-driven bean are equivalent—the EJB container can assign a message to any MDB instance. The container can pool these instances to allow streams of messages to be processed concurrently.
The EJB container interacts directly with a message-driven bean—creating bean instances and passing JMS messages to those instances as necessary. The container creates bean instances at deployment time, adding and removing instances during operation based on message traffic.
Example: In an on-line shopping application, where the process of taking an order from a customer results in a process that issues a purchase order to a supplier, the supplier ordering process could be implemented by a message-driven bean. While taking the customer order always results in placing a supplier order, the steps are loosely coupled because it is not necessary to generate the supplier order before confirming the customer order. It is acceptable or beneficial for customer orders to «stack up» before the associated supplier orders are issued.
EJB Anatomy and Environment
Examine the classes required for each bean type, the EJB run-time environment, and the deployment descriptor files that govern a bean’s run-time behavior.
This section includes the following topics:
EJB Components
The composition of a bean varies by bean type. Table 2-1 defines the classes that make up each type of EJB, and defines the purpose of the class type.
Table 2-1 Components of an EJB
The remote interface exposes business logic to remote clients—clients running in a separate application from the EJB. It defines the business methods a remote client can call.
The local interface exposes business logic to local clients—those running in the same application as the EJB. It defines the business methods a local client can call.
Note : Not available for 1.1 EJBs.
The local home interface, also referred to as an EJB factory or life-cycle interface, provides methods that local clients—those running in the same application as the EJB—can use to create, remove, and in the case of an entity bean, find instances of the bean.
The local home interface also has «home methods»—business logic that is not specific to a particular bean instance.
The remote home interface, also referred to as an EJB factory, or life-cycle interface, provides methods that remote clients—those running in a separate application from the EJB—can use to create, remove, and find instances of the bean.
The bean class implements business logic.