Hello dear friends. In this video, we will examine the EJB Container. So, let's begin. Enterprise beans are Java programming language server components, that contain business logic. EJB container is a server-side component, that comprises the business logic. The EJB container provides local and remote access to enterprise beans. In other words, we can say that it provides a runtime environment for EJB applications within the application server. A single EJB container can have one or more EJB modules. It acts as an intermediate action between business logic and enterprise application. The following figure depicts the structure of the EJB container.

The container is responsible for creating the enterprise bean, binding the enterprise bean to the naming servers, so other application components can access the enterprise bean, ensuring only authorized clients have access to the enterprise beans methods, saving the beans state to persistent storage, caching the state of the bean, and activating or passivating the bean when necessary. Java EE expects the developer to create an enterprise Java bean. A simple component and the EJB container to provide the infrastructure required for communications, transactions, and data access. It converts business logic into executable code. In addition, the EJB container provides life cycle management for the component to ensure that its creation, usage, and destruction are both efficient and in accord with the specification.

Let's examine the inheritance dependencies, methods, and interfaces that define the EJB container. When the EJP container started, it has at its highest level the EJBContainerImpl class as its controller. It's a subclass of the generic container IMPL class. EJBcontainerIMPL implements the EJB container service interface and has listeners for changes to the deployed application modules and other parts of the environment. However, if we look at the WAS component interface, we can see some key methods that explain how the components and therefore the container are controlled by the WAS runtime environment. The containerImpl class is a subclass of the componentImpl class. So, it can be treated like any other component by the load components calls of the outer container that initializes it. It is how the base server starts, controls, and interacts with the EJB container. As I said before, an EJB is a server-side component and needs to be executed in a container.

This runtime environment provides core features common to many enterprise applications, like remote client communication. Without writing any complex code, an EJB client can invoke methods remotely via standard protocols. Dependency injection. The container can inject several resources into an EJB like JMS destinations and factories, data sources, other EJBs, environment variables, etc. State management. For stateful session beans, the container manages their state transparently. You can maintain state for a particular client as if you were developing a desktop application. Pooling. For stateless beans and MDBs, the container creates a pool of instances that can be shared by multiple clients. Once invoked, an EJB returns to the pool to be reused instead of being destroyed. Component Lifecycle. The container is responsible for managing the lifecycle of each component. Messaging. The container allows MDBs to listen to destinations and consume messages without too much JMS plumbing. Transaction Management.

With declarative transaction management, an EJB can use annotations to inform the container about the transaction policy it should use. The container takes care of the commit or the rollback. Security. Class or method level access control can be specified on EJBs to enforce user and role authentication. Concurrency support. Except for singletons where some concurrency declaration is needed, all the other types of EJB are threat safe by nature. You can develop high performance applications without worrying about threat issues. Interceptors. Cross-cutting concerns can be put into interceptors which will be invoked automatically by the container.

Asynchronous method invocation. With EJB 3.1, it's now possible to have asynchronous calls without involving messaging. Once the EJB is deployed, the container takes care of these features, leaving the developer to focus on business logic while benefiting from these services without adding any system level code. So, that's all I have to say about the EJB container. In the following video, we will continue with EJB types and session beans. See you in the following video.