JavaBeans is a specification for creating server-side
scalable, transactional, multi-user secure enterprise-level
applications. It provides a consistent component
architecture framework for creating distributed n-tier
middleware. It would be fair to call a bean written
to EJB spec a Server Bean.
A typical EJB
Architecture consists of
an EJB server,
containers that runs on these servers,
EJBs that run
in these containers,
other auxiliary systems like
and Directory Interface (JNDI ) and
Transaction Service (JTS).
In a typical
development and deployment scenario, there will
be an EJB server provider who creates and sells an
EJB server along with EJB containers that will run on
these servers. Then there will be the EJB providers-people
responsible for developing the EJBs and the
Application assemblers-people that use pre-built EJBs
to build their applications.
EJB Servers :
These are analogous to the CORBA ORB. This provides
the system services like a raw execution environment,
multiprocessing, load-balancing, device access, provides
naming and transaction services and makes containers
EJB Containers :
These act as the interface between an Enterprise Java
Bean and the outside world. An EJB client never
accesses a bean directly. Any bean access is done
through container-generated methods which in turn
invoke the bean's methods. The two types
of containers are session containers that may contain
transient, non-persistent EJBs whose states are not
saved at all and entity containers that contain
persistent EJBs whose states are saved between
EJB Clients :
These make use of the EJB Beans for their operations.
They find the EJB container that contains the bean
through the Java Naming and Directory (JNDI)
interface. They then make use of the EJB Container to
invoke EJB Bean methods.
There are two types of EJBs. They are
Each Session Bean is usually associated with one EJB
Client. Each Session Bean is created and destroyed by
the particular EJB Client that it is associated with.
A Session Bean can either have states or they can be
stateless. However, Session Beans do not survive a
Entity Beans always have states. Each Entity Bean may
however be shared by multiple EJB Clients. Their
states can be persisted and stored across multiple
invocations. Hence they can survive System Shutdowns.
servers have a right to manage their working set. Passivation is the process by which the
state of a Bean is saved to persistent storage and
then is swapped out. Activation is the process by which the
state of a Bean is restored by swapping it in from
persistent storage. Passivation and Activation apply
to both Session and Entity Beans.
are two types of Session Beans. They are
Session Beans and
Stateless Session Beans:
These types of EJBs have no internal state. Since
they do not have any states, they need not be
passivated. Because of the fact that they are
stateless, they can be pooled in to service multiple
clients (remember MTS components?)
Stateful Session Beans:
These types of EJBs possess internal states. Hence
they need to handle Activation and Passivation.
However, there can be only one Stateful Session Bean
per EJB Client. Since they can be persisted, they are
also called Persistent Session Beans. These types of EJBs can be
saved and restored across client sessions. To save, a
call to the bean's getHandle() method returns a handle object. To
restore, call the handle object's getEJBObject() method.
in Entity Beans is of two types. They are:
Here, the EJB container is responsible for saving the
Bean's state. Since it is container-managed, the
implementation is independent of the data source. The
container-managed fields need to be specified in the
Deployment Descriptor and the persistence is
automatically handled by the container.
Here, the Entity Bean is directly responsible for
saving its own state. The container does not need to
generate any database calls. Hence the implementation
is less adaptable than the previous one as the
persistence needs to be hard-coded into the bean.
deployed as serialized instances (*.ser files). The
manifest file is used to list the EJBs. In addition
to this, a Deployment Descriptor has to be supplied along with
each .ser file. It contains a serialized instance of
an EntityDescriptor or a SessionDescriptor.
typical EJB manifest entry looks like this:
The Name line describes a serialized
Deployment Descriptor. The Enterprise-Bean line indicates whether or not
the entry be treated as an EJB.
Deployment Descriptors are serialized instances of a
class. They are used to pass information about an
EJBs preferences and deployment needs to its
container. The EJB developer is responsible for
creating a deployment descriptor along with his/her
Other Auxiliary systems that are available to EJB systems
are the Java Naming and Directory Interface (JNDI) which allows EJB Clients to
find EJB beans and the Java Transaction Service (JTS) that provides transaction
support in an EJB environment.