Enterprise beans are the J2EE components that implement Enterprise JavaBeans (EJB) technology.

Enterprise beans run in the EJB container, a runtime environment within the J2EE server. EJB container
provides system-level services such as transactions to its enterprise beans.

An enterprise bean is a server-side component that encapsulates the business logic of an

application.

1. EJB container provides system-level services to enterprise beans, the bean developer can
concentrate on solving business problems. System-level services such as transaction management
and security authorization.
2. Beans--and not the clients--contain the application's business logic, the client developer can focus
on the presentation of the client. Client developer does not have to code the routines that
implement business rules or access databases
3. Enterprise beans are portable components, the application assembler can build new applications
from existing beans.

Types of Enterprise Beans:-

Table 3-1 Summary of Enterprise Bean Types

Enterprise Bean
Purpose
Type
Session Performs a task for a client
Entity Represents a business entity object that exists in persistent storage
Acts as a listener for the Java Message Service API, processing messages
Message-Driven
asynchronously

Session Bean:-

A session bean represents a single client inside the J2EE server. To access an application that is deployed
on the server, the client invokes the session bean's methods. The session bean performs work for its client,
shielding the client from complexity by executing business tasks inside the server.

1. Stateful Session Beans - The state of an object consists of the values of its instance variables. In a
stateful session bean, the instance variables represent the state of a unique client-bean
session.

The state is retained for the duration of the client-bean session. If the client removes the bean or
terminates, the session ends and the state disappears.

 The bean's state represents the interaction between the bean and a specific client.
 The bean needs to hold information about the client across method invocations.
 The bean mediates between the client and the other components of the application,
presenting a simplified view to the client.
 Bean manages the work flow of several enterprise beans.
 2. Stateless Session Beans- A stateless session bean does not maintain a conversational state for a
particular client. When a client invokes the method of a stateless bean, the bean's instance
variables may contain a state, but only for the duration of the invocation. When the method is
finished, the state is no longer retained. Except during method invocation, all instances of a
stateless bean are equivalent, allowing the EJB container to assign an instance to any client.

Because stateless session beans can support multiple clients, they can offer better scalability for
applications that require large numbers of clients. Typically, an application requires fewer
stateless session beans than stateful session beans to support the same number of clients.

EJB container may write a stateful session bean to secondary storage. However, stateless session
beans are never written to secondary storage. Therefore, stateless beans may offer better
performance than stateful beans.

 The bean's state has no data for a specific client.

 In a single method invocation, the bean performs a generic task for all clients. For
example, you might use a stateless session bean to send an e-mail that confirms an online
order.
 The bean fetches from a database a set of read-only data that is often used by clients.
Such a bean, for example, could retrieve the table rows that represent the products that
are on sale this month.

Entity Bean:-

An entity bean represents a business object in a persistent storage mechanism.

E.g. customers, orders, and products.

Entity beans are persistent, allow shared access, have primary keys, and may participate in relationships
with other entity beans.

Persistence- Persistence means that the entity bean's state exists beyond the lifetime of the application or
the J2EE server process. Saved in a storage mechanism.

1. bean-managed persistence- Entity bean code that you write contains the calls that access the
database.
2. container-managed persistence- EJB container automatically generates the necessary database
access calls.

Shared Access- Entity beans may be shared by multiple clients. Because the clients might want to change
the same data, it's important that entity beans work within transactions. EJB container provides
transaction management. Transaction attributes specified in the bean's deployment descriptor.

Primary Key- Each entity bean has a unique object identifier. A customer entity bean, for example,
might be identified by a customer number. The unique identifier, or primary key, enables the client to
locate a particular entity bean.
Relationships- Like a table in a relational database, an entity bean may be related to other entity beans.
For example, in a college enrollment application, StudentEJB and CourseEJB would be related because
students enroll in classes.

Relationships implemented differently for entity beans with bean-managed persistence and those with
container-managed persistence.

Container-Managed Persistence-

In order to generate the data access calls, the container needs information that you provide in the entity
bean's abstract schema.

Abstract Schema- Defines the bean's persistent fields and relationships.

Name of an abstract schema is specified in the deployment descriptor. This name is referenced by queries
written in the Enterprise JavaBeans Query Language ("EJB QL").

Must define an EJB QL query for every finder method. EJB QL query determines the query that is
executed by the EJB container when the finder method is invoked.

Persistent Fields- The persistent fields of an entity bean are stored in the underlying data store.
Collectively, these fields constitute the state of the bean. At runtime, the EJB container automatically
synchronizes this state with the database. During deployment, the container typically maps the entity bean
to a database table and maps the persistent fields to the table's columns.
A CustomerEJB entity bean, for example, might have persistent fields such as firstName, lastName,
phone, and emailAddress. In container-managed persistence, these fields are virtual. You declare them in
the abstract schema, but you do not code them as instance variables in the entity bean class. Instead, the
persistent fields are identified in the code by access methods (getters and setters).

Relationship Fields- A relationship field is like a foreign key in a database table--it identifies a related
bean. Like a persistent field, a relationship field is virtual and is defined in the enterprise bean class with
access methods. But unlike a persistent field, a relationship field does not represent the bean's state.

The Contents of an Enterprise Bean

To develop an enterprise bean, you must provide the following files:

 Deployment descriptor: An XML file that specifies information about the bean such as its
persistence type and transaction attributes. The deploytool utility creates the deployment
descriptor when you step through the New Enterprise Bean wizard.
 Enterprise bean class: Implements the methods defined in the following interfaces.
 Interfaces: The remote and home interfaces are required for remote access. For local access,
