J2EE provides different types of components for different purposes. Today, you will start to look at one of the principal types of component in J2EE—Enterprise JavaBeans (EJBs).

The study of EJBs is continued on Day 5, "Session EJBs," Day 6, "Entity EJBs," Day 7, "Container-Managed Persistence and EJB Query Language," Day 8, "Transactions and Persistence," and Day 10, "Message-Driven Beans." As you can see, there is a lot to learn about EJBs, so today serves as a first step on the road to all of this EJB knowledge. Today, you will:

• Examine the different types of EJB available

• See 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 what EJBs are and why you would use them.

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 of using simple Java objects, such as scalability, lifecycle management, and state management.

Beans, Clients, Containers, and Servers

An EJB is essentially a managed middleware component that is created, controlled, and destroyed by the J2EE container in which it lives. This control allows the container to manage 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 reusable 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. 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 the work done on its behalf 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.

To benefit from certain services provided by the container, such as automatic security, automatic transactions, lifecycle management, and so on, an EJB is packaged with a deployment descriptor (DD) that indicates the component's requirements for services, such as transaction management and security authorization. The container will then use this information to perform authentication and transaction demarcation on behalf of the component—the component does not contain code to perform these tasks.

This chapter is from Teach Yourself J2EE in 21 Days, second edition, by Martin Bond et. al. (Sams, 2004, ISBN: 0-672-32558-6). Check it out at your favorite bookstore today. Buy this book now.