EJB Containers

• act as the interface between an Enterprise Java Bean and low-level, platform-specific functionality that supports the Bean - the EJB Server
• EJB client never accesses a bean directly. Any bean access is done through container-generated class which in turn invokes the bean's methods
• by intercepting invocations of bean's methods, the container may provide system-level services to beans (transaction, security, control of concurrent access ...)
• the transaction, persistance and security management is based on the declarative approach (i.e. the actual behavior with respect to those services is specified in the deployment descriptor and thus is not hard-coded in the bean's class code)
• container manages a lifecycle of beans to utilize server resources (memory, threads) effectively. It may passivate the instance of a bean (i.e. flush it's state to a database and deactivate it) and activate it (i.e. create a new instance and restore it's original state from the database) when the client invokes the bean's method later.
• container makes the required services (e.g. transaction service) available to beans through standard interfaces defined in the EJB specification

The container tightly interacts with classes generated by the deployment tool for the deployed EJB Bean to manage enterprise Bean's persistence, transactional properties and security.

Note: The EJB Server may host one or more EJB Containers, possibly each of them configured differently.