the local and local home interfaces are required. See the section Defining Client Access with
Interfaces. (Please note that these interfaces are not used by message-driven beans.)
 Helper classes: Other classes needed by the enterprise bean class, such as exception and utility
classes.

You package the files in the preceding list into an EJB JAR file, the module that stores the
enterprise bean. An EJB JAR file is portable and may be used for different applications. To
assemble a J2EE application, you package one or more modules--such as EJB JAR files--into an
EAR file, the archive file that holds the application. When you deploy the EAR file that contains
the bean's EJB JAR file, you also deploy the enterprise bean onto the J2EE server.

Naming Conventions for Enterprise Beans

Because enterprise beans are composed of multiple parts, it's useful to follow a naming
convention for your applications. Table 3-2 summarizes the conventions for the example beans
of this tutorial.

Table 3-2 Naming Conventions for Enterprise Beans 

Item Syntax Example

Enterprise bean name (DD) <name>EJB AccountEJB

EJB JAR display name (DD) <name>JAR AccountJAR

Enterprise bean class <name>Bean AccountBean

Home interface <name>Home AccountHome

Remote interface <name> Account

Local home interface Local<name>Home LocalAccountHome

Local interface Local<name> LocalAccount

Abstract schema (DD) <name> Account

DD means that the item is an element in the bean's deployment descriptor.

The Life Cycles of Enterprise Beans

An enterprise bean goes through various stages during its lifetime, or life cycle. Each type of
enterprise bean--session, entity, or message-driven--has a different life cycle.

The descriptions that follow refer to methods that are explained along with the code examples in
the next two chapters. If you are new to enterprise beans, you should skip this section and try out
the code examples first.

The Life Cycle of a Stateful Session Bean

Figure 3-3 illustrates the stages that a session bean passes through during its lifetime. The client
initiates the life cycle by invoking the create method. The EJB container instantiates the bean
and then invokes the setSessionContext and ejbCreate methods in the session bean. The
bean is now ready to have its business methods invoked.
While in the ready stage, the EJB container may decide to deactivate, or passivate, the bean by
moving it from memory to secondary storage. (Typically, the EJB container uses a least-
recently-used algorithm to select a bean for passivation.) The EJB container invokes the bean's
ejbPassivate method immediately before passivating it. If a client invokes a business method
on the bean while it is in the passive stage, the EJB container activates the bean, moving it back
to the ready stage, and then calls the bean's ejbActivate method.

At the end of the life cycle, the client invokes the remove method and the EJB container calls the
bean's ejbRemove method. The bean's instance is ready for garbage collection.

Your code controls the invocation of only two life-cycle methods--the create and remove
methods in the client. All other methods in Figure 3-3 are invoked by the EJB container. The
ejbCreate method, for example, is inside the bean class, allowing you to perform certain
operations right after the bean is instantiated. For instance, you may wish to connect to a
database in the ejbCreate method. See Chapter 16 for more information.

The Life Cycle of a Stateless Session Bean

Because a stateless session bean is never passivated, its life cycle has just two stages: nonexistent
and ready for the invocation of business methods. Figure 3-4 illustrates the stages of a stateless
session bean.
Figure 3-4 Life Cycle of a Stateless Session Bean

The Life Cycle of an Entity Bean

Figure 3-5 shows the stages that an entity bean passes through during its lifetime. After the EJB
container creates the instance, it calls the setEntityContext method of the entity bean class.
The setEntityContext method passes the entity context to the bean.

After instantiation, the entity bean moves to a pool of available instances. While in the pooled
stage, the instance is not associated with any particular EJB object identity. All instances in the
pool are identical. The EJB container assigns an identity to an instance when moving it to the
ready stage.

There are two paths from the pooled stage to the ready stage. On the first path, the client invokes
the create method, causing the EJB container to call the ejbCreate and ejbPostCreate
methods. On the second path, the EJB container invokes the ejbActivate method. While in the
ready stage, an entity bean's business methods may be invoked.

There are also two paths from the ready stage to the pooled stage. First, a client may invoke the
remove method, which causes the EJB container to call the ejbRemove method. Second, the EJB
container may invoke the ejbPassivate method.
Figure 3-5 Life Cycle of an Entity Bean

At the end of the life cycle, the EJB container removes the instance from the pool and invokes
the unsetEntityContext method.

In the pooled state, an instance is not associated with any particular EJB object identity. With
bean-managed persistence, when the EJB container moves an instance from the pooled state to
the ready state, it does not automatically set the primary key. Therefore, the ejbCreate and
ejbActivate methods must assign a value to the primary key. If the primary key is incorrect, the
ejbLoad and ejbStore methods cannot synchronize the instance variables with the database. In
the section The SavingsAccountEJB Example, the ejbCreate method assigns the primary key
from one of the input parameters. The ejbActivate method sets the primary key (id) as
follows:

id = (String)context.getPrimaryKey();
In the pooled state, the values of the instance variables are not needed. You can make these
instance variables eligible for garbage collection by setting them to null in the ejbPasssivate
method.

The Life Cycle of a Message-Driven Bean

Figure 3-6 illustrates the stages in the life cycle of a message-driven bean.

The EJB container usually creates a pool of message-driven bean instances. For each instance,
the EJB container instantiates the bean and performs these tasks:

1. It calls the setMessageDrivenContext method to pass the context object to the instance.

2. It calls the instance's ejbCreate method.

Figure 3-6 Life Cycle of a Message-Driven Bean

Like a stateless session bean, a message-driven bean is never passivated, and it has only two
states: nonexistent and ready to receive messages.

At the end of the life cycle, the container calls the ejbRemove method. The bean's instance is
then ready for garbage collection.