Enterprise JavaBeans (EJBs)

The primary goal of the Enterprise JavaBeans (EJB) component model is to define a standard and consistent way for server-side application components to be written and deployed on all application servers that support the EJB specification. In essence, EJB brings the same Write Once Run Anywhere concept of standard Java to server-side components.

An enterprise bean is a Java class residing on the server side and implements the business logic for multi-tier enterprise applications. The EJB specification aims to standardize the development of these server-side Java classes. As a result, the EJB specification has clearly demarcated the middle tier of the three-tier architecture from a compound business logic layer into two parts: a transactional business logic layer and a data logic layer. For each of these layers, the EJB specification defines standard component models to develop transactional business logic components and data logic components.

The EJB specification defines that transactional business logic can be built using session beans. There are two types of session EJBs: stateful session beans and stateless session beans.

For data logic, the EJB specification defines entity beans. Entity beans can be implemented in two ways based on the way they persist data in the database; if the EJB container is responsible for managing the persistence for the entity bean, the bean is said to have container-managed persistence. Alternatively, if the bean provider is responsible for implementing the entity bean's persistence, the entity bean is said to have bean-managed persistence.

The major new addition in the EJB 2.0 specification is the inclusion of a new bean type the message-driven bean. With message-driven beans, the EJB specification provides support for writing stateless beans that can act as Java Message Service (JMS) API clients and process messages from a message queue.

Design Contracts

In the EJB framework, the main participants are the container, EJB components providing business services, and client applications utilizing the application component services. Hence, the EJB framework specifies two kinds of design contracts for these participants.

Client-View Contract

The client-view contract is used for defining a consistent method of interaction between an EJB client application and an EJB container. In the EJB framework, the container performs the mediation between an EJB client and an EJB component. So, the client-view contract specifies the interfaces that are available for the EJB client to interact with an EJB container irrespective of the vendor supplying the container. As a part of this contract, interfaces are defined to obtain a reference to the factory within the container for creating EJB component instances (the home interface), obtaining references to the implementation of the business interface published by the EJB component (the remote interface), and acquiring some sundry metadata information about the EJB component.

The client-view contract ensures that the EJB client applications can communicate with any EJB container without any changes in the source code.

Component Contract

Because the EJB container provides the execution environment for EJB components, the component contract defines the standardized way for EJB components to interact with the container. The entire life cycle of an EJB component until it is removed from memory, such as component instantiation, component activation, and passivation, is managed by the container. Hence, defining a consistent environment for EJB components to execute in containers implemented by different vendors was the primary aim behind defining this contract. The contract defines interfaces that can enable an EJB component developer to develop either transactional (SessionBean) or persistent (EntityBean) EJB components.

The container-component contract ensures portability of EJB components across different vendor implementations of EJB containers.