what is entity bean and its ejb types

 what is entity bean and its ejb types

EJBs are distinguished along three main functional roles. Within each primary role, the
EJBs are further distinguished according to subroles. By partitioning EJBs into roles, the

programmer can develop an EJB according to a more focused programming model than,
if, for instances such roles were not distinguished earlier. These roles also allow the EJB
container to determine the best management of a particular EJB based on its programming
model type.

There are three main types of beans: 

• Session Bean 

• Entity Beans 

• Message-driven Beans

Session Bean

 A session EJB is a non persistent object. Its lifetime is the duration of a particular
interaction between the client and the EJB. The client normally creates an EJB, calls
methods on it, and then removes it. If, the client fails to remove it, the EJB container will
remove it after a certain period of inactivity. There are two types of session beans:

• Stateless Session Beans: A stateless session EJB is shared between a number of
clients. It does not maintain conversational state. After each method call, the container
may choose to destroy a stateless session bean, or recreate it, clearing itself out, of all
the information pertaining the invocation of the last method. The algorithm for
creating new instance or instance reuse is container specific.

• Stateful Session Beans: A stateful session bean is a bean that is designed to service
business processes that span multiple method requests or transaction. To do this, the
stateful bean retains the state for an individual client. If, the stateful bean’s state is
changed during method invocation, then, that same state will be available to the same
client upon invocation.

1.7.1.1 Life Cycle of a Stateless Session Bean

The Figure 1 shows the life cycle of a Stateless Session Bean

 

 • Does not exist: In this state, the bean instance simply does not exist.

• Ready state: When EJB Server is first started, several bean instances are created and
placed in the Ready pool. More instances might be created by the container as and
when needed by the EJB container

 1.7.1.2 Life Cycle of a Stateful Session Bean

The Figure 2 shows the life cycle of a Stateful Session Bean

 • Does not exist: In this state, the bean instance simply does not exist.

• Ready state: A bean instance in the ready state is tied to a particular client and
engaged in a conversation.

 • Passive state: A bean instance in the passive state is passivated to conserve resources.

1.7.1.3 Required Methods in Session Bean

 The following are the required methods in a Session Bean:

setSessionContext(SessionContext ctx) :
Associate your bean with a session context. Your bean can make a query to the
context about its current transactional state, and its current security state

 ejbCreate( …) :

 Initialise your session bean. You would need to define several ejbCreate (…) methods and
then, each method can take up different arguments. There should be at least one
ejbCreate() in a session bean.

ejbPassivate():

 This method is called for, just before the session bean is passivated and releases any
resource that bean might be holding.

ejbActivate():

This method is called just for, before the session bean is activated and acquires the
resources that it requires.

ejbRemove():

This method is called for, by the ejb container just before the session bean is removed
from the memory.

 The use of a Session Bean

  

 In general, one should use a session bean if the following circumstances hold

 • At any given time, only one client has access to the bean instance.
• The state of the bean is not persistent, existing only for a short period and therefore.
• The bean implements a web service.

Stateful session beans are appropriate if, any of the following conditions are true:

• 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.

• Behind the scenes, the bean manages the work flow of several enterprise beans.

To improve performance, one might choose a stateless session bean if, it has any of these
traits:

• 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 a promotional email to
several registered users

 Entity Bean

 Entity EJBs represent persistent objects. Their lifetimes is not related to the duration of
interaction with clients. In nearly all cases, entity EJBs are synchronised with relational
databases. This is how persistence is achieved. Entity EJBs are always shared amongst
clients. A client cannot get an entity EJB to itself. Thus, entity EJBs are nearly always
used as a scheme for mapping relational databases into object-oriented applications.
An important feature of entity EJBs is that they have identity—that is, one can be
distinguished from another. This is implemented by assigning a primary key to each
instance of the EJB, where ‘primary key’ has the same meaning as it does for database
management. Primary keys that identify EJBs can be of any type, including programmerdefined
classes.

There are two type of persistence that entity EJB supports. These persistence types are:

• Bean-managed persistence (BMP): The entity bean’s implementation manages
persistence by coding database access and updating statements in callback methods.

• Container-managed persistence (CMP): The container uses specifications made in
the deployment descriptor to perform database access and update statements
automatically.

 

 An entity bean has the following three states:
 
