EJB Unit-I

Introduction
Enterprise JavaBeans (EJB) is server-side component model of the Java platform for
developing distributed enterprise applications.
It enables enterprises develop secure, scalable, multi-platform, business-critical applications
as server-side components
The EJB specification is part of Java EE specification which encapsulates the business logic
of an application.
Applications developed using EJB run on Java EE Application Servers which include an EJB
container by default or a standalone EJB container can be used. (More on this later).
The main point of EJB was to allow enterprise developers to concentrate on business logic
and free them from the need to write transaction, security, caching, pooling and threading
primitives by delegating that task to the server vendor.
When to use EJB?
If your application,
1.

Needs to encapsulate business logic

Business logic is separated from presentation and persistence tier

Needs Remote access

o
Applications running on different servers can access EJB.

Needs to be scalable
o
Almost all Java EE application servers support clustering, load balancing, and
failover

Needs Broad vendor support

o
JBoss, Oracle AS, WebLogic, WebSphere, Glassfish, etc are some of Java EE
Application Servers.

Needs to be portable
o
Applications developed using EJB can be written once and deployed on different
Java EE Application Servers

Needs deployment time configuration

o
Enables deployment-time configuration using XML-based deployment descriptor
or within the beans code using metadata deployment annotations.
Disadvantages of EJB:
1.
Complexity
o
EJB specification is too large and complicated. Even though EJB might be
simpler than other remote object systems, remote-object frameworks are much more
complex than local-object frameworks.
o
Spring is easier and more powerful for local access
o

M.S. Chahar

Page 1

EJB Unit-I

Requires Java EE server

Cant run on Web Containers such as Tomcat, Jetty, Resin, JRun, Resin
Java EE servers are usually hard to configure, significantly slower to start/restart
during development and testing, and usually cost money

Bad name due to earlier releases

o
EJB2 was so complex that EJB has bad reputation till this day

Needs Java Clients

o
EJBs are built on top of RMI. Both involve Java clients and beans. If your clients
need to be written in something else (e.g., .NET, PHP, etc.) then you have to go with web
services or something else that is a platform independent protocol, like HTTP, XML over
HTTP or SOAP.

o
o

