Bean implementation classes expose business logic to clients. They reside within a container such as IBM’s WebSphere Application Server, version 5.0. The container intercepts the client’s request and delegates it to the appropriate EJB for fulfillment. It is assumed that different types of EJBs contain APIs based on the bean’s type, and will therefore behave differently depending on which type of bean is selected.
The EJB container component exists within the J2EE application server’s infrastructure. The container provides the Java Runtime Environment (JRE) runtime for all EJB components. The container vendor must implement the services in the J2EE specification, version 1.3.1, which describes the interfaces and their services but never prescribes their implementation. Therein lies the key to J2EE’s flexibility and scalability. It represents a contract between the container and the designated EJB.
The following is an overview of an Enterprise JavaBean’s life cycle:
Create an EJB.
Construct a new enterprise application.
Generate an enterprise archive (EAR) file.
Bundle both the entity and session beans into a Java archive (JAR) file.
Add the JAR file to the new J2EE application.
Assemble the web components into a WAR file.
Specify the Java Naming and Directory Interface (JNDI) name and root context.
Test and verify the application.
Deploy the application to an operational environment.
Execute the J2EE application.
The EJB container provides support for low-level tasks such as activating or deactivating objects. In addition, the container manages process, memory allocation, and multithreading.
The container is also responsible for managing the state of an EJB instance. This is desirable because developers can focus on writing business logic, rather than concerning themselves with writing low-level system code.
The container reads the deployment descriptor file to obtain metadata about the J2EE application in order to provide the appropriate bean’s life cycle management. Responsibilities include enforcing security and controlling the bean instance’s behavior.
The container manages user authentication and authorization. This functionality is based on security information contained within the deployment descriptor.
EJBs provide support for both local and distributed transactions. This is achieved via the Java Transaction API and transaction services. For example, local transactions include interaction with a single relational database such as Oracle9i, Sybase, or IBM’s DB2 Enterprise Edition. Conversely, distributed transactions involve interaction with several remotely located relational databases spanning more than one server and multiple operating systems.
Developers have the option of implementing EJB transactions programmatically or setting the appropriate fields declaratively in the deployment descriptor file.
Traditionally, when developers must consider persisting data to a resource, they choose an entity bean for this task. They can then choose between a container-managed persistent (CMP) bean or a bean-managed persistent (BMP) bean.
The CMP is the more desirable of the two types because developers are not responsible for managing persisted transactions; they can depend on container-provided services. The BMP bean requires considerably more attention to facilitating data persistence, managing bean interaction with the repository, and writing low-level code.