The environment that surrounds the beans on the EJB server is often referred to as the container. The container is more a concept than a physical construct. Conceptually, the container acts as an intermediary between the bean and the EJB server. It manifests and manages the EJB objects and EJB homes for a particular type of bean and helps these constructs to manage bean resources and apply primary services such as transactions, security, concurrency, naming, and so forth at runtime. Conceptually, an EJB server may have many containers, each of which may contain one or more types of enterprise beans. As you will discover a little later, the container and the server are not clearly different constructs, but the EJB specification defines the component model in terms of the container’s responsibilities, so we will follow that convention here.
Enterprise bean components interact with
the EJB container through a well-defined component model. The
(EJB 2.0) interfaces are the bases of
this component model. As we learned earlier, these interfaces provide
callback methods that notify the bean class of life-cycle events. At
runtime, the container invokes the callback methods on the bean
instance when appropriate life-cycle events occur. When the container
is about to write an entity bean instance’s state to the
database, for example, it first calls the bean instance’s
method. This provides the bean instance ...