Today, you will

• Examine the different types of EJB available




• Take a look at how EJBs are applied




• Explore the structure of one of the EJBs that forms part of the case
  study to see how the different parts fit together




• Deploy and use some of the EJBs from the case study





• Write a simple client for an EJB

First, you need to understand why you would use EJBs.

What Is an EJB?

In a typical J2EE application, Enterprise JavaBeans (EJBs) contain the
application's business logic and live business data. Although it is
possible to use standard Java objects to contain your business logic and
business data, using EJBs addresses many of the issues you would find by using
simple Java objects, such as scalability, lifecycle management, and state
management.

Beans, Clients, Containers, and Servers

An EJB is essentially a managed component that is created, controlled, and
destroyed by the J2EE container in which it lives. This control allows the
container to control the number of EJBs currently in existence and the resources
they are using, such as memory and database connections. Each container will
maintain a pool of EJB instances that are ready to be assigned to a client. When
a client no longer needs an EJB, the EJB instance will be returned to the pool
and all of its resources will be released. At times of heavy load, even EJB
instances that are still in use by clients will be returned to the pool so they
can service other clients. When the original client makes another request of its
EJB, the container will reconstitute the original EJB instance to service the
request. This pooling and recycling of EJB instances means that a few EJB
instances, and the resources they use, can be shared between many clients. This
maximizes the scalability of the EJB-based application. The EJB lifecycle is
discussed further on Days 5 and 6.

The client that uses the EJB instance does not need to know about all of this
work by the container. As far as the client is concerned, it is talking to a
remote component that supports defined business methods. How those methods are
implemented and any magic performed by the container, such as just-in-time
instantiation of that specific component instance, are entirely transparent to
the client part of the application.

The EJB benefits from certain services provided by the container, such as
automatic security, automatic transactions, lifecycle management, and so on. To
do this, the EJB must conform to certain rules and implement an appropriate
interface that allows the container to manage the component. The EJB is packaged
with configuration information that indicates the component's requirements,
such as transaction and security requirements. The container will then use this
information to perform authentication and control transactions on behalf of the
component—the component does not have to contain code to perform such
tasks.

The primary purpose of the container is to control and provide services for
the EJBs it contains. When it needs to use some underlying functionality, such
as creating a transaction on behalf of a bean, it uses the facilities of the
underlying EJB server. The EJB server is the base set of services on top of
which the container runs. Different types of EJB will run in different
containers, but many different EJB containers can run on a single EJB server.
EJB servers are generally delivered as part of a J2EE-compliant application
server (examples include BEA WebLogic and IBM WebSphere). You will install and
run the application server, which will provide the underlying services required
of an EJB server and will host EJB containers.

The EJB Landscape

As you have seen, the J2EE Blueprints
(http://java.sun.com/blueprints/enterprise/index.html)
define a target architecture for a typical J2EE-based application. In this
architecture, EJBs live in the middle tier and are used by other application
components that live in the presentation tier. Although it is possible that both
of these logical tiers will reside on the same computer, it is most likely that
they will reside on different machines. This means that an EJB will usually have
to be made available to remote clients.

To offer services to remote clients, EJBs will export their services as RMI
remote interfaces. RMI allows you to define distributed interfaces in Java.
There are certain caveats on doing this, not only at the implementation level
(such as declaring that RemoteExceptions may be thrown when calling a
method on an EJB) but also at the design level. Designing remote interfaces is a
skill in itself, which will be explored as you progress through topics in this
book, such as EJBs and J2EE Patterns.

Because they must use an RMI-based interface to access the functionality of
the EJB, the clients of an EJB must have some programming functionality. This
means that they are typically either "thick" clients that provide a
GUI interface or Web-server components that deliver HTML interfaces to
"thin" clients. The different types of client are explored in more
detail shortly.

In the other direction, EJBs themselves will make use of data sources, such
as databases and mainframe systems, to perform the required business logic.
Access to such data and services can be through a JDBC database connection, a
J2EE Connector, another EJB, or a dedicated server or class of some form.