1. EJB is designed
; To encapsulate business logic
; To provide standard common system services to the developers so that
developers can concentrate on business logic coding. The key services
provided by EJB container are:
i. Life-cycle management
ii. Client session management
iii. Persistence management
v. Scalability (instance pooling)
vi. Transaction management
vii. Locking and concurrency control
ix. Thread safe (one instance per thread)
; To make the code reusable
It is a distributed computing and can be accessed by any type of the clients:
; Web client using JRMP or RMI-IIOP
; Standalone Java client using JRMP or RMI-IIOP
; EJB client using JRMP or RMI-IIOP
; CORBA client using RMI-IIOP
2. Some key differences between normal Java Bean and EJB Java Bean EJB
General purpose Highly specialized business-logic
Any tier Business logic tier
No system services provided Several key system services provided
Local service Distributed computing, remote service
3. EJB architecture
Register the home
when deploying JNDI lookup
Call Home’s create() method Client Home Return component reference to client Stub create() Bean Pool Network Component Interface
Once component interface receives the method call from skeleton, the container
will locate a free bean instance from the pool to provide the service. The sequence
of the service invocations is as follows:
; Examine the security credentials of the caller of that method
; Start or join with any required transactions
; Make any necessary calls to persistence functions
; Trigger various callbacks to allow EJB to acquire resources
; Make the actual business method call
; Do some more works with transactions, persistence, callbacks and so on
; Finally, the results of the business method or exception will be sent back to
client via RMI infrastructure
4. Bean Type
Session Bean: Stateful and Statless
Entity Bean: BMP vs CMP
Message Driven Bean (MDB), since EJB 2.0
Local vs Remote
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.
Figure 2 WebLogic Server Free Pool Showing Stateless Session EJB Life Cycle
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.
Figure 3 Stateful Session EJB Life Cycle
The differences between the stateful and stateless are:
; You must define instance variables to hold the state for Stateful
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
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.
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 lifecycle, 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. It is acceptable or beneficial for customer orders to "stack up" before the associated supplier orders are issued.
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.
Table 1 Components of an EJB
EJB Description Stateless Stateful Entity MDB Component Session Session Remote The remote interface exposes Yes Yes Yes No interface business logic to remote clients—
clients running in a separate
application from the EJB. It defines
the business methods a remote
client can call.
Local The local interface exposes business Yes Yes Yes No interface logic to local clients—those running
in the same application as the EJB.
It defines the business methods a
local client can call.
Local home The local home interface, also Yes Yes Yes No interface 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
Remote The remote home interface, also Yes Yes Yes No home referred to as an EJB factory, or life-
interface 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.
Bean class The bean class implements business Yes Yes Yes Yes
Primary key Only entity beans have a primary No No Yes No class key class. The primary key class
maps to one or more fields in a
database—identifying the persistent
data to which the entity bean