An introduction to enterprise beans

This chapter looks at the characteristics and purpose of enterprise beans. It describes the two basic types of enterprise beans and their life cycles, and it provides an example of how enterprise beans can be combined to create distributed, three-tiered applications.


Bean basics

An enterprise bean is a Java component that can be combined with other enterprise beans and other Java components to create a distributed, three-tiered application. There are two types of enterprise beans:

Entity beans

This section discusses the basics of entity beans.

Basic components of an entity bean
Every entity bean must have the following components, which are illustrated in Figure 3:

Figure 3. The components of an entity bean

The components of an entity bean

Data persistence
Entity beans encapsulate and manipulate persistent (or permanent) business data. For example, at a bank, entity beans can be used to model customer profiles, checking and savings accounts, car loans, mortgages, and customer transaction histories.

To ensure that this important data is not lost, the entity bean stores its data in a data source such as a database. When the data in an enterprise bean instance is changed, the data in the data source is synchronized with the bean data. Of course, this synchronization takes place within the context of the appropriate type of transaction, so that if a router goes down or a server fails, permanent changes are not lost. When you design an entity bean, you must decide whether you want the enterprise bean to handle this data synchronization or whether you want the container to handle it. An enterprise bean that handles its own data synchronization is said to implement bean-managed persistence (BMP), while an enterprise bean whose data synchronization is handled by the container is said to implement container-managed persistence (CMP).

Unless you have a good reason for implementing BMP, it is recommended that you design your entity beans to use CMP. The code for an enterprise bean with CMP is easier to write and does not depend on any particular data storage product, making it more portable between EJB servers. However, you must use entity beans with BMP if you want to use a data source that is not supported by the EJB server.

Session beans

This section discusses the basics of session beans.

Basic components of a session bean
Every session bean must have the following components, which are illustrated in Figure 4:

Unlike an entity bean, a session bean does not have a primary key class. A session bean does not require a primary key class because you do not need to search for specific instances of session beans.

Figure 4. The components of a session bean

The components of a session bean

Stateless versus stateful session beans
Session beans encapsulate data and methods associated with a user session, task, or ephemeral object. By definition, the data in a session bean instance is ephemeral; if it is lost, no real harm is done. For example, at a bank, session beans can represent a funds transfer, the creation of a customer profile or new account, and a withdrawal or deposit. If information about a fund transfer is already typed (but not yet committed), and a server fails, the balances of the bank accounts remains the same. Only the transfer data is lost, which can always be retyped.

The manner in which a session bean is designed determines whether its data is shorter lived or longer lived:


Creating an EJB module

The last step in the development of an enterprise bean is the creation of an EJB module. An EJB module consists of the following:

The EJB module can be created by using the tools within an integrated development environment (IDE) like IBM's VisualAge for Java Enterprise Edition or by using the tools contained in WebSphere. For more information, see Tools for developing and deploying enterprise beans.

The EJB module
The EJB module is used to assemble enterprise beans into a single deployable unit; this file uses the standard Java archive file format. The EJB module can contain individual enterprise beans or multiple enterprise beans. For more information, see Creating an EJB module and deployment descriptor.

The deployment descriptor
The EJB module contains one or more deployable enterprise beans and one deployment descriptor. The deployment descriptor contains attribute and environment settings for each bean in the module, and it defines how the container invokes functionality for all beans in the module. The deployment descriptor attributes can be set for the entire enterprise bean or for the individual methods in the bean. The container uses the definition of the bean-level attribute unless a method-level attribute is defined, in which case the latter is used. The deployment descriptor contains the following information about entity and session beans. These attributes can be set on the bean only; they cannot be set on a specific method of the bean.

The deployment descriptor contains the following application assembly information:

The following binding attribute is stored in the repository (it is not part of the deployment descriptor):


Deploying an EJB module

When you deploy an EJB module, the deployment tool creates or incorporates the following elements:

Figure 5 shows a simplified version of a deployed entity bean.

Figure 5. The major components of a deployed entity bean

The major components of a deployed entity bean

You can deploy an EJB module with a variety of different tools. For more information, see Tools for developing and deploying enterprise beans.


Developing EJB applications

To create EJB applications, create the enterprise beans and EJB clients that encapsulate your business data and functionality and then combine them appropriately. Figure 6 provides a conceptual illustration of how EJB applications are created by combining one or more session beans, one or more entity beans, or both. Although individual entity beans and session beans can be used directly in an EJB client, session beans are designed to be associated with clients and entity beans are designed to store persistent data, so most EJB applications contain session beans that, in turn, access entity beans.

Figure 6. Conceptual view of EJB applications

Conceptual view of EJB applications

This section provides an example of the ways in which enterprise beans can be combined to create EJB applications.

An example: enterprise beans for a bank
If you develop EJB applications for the banking industry, you can develop the following entity beans to encapsulate your business data and associated methods:

An EJB client can directly access entity beans or session beans; however, the EJB Specification suggests that EJB clients use session beans to in turn access entity beans, especially in more complex applications. Therefore, as an EJB developer for the banking industry, you can create the following session beans to represent client tasks:

