Enterprise JavaBeans: A Primer

Enterprise developers approaching J2EE often have trouble grasping the character and practices of Enterprise JavaBeans (EJBs). Terms like home interfaces, message-driven, instance-management, and container-managed persistence are often cast about rather cavalierly with the assumption that we all understand how these terms apply to us.

In this article, I'll begin to clarify these terms and identify some of the problems faced by enterprise application developers, and how EJBs help to solve these problems.

What is EJB Technology?

EJB technology defines a Java-based, server-side, reusable component framework for distributed applications that facilitates centrally-managed business logic, and declarative deployment. Sounds quite important and technical, doesn't it? Doesn't help much, does it? Let's see if I can put it another way:

• EJBs are written in Java
• EJBs are usually executed within an application server environment
• EJBs can be reused
• EJBs can be distributed across many machines and accessed almost as if they were on your local machine
• EJBs are centrally-managed by a container

The EJB specification and architecture are attempts to make remote, distributed, multi-tier development much easier. It has hoped to do this by introducing a concept known as an Enterprise Java Bean (EJB). The first thing to notice is that EJB, the component, is named the same as EJB, the specification. This is similar to the JavaBeans and Java Bean conundrum. The easiest way to get a grip around this puzzle is to put Java and Beans together when referring to the specifications and separate them when referring to the components. Thus, the remote specification becomes Enterprise JavaBeans and the remote component becomes an Enterprise Java Bean. The local specification becomes JavaBeans and the local component becomes a Java Bean.

The specification names and component names are very similar, but this is where the similarities end. The JavaBeans specification and component model and the Enterprise JavaBeans and component model have very little in common. To illustrate this, let's take a look at the concept of EJB, the component, and the environment in which it lives and executes.

EJB Runtime Environment

An Enterprise JavaBean is a Java object exposing a number of interfaces and which lives and executes inside of a runtime environment known as an EJB container. An Enterprise JavaBean cannot live outside an EJB container. In fact, the relationship between and EJB container and an EJB is sometimes called Inversion of Control (IoC) or the “Hollywood Principle" (don't call us, we'll call you).

An EJB container is a runtime environment for managing enterprise beans. The container hosts and manages an enterprise bean in much the same manner that a Java servlet engine hosts a Java servlet. The EJB container instantiates and controls the enterprise beans and provides them with system-level services.

A client application wishing to interact with an enterprise bean does not have direct access to an enterprise bean. Rather, the bean is isolated from the client application by the container.
Services provided by an EJB container
A programmer of the classes and interfaces from which an enterprise bean object will be created can assume that the following system-level services will be available from the EJB container:

• Transaction management for the bean
• Security for the bean
• Persistence of the bean
• Remote access to the bean
• Lifecycle management of the bean
• Database-connection pooling
• Instance pooling for the bean

Since the EJB container handles the entire scope of infrastructure service-level services for an enterprise bean, a programmer can concentrate on programming the business-logic for the enterprise bean.

Types of Enterprise Beans

The EJB architecture defines three distinct types of enterprise beans; session beans, entity beans and message-driven beans. Session beans and entity beans are invoked synchronously by an enterprise bean client. Message-driven beans (MDBs) are invoked by a message container, such as a publish/subscribe topic.