Java EJB introduction

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 EJBbased
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.