Java Reference
In-Depth Information
Enterprise JavaBeans
Packages
javax.ejb, javax.ejb.
spi
Use:
J2EE (J2EE1.2)
Description
In a sense, Enterprise JavaBeans are the heart and soul of the J2EE architecture. They represent the core business
model, defined in terms of a collaborating set of components. EJBs are used to enforce business rules, to
encapsulate business logic, and to encompass the business model within an enterprise application.
There are three fundamental categories of EJBs:
Session Beans -
EJBs that directly support business logic. Session Beans can be either
Stateful
or
Stateless.
A
Stateful Session Bean is associated with a specific client session, while a Stateless Session Bean represents a
generic business resource, not dependent on any specific client caller.
Entity Beans -
Designed to be directly associated with a DBMS or other persistent data store, providing an
“objectized” form for the data
Message-driven Beans -
Designed to be asynchronous receivers of message notifications from JMS technology.
These beans can receive and react to messages using the JMS API as a J2EE application runs.
To create an EJB, you need to write three Java code elements:
A Home interface, used to manage the EJBs lifecycle (contains create, locate and remove methods)
A Remote interface, used to define business methods
The Enterprise Bean implementation
In addition, you write an XML document called a deployment descriptor that specifies details about how the
Enterprise Bean should be managed: it contains configuration, administration, and resource management
information.
EJBs, even more than the other J2EE component technologies, depend strongly on their containers. In a very real
way, EJBs need their underlying container to create them, call them—really, to regulate every aspect of their life.
It's interesting to observe that the entire EJB architecture is interface-based. The only real classes that are defined
for the model are the exceptions. This illustrates even more dramatically the dependence of an EJB on its
container, since part of the task of the container is to generate the support code that implements the Home and
Remote interfaces and ties both of them to the underlying Enterprise Bean.
Deploying an Enterprise Bean involves producing the classes which implement the Home and Remote interfaces.
It involves providing code to map between method calls on the interfaces and actual method invocations on the
underlying Bean. In some cases, it involves producing additional management code based on information
supplied in the deployment descriptor.
It's often a big adjustment to former middleware programmers to “let go” and accept that the container takes care
of the additional services required by the EJBs. It can be difficult to get used to the concept of large amounts of
support code being automatically produced.
General Pattern Use
Enterprise JavaBeans have a number of patterns, but many of them are supplied by the container, implemented by
the underlying framework as part of the task of producing a functional, integrated EJB.
HOPP
(see page 189): Clients never interact with an Enterprise Bean directly. They always pass method calls to
either the Home or Remote interface, which then trigger calls to an EJB. You could say that clients don't even talk