• Does not exist: In this state, the bean instance simply does not exist.
• Pooled state: When the EJB server is first started, several bean instances are created
and placed in the pool. A bean instance in the pooled state is not tied to a particular
data, that is, it does not correspond to a record in a database table. Additional bean
instances can be added to the pool as needed, and a maximum number of instances
can be set.
• Ready state: A bean instance in the ready state is tied to a particular data, that is, it
represents an instance of an actual business object.

1.7.2.2 Required Methods in Entity Bean

 Entity beans can be bean managed or container managed. Here, are the methods that are
required for entity beans:

setEntityContext():

This method is called for, if a container wants to increase its pool size of bean instances,
then, it will instantiate a new entity bean instance. This method associates a bean with
context information. Once this method is called for, then, the bean can access the
information about its environment


 ejbFind(..):

This method is also known as the Finder method. The Finder method locates one or more
existing entity bean data instances in underlying persistent store.

ejbHome(..):

The Home methods are special business methods because they are called from a bean in
the pool before the bean is associated with any specific data. The client calls for, home
methods from home interface or local home interface.

ejbCreate():

This method is responsible for creating a new database data and for initialising the bean.

ejbPostCreate():

There must be one ejbPostCreate() for each ejbCreate(). Each method must accept the
same parameters. The container calls for, ejbPostCreate() right after ejbCreate().

 ejbActivate():

When a client calls for, a business method on a EJB object but no entity bean instance is
bound to EJB object, the container needs to take a bean from the pool and transition into a
ready state. This is called Activation. Upon activation the ejbActivate() method is called
for by the ejb container.

ejbLoad():

This method is called for, to load the database in the bean instance.

ejbStore():

This method is used for, to update the database with new values from the memory. This
method is also called for during ejbPassivate().

ejbPassivate():

This method is called for, by the EJB container when an entity bean is moved from the
ready state to the pool state.

ejbRemove():

This method is used to destroy the database data. It does not remove the object. The object
is moved to the pool state for reuse.

unsetEntityContext():

This method removes the bean from its environment. This is called for, just before
destroying the entity bean.

1.7.2.3 The Use of the Entity Bean

You could probably use an entity bean under the following conditions:

• The bean represents a business entity and not a procedure. For example,
BookInfoBean would be an entity bean, but BookInfoVerifierBean would be a session
bean.
• The bean’s state must be persistent. If the bean instance terminates or if the
Application Server is shut down, the bean's state still exists in persistent storage (a
database).

 1.7.3 Message Driven Bean

A message-driven bean acts as a consumer of asynchronous messages. It cannot be called
for, directly by clients, but is activated by the container when a message arrives. Clients
interact with these EJBs by sending messages to the queues or topics to which they are
listening. Although a message-driven EJB cannot be called for, directly by clients, it can
call other EJBs itself.

1.7.3.1 Life Cycle of a Message Driven Bean
The Figure 4 shows the life cycle of a Message Driven Bean

 

 A message driven bean has the following two states:

 • Does not exist: In this state, the bean instance simply does not exist. Initially, the
bean exists in the; does not exist state.

• Pooled state: After invoking the ejbCreate() method, the MDB instance is in the
ready pool, waiting to consume incoming messages. Since, MDBs are stateless, all
instances of MDBs in the pool are identical; they're allocated to process a message
and then return to the pool.

1.7.3.2 Method for Message Driven Bean
onMessage(Message):

This method is invoked for each message that is consumed by the bean. The container is
responsible for serialising messages to a single message driven bean.

ejbCreate():
When this method is invoked, the MDB is first created and then, added to the ‘to pool’.

ejbCreate():

When this method is invoked, the MDB is removed from the ‘to pool’.

setMessageDrivenContext(MessageDrivenContext):

This method is called for, as a part of the event transition that message driven bean goes
through, when it is being added to the pool. This is called for, just before the ejbCreate().

 1.7.3.3 The Use of the Message Driven Bean

Session beans allow you to send JMS messages and to receive them synchronously, but
not asynchronously. To avoid tying up server resources, you may prefer not blocking
synchronous receives in a server-side component. To receive messages asynchronously,
use a message-driven bean.