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.
Types of EJB
In most texts on this subject you will see pictures of a 3-tier system containing boxes labeled “EJB.” It is actually more important to identify what application functionality that should go into an EJB.
At the start of application development, regardless of the precise development process used there is generally some analysis that delivers a model, or set of classes and packages, that represent single or grouped business concepts.
Two types of functionality are generally discovered during analysis—data manipulation and business process flow. The application model will usually contain data-based classes such as Customer or Product. These classes will be manipulated by other classes or roles that represent business processes, such as Purchaser or CustomerManager. There are different types of EJB that can be applied to these different requirements:
Session EJB— A Session EJB is useful for mapping business process flow (or equivalent application concepts). There are two sub-types of Session EJB—stateless and stateful—that are discussed in more detail on Day 5. Session EJBs commonly represent “pure” functionality and are created as needed.
Entity EJB— An Entity EJB maps a combination of data (or equivalent application concept) and associated functionality. Entity EJBs are usually based on an underlying data store and will be created on the data within that store.
Message-Driven EJB— A Message-driven EJB is very similar in concept to a Session EJB, but is only activated when an asynchronous message arrives.
As an application designer, you should choose the most appropriate type of EJB based on the task to be accomplished.
Common Uses of EJBs
So, given all of this, where would you commonly encounter EJBs and in what roles? Well, the following are some examples:
In a Web-centric application, the EJBs will provide the business logic that sits behind the Web-oriented components, such as servlets and JSPs. If a Web-oriented application requires a high level of scalability or maintainability, use of EJBs can help to deliver this.
Thick client applications, such as Swing applications, will use EJBs in a similar way to Web-centric applications. To share business logic in a natural way between different types of client applications, EJBs can be used to house that business logic.
Business-to-business (B2B) e-commerce applications can also take advantage of EJBs. Because B2B e-commerce frequently revolves around the integration of business processes, EJBs provide an ideal place to house the business process logic. They can also provide a link between the Web technologies often used to deliver B2B and the business systems behind.
Enterprise Application Integration (EAI) applications can incorporate EJBs to house processing and mapping between different applications. Again, this is an encapsulation of the business logic that is needed when transferring data between applications (in this case, in-house applications).
These are all high-level views on how EJBs are applied. There are various other EJB-specific patterns and idioms that can be applied when implementing EJB-based solutions. These are discussed more on Day 18, “Patterns.”