The environment that surrounds the beans on the EJB server is often called the container. The container is more a concept than a physical construct. It acts as an intermediary between the bean and the EJB server. It manages the EJB objects and EJB homes and helps these constructs to manage bean resources and provide services such as transactions, security, concurrency, and naming at runtime. The distinction between the container and the server is not clearly defined, 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
EntityBean
,
SessionBean
, and
MessageDrivenBean
interfaces provide callback methods
that notify the bean class of life-cycle events. At runtime, the
container invokes these methods on the bean instance when relevant
events occur. For example, when the container is about to write an
entity bean instance’s state to the database, it
first calls the bean instance’s ejbStore( )
method. This call gives the bean
instance an opportunity to do cleanup on its state before
it’s written to the database. The
ejbLoad( )
method is
called just after the bean’s fields are populated
from the database, providing the bean developer with an opportunity
to manage the bean’s state before the first business
method is called.[9] Other
callback methods can be used by the bean class in a similar fashion.
EJB defines when these various callback methods are invoked and what
can be done within their contexts.
While the bean interfaces require implementations of all the callback methods, those implementations don’t have to be meaningful. The method body of any or all of the callback methods can be left empty, and often is. Beans that implement callback methods usually access resources that aren’t managed by the EJB system. Enterprise beans that wrap legacy systems often fall into this category.
javax.ejb.EJBContext
is an interface implemented by the
container and is also part of the bean-container contract. Entity
beans use a subclass of javax.ejb.EJBContext
called
javax.ejb.EntityContext
.
Session beans use a subclass called
javax.ejb.SessionContext
.
Message-driven beans use the subclass
javax.ejb.MessageDrivenContext
. These EJBContext
types provide the bean with information about its environment: its
container, the client using the enterprise bean, and the bean itself.
The bean can use this information while processing requests from
clients and callback methods from the container.
An enterprise bean’s interface with the container
also includes a JNDI namespace, called the environment
naming context
, which the bean can use to look up the
resources it needs (including other beans). The JNDI environment
naming context and the EJBContext
(and its
subclasses) are described in more detail in Chapter 10, Chapter 11, and Chapter 12.
[9] The ejbLoad( )
and ejbStore( )
behavior illustrated here is for
container-managed persistence. With bean-managed persistence, the
behavior is slightly different. This distinction is examined in
detail in Chapter 10.