Enterprise 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,
EJB containers that runs on these servers,
EJBs that run in these containers,
EJB clients and
other auxiliary systems like
the Java Naming and Directory Interface (JNDI ) and the Java 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 visible.

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

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.

Enterprise Java Beans:
There are two types of EJBs. They are
Session Beans and
Entity Beans

Session Beans:
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 System shutdown.

Entity Beans:
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.

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

There are two types of Session Beans. They are
Stateless Session Beans and
Stateful Session Beans

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.

Persistence in Entity Beans is of two types. They are:
Container-managed persistence
Bean-managed persistence

Container-managed persistence:
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.

Bean-managed persistence:
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.

EJBs are 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.

A typical EJB manifest entry looks like this:

Name: ~gopalan/BankAccountDeployment.ser
Enterprise-Bean: True

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

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.

 

More to come soon...