Session Beans
What is a Session bean
A session bean is the enterprise bean that directly interact with the user and contains the business
logic of the enterprise application. A session bean represents a single client accessing the
enterprise application deployed on the server by invoking its method. An application may contain
multiple sessions depending upon the number of users accessing to the application. A session
bean makes an interactive session only for a single client and shields that client from
complexities just by executing the business task on server side.
For example, whenever a client wants to perform any of these actions such as making a
reservation or validating a credit card, a session bean should be used. The session bean decides
what data is to be modified. Typically, the session bean uses an entity bean to access or modify
data. They implement business logic, business rules, algorithms, and work flows. Session beans
are relatively short-lived components.
The EJB container may destroy a session bean if its client times out.
A session bean can neither be shared nor can persist (means its value cannot be saved to the
database its value. A session bean can have only one client. As long as the client terminates,
session bean associated with this client is also terminated and the data associated with this bean
is also destroyed.

M.S. Chahar

Page 2

EJB Unit-I

In this figure shows how Session Bean interacts with the clients as well as with the Entity
Beans.
Session beans are divided into two parts.
Stateless

Session Beans:
A stateless session bean does not maintain a conversational state with the client. When a client
invokes the methods of a stateless bean, the instance of bean variables may contain a state
specific to that client only for the duration of a method invocation. Once the method is finished,
the client-specific state should not be retained i.e. the EJB container destroys a stateless session
bean.
These types of session beans do not use the class variables (instance variables). So they do not
persist data across method invocation and therefore there is no need to passivates the bean's
instance. Because stateless session beans can support multiple clients, they provide the better
scalability for applications that require large numbers of clients.
Stateful

Session Beans:
These types of beans use the instance variables that allows the data persistent across
Method invocation because the instance variables allow persistence of data across method
invocation. The client sets the data to these variables which he wants to persist. A stateful session
bean retains its state across multiple method invocations made by the same client.
If the stateful session bean's state is changed during a method invocation, then that state will be
available to the same client on the following invocation. The state of a client bean is retained for
the duration of the client-bean session. Once the client removes the bean or terminates, the
session ends and the state disappears. Because the client interacts with its bean, this state is often
called the conversational state.

M.S. Chahar

Page 3

EJB Unit-I

Example:- consider a customer using a debit card at an ATM machine. The ATM
could perform various operations like checking an account balance, transferring funds, or making
a withdrawal. These operations could be performed one by one, by the same
customer. So the bean needs to keep track its state for each of these operations to the
same client. Thus Stateful session beans has the extra overhead for the server to maintain the
state than the stateless session bean.
The user interface calls methods of session beans if the user wants to use the functionality of the
session bean. Session beans can call to other session beans and entity beans.
When to use session beans:
Generally session beans are used in the following circumstances:
When there is only one client is accessing the beans instance at a given time.
When the bean is not persistent that means the bean is going to exist no longer.
The bean is implementing the web services.
Stateful session beans are useful in the following circumstances:
What the bean wants to holds information about the client across method
Invocation.
When the bean works as the mediator between the client and the other
Component of the application.
When the bean have to manage the work flow of several other enterprise
beans.
Stateless session beans are appropriate in the circumstances illustrated below:
If the bean does not contain the data for a specific client.
If there is only one method invocation among all the clients to perform the
generic task.
Life Cycle of a Stateless Session Bean:
Since the Stateless session bean does not passivates across method calls therefore a stateless
session bean includes only two stages. Whether it does not exist or ready for method invocation.
A stateless session bean starts its life cycle when the client first obtains the reference of the
session bean. For this, the container performs the dependency injection before invoking the
annotated @PreConstruct method if any exists. After invoking the annotated @PreConstruct
method the bean will be ready to invoke its method by the client.

In this figure demonstrates how the Stateless Session Beans are created and destroyed.
Life Cycle of a Stateful Session Bean:
A Stateful session bean starts its life cycle when the client first gets the reference of a stateful
session bean. Before invoking the method annotated @PostConstruct the container performs
M.S. Chahar

Page 4

EJB Unit-I

any dependency injection after this the bean is ready. The container may deactivate a bean while
in ready state (Generally the container uses the least recently use algorithm to passivates a bean).
In the passivate mechanism the bean moves from memory to secondary memory. The container
invokes the annotated @PrePassivate method before passivating the bean. If a client invokes a
business method on the passivated bean then the container invokes the annotated PostActivate
method to let come the bean in the ready state.

In this figure shows the various states of the Stateful Session Beans.
Message Driven Beans:
Message driven beans are the light weight components used for communication. In message
driven beans the messaging service is in asynchronous mode because the user is not intended to
get the instant result. To understand the concept of message driven beans more clearly first we
should go through the various concepts illustrated given below:
Techniques to implement messaging, message-oriented-middleware (MOM)
and the asynchronous behavior.
Utilization of JMS, message-oriented-middleware to implement JMS based
messagedriven-beans.
Features and comparison of message-driven-beans with entity and session
beans.
Techniques to develop message driven beans, including advanced topics like
gotchas and possible actions.
Motivations for messaging: EJB components are used to develop the applications for the
distributed computing network.
Distributed computing network uses the RMI-IIOP protocol to communicate with each other.
This protocol is used to call the EJB components. RMI-IIOP accepts challenges in several areas
like:

M.S. Chahar

Page 5

EJB Unit-I

Asynchrony:

A typical RMI-IIOP client has to wait until the server completes its processing
and returns the result to the client. After that the server enables to the client to continue its
processing.
Decoupling:

An RMI-IIOP server must have the knowledge about the server that it want to
use. The client can address them directly through object references. It is not possible to remove a
server from the server without directly impacting the clients because the client and server are
closely coupled with each other.
Reliability:

Data may be lost or the client can't perform any operation if the server or the
network crashes.
Support

for multiple senders and receivers: You can use messaging server instead of remote
method invocation (RMI) but the messaging service uses the middleman between the client and
the server. This middleman simply receives the messages from one or more senders and sends
these messages to one or more consumers. It is not required to get the response instantly from the
receiver. The receiver may sends back response back to the sender after completing all the
processing. This is known as asynchronous programming.
Java Message Services (JMS): JMS API is an enterprise tool developed by Sun Microsystems
used to develop the enterprise applications. JMS API supports to a framework that allows the
development of portable and message based applications. JMS communicates in synchronous or
in asynchronous mode by using point-to-point and the publish-subscribe models respectively.
JMS has become vendor specific and many vendors such as IBM, Oracle, Hewlett-Packard, BEA
Systems and Macromedia are providing the JMS implementation.
JMS API: JMS APIs play an important role as comparing the RMI-IIOP protocol. You need to
aware with different interfaces, low level topology issues like structure, messaging format,
networking protocol and server location.

M.S. Chahar

Page 6

EJB Unit-I

1. Locate the JMS provider's ConnectionFactory instance: First establish the

connection by using a ConnectionFactory instance to get access the JMS provider of the
MOM product you are using. An administrator typically creates and configures the
ConnectionFactory for the JMS client's use.
2. Create a JMS connection: A JMS connection manages the low level network
communications similar to JDBC connection. Use ConnectionFactory to get a
connection. For large deployment this connection may be load balance across a group of
machines.
3. Create a JMS session: A JMS session object is used to send and receive the messages
and works as the ConnectionFactory for message producers and message consumers. It
also allows the encapsulation of messages in transactions. We use Connection to get the
session object.
4. Locate the JMS Destination: A JMS destination is an object to which we are sending or
from which we are receiving the messages. Locating the right destination is similar to
tuning the channel in the right direction to get the clear picture while watching the
television or answering the correct phone to get the desired message.
5. Create a JMS producer or a JMS consumer: If you are interested to send a message
then you need an object to pass your message. This object is known as the JMS producer.
If you want to receive a message you need to call a JMS object. This object is known as
the Consumer object. To get hold an object Session and Destination are used.
6. Send or Receive a message: There may be different types of messages like text, streams,
maps, bytes, objects and so on. To send a messages first instantiate it and then send it by
using the Producer object. If you are intended to receive a message then first receive the
message with the help of Consumer object and then crack it to see what it contains.
All the points described above are applicable to both point-to-point as well as publish/subscribe.
Here we are going to discuss JMS by taking the queuing system. Queuing system includes the
following parts:
JMS

Server: The JMS server maintains the message queue to receive emails.
JMS

Queue: In case of point-to-point messaging system, a queue is used to hold the

messages from clients. Messages holding this queue are of MapMessages type that stores the
information about the email as name/value pair.
Email

Message Client: A client of this messaging system creates the JMS message to put it
on the JMS Queue. This message contains the information about the message to be sent out.
Email

Message Driven Bean: It is the message driven bean that is responsible to take the
JMS MapMessage to mail it out.
JMS Architecture: Talk first about JMS while talking about the message driven beans. There
are a lot of messaging systems exist in the market. Messaging systems provide a mechanism to
exchange data and events asynchronously. JMS API defines a standard way to access any
messaging system such as JDBC that enables the user to talk to SQL Server, Oracle and Sybase
simply by using the same API. The additional benefits of JMS API are loose coupling between
the generated request and the code that services the request.
M.S. Chahar

Page 7

EJB Unit-I

Here are some of the basics of the messaging server that one should know to more clearly
understand the concept of JMS APIs:
Messaging Domains
JMS Messages
Messaging Domains: A messaging system includes several models of operation. JMS API
provides separate domains corresponding to different models. JMS provider is free to implement
one or more domains. Point-to-Point and Publish/Subscribe are the two most commonly used
domains. These two domains concludes the following concepts.
Producer:

The client, responsible for sending the message to the destination is known as the
producer.
Consumer:

The client, responsible for receiving the message is known as the consumer.
Destination:

Destination is the object used by the client to specify the target that uses it to
send the message to or to receive the message from.
Point-to-Point (PTP): An application that uses the point-to-point technique for messaging has
the following characteristics.
A PTP producer is the sender.
A PTP consumer is the receiver.
PTP uses a queue as the destination.
A receiver can consume only a single message.
Integrating JMS with EJB: Integration of JMS with EJB is the excellent idea because of it the
EJB components gets benefit from the value proposed by messaging like multinary
communications and non blocking clients. The idea behind the introduction of new type of bean
is to consume messages in an EJB application.
Use a Java Object that receives the JMS messages to call an EJB client: Instead of
developing the whole new bean the java community proposed an idea of object to receive a
message and to call the appropriate EJB component such as the session bean or the entity bean.
But the problems that come with this approach are:
You have to implement the multithreading concept just to increase the message consumption
so that you can listen the messages in multiple threads. However developing the multithreaded
application is not a tuff task for the developer.
Register yourself as a listener by writing the special code for JMS messages.
Hard code the JMS destination name in your java object that access the destination
information required for extra effort to access the destination information from the dish
like property files.
JMS message listener receives services from the EJB container just like a plain java
object such as clustering, pooling, transaction, automatic life cycle management and
many more. You need to hard code this yourself that is a tuff task and error prone.
Your java object is wrapped by other EJB components therefore it requires some way to start
up. If the class is running inside the container then you are required to use a server specific
startup class for the activation of the java object when the EJB server starts. This is not portable
as the EJB container does not define an standard way to activate the given logic.
M.S. Chahar

Page 8

EJB Unit-I

Message driven bean: Message driven beans are the special type of components that can receive
the JMS as well as other type of messages. Message driven bean can also be used to receive the
messages other than JMS. When a message is reached at the destination then the EJB container
invokes the message driven bean. A message driven bean is decoupled with the client that sends
the message. A client is not allowed to access the message driven bean through a business
interface. The client can interact with the message driven bean only through the messaging
system. To interact with the message driven bean use the message provider specific API such as
JMS.

M.S. Chahar

Page 9