This example is simplified by necessity. Nevertheless, by using this set of enterprise beans, you can create a variety of EJB applications for different types of users by combining the appropriate beans within that application. One or more EJB clients can then be built to access the application.

Using the banking beans to develop EJB banking applications

When using beans built to the Sun Microsystems JavaBeans(TM) Specification (as opposed to the EJB Specification), you combine predefined components such as buttons and text fields to create GUI applications. When using enterprise beans, you combine predefined components such as the banking beans to create three-tiered applications.

For example, you can use the banking enterprise beans to create the following EJB applications:

These examples represent only a subset of the possible EJB applications that can be created with the banking beans.


Life cycles of enterprise bean instances

After an enterprise bean is deployed into a container, clients can create and use instances of that bean as required. Within the container, instances of an enterprise bean go through a defined life cycle. The events in an enterprise bean's life cycle are derived from actions initiated by either the EJB client or the container in the EJB server. You must understand this life cycle because for some enterprise beans, you must write some of the code to handle the different events in the enterprise bean's life cycle.

The methods mentioned in this section are discussed in greater detail in Developing enterprise beans.

Session bean life cycle
This section describes the life cycle of a session bean instance. Differences between stateful and stateless session beans are noted.

Creation state
A session bean's life cycle begins when a client invokes a create method defined in the bean's home interface. In response to this method invocation, the container does the following:

  1. Creates a new memory object for the session bean instance.

  2. Invokes the session bean's setSessionContext method. (This method passes the session bean instance a reference to a session context interface that can be used by the instance to obtain container services and get information about the caller of a client-invoked method.)

  3. Invokes the session bean's ejbCreate method corresponding to the create method called by the EJB client.

Ready state
After a session bean instance is created, it moves to the ready state of its life cycle. In this state, EJB clients can invoke the bean's business methods defined in the remote interface. The actions of the container at this state are determined by whether a method is invoked transactionally or nontransactionally:

Pooled state
The container has a sophisticated algorithm for managing which enterprise bean instances are retained in memory. When a container determines that a stateful session bean instance is no longer required in memory, it invokes the bean instance's ejbPassivate method and moves the bean instance into a reserve pool. A stateful session bean instance cannot be passivated when it is associated with a transaction.

If a client invokes a method on a passivated instance of a stateful session bean, the container activates the instance by restoring the instance's state and then invoking the bean instance's ejbActivate method. When this method returns, the bean instance is again in the ready state.

Because every stateless session bean instance of a particular type is the same as every other instance of that type, stateless session bean instances are not passivated or activated. These instances exist in a ready state at all times until their removal.

Removal state
A session bean's life cycle ends when an EJB client or the container invokes a remove method defined in the bean's home interface and remote interface. In response to this method invocation, the container calls the bean instance's ejbRemove method.

If you attempt to remove a bean instance while it is associated with a transaction, the javax.ejb.RemoveException is thrown. After a bean instance is removed, any attempt to invoke a method on that instance causes the java.rmi.NoSuchObjectException to be thrown.

A container can implicitly call a remove method on an instance after the lifetime of the EJB object has expired. The lifetime of a session EJB object is set in the deployment descriptor with the timeout attribute.

For more information on the remove methods, see Removing a bean's EJB object.

Entity bean life cycle
This section describes the life cycle of entity bean instances. Differences between entity beans with CMP and BMP are noted.

Creation State
An entity bean instance's life cycle begins when the container creates that instance. After creating a new entity bean instance, the container invokes the instance's setEntityContext method. This method passes the bean instance a reference to an entity context interface that can be used by the instance to obtain container services and get information about the caller of a client-invoked method.

Pooled State
After an entity bean instance is created, it is placed in a pool of available instances of the specified entity bean class. While the instance is in this pool, it is not associated with a specific EJB object. Every instance of the same enterprise bean class in this pool is identical. While an instance is in this pooled state, the container can use it to invoke any of the bean's finder methods.

Ready State
When a client needs to work with a specific entity bean instance, the container picks an instance from the pool and associates it with the EJB object initialized by the client. An entity bean instance is moved from the pooled to the ready state if there are no available instances in the ready state.

There are two events that cause an entity bean instance to be moved from the pooled state to the ready state:

When an entity bean instance is in the ready state, the container can invoke the instance's ejbLoad and ejbStore methods to synchronize the data in the instance with the corresponding data in the data source. In addition, the client can invoke the bean instance's business methods when the instance is in this state. All interactions required to handle an entity bean instance's business methods in the appropriate transactional (or nontransactional) manner are handled by the container.

When a container determines that an entity bean instance in the ready state is no longer required, it moves the instance to the pooled state. This transition to the pooled state results from either of the following events:

Removal State
An entity bean instance's life cycle ends when the container invokes the unsetEntityContext method on an entity bean instance in the pooled state. Do not confuse the removal of an entity bean instance with the removal of the underlying entity whose data is stored in the data source. The former simply removes an uninitialized object; the latter removes data from the data source.

For more information on the remove methods, see Removing a bean's EJB object.