February 28, 2021
Hot Topics:

The Enterprise JavaBeans architecture

  • By Piroz Mohseni
  • Send Email »
  • More Articles »

Home interface

A client is a piece of the system that uses the Enterprise Bean. This could be a remote application or a tool that is used by the system administrator to manage the Beans. A mechanism is needed for a client to uniquely identify the Bean, to request creation of a Bean, and invoke the Bean's methods. The Home interface provides this functionality. The Home interface is actually defined by the Bean developer. It is implemented by the container. Typically, a tool is used to create a container class based on an enterprise JavaBean. One of the outputs of that tool is the implementation of a home interface. The home interface must extend

Additionally, the home interface must also include a method signature for creating the EJB instance. Note that the home interface must only provide the method signature. The actual implementation is done inside the Bean. So, for each

signature, the Bean implements an
. Argument counts and types determine the relationship between the method signature and the implementations.

The home interface is the key piece that allows a client to find, create, and remove an EJB. It is one of the interfaces that the container provides to the Bean. The other is a remote interface bundled inside an EJBObject.

Remote interface

The remote interface is based on the business logic inside the Bean. It is also generally generated by a tool provided by the container vendor. The remote interface is actually implemented by the EJBObject (also generated by a tool). While the home interface provides services for creating and destroying an EJB, the remote interface strictly deals with the business logic and methods provided by the Bean. This separation allows the EJB specification to separate business logic from EJB-specific functions. Each EJB must have a remote interface. The remote interface must extend javax.ejb.EJBObject.


The remote interface must provide the signatures for all the business methods supported by the Bean. The EJBObject implements these interfaces, and its implementation is merely a delegation to the actual Bean. This means that all client calls are handled by the EJBObject, not by the EJB itself. This provides another level of isolation for the Bean. The EJBObject intercepts all the calls before sending them to the Bean. Since the EJBObject is created by the tools provided by the container vendor, the container can make sure that "destructive" client requests are never passed to the Bean. It can also coordinate all calls to the Bean to insure transaction integrity and concurrency.

Deployment descriptor

The deployment descriptor is another component of the EJB architecture that is typically generated by a tool. It is a serialized class instance that is shipped with every EJB. The deployment descriptor describes characteristics of the Bean to the container. Examples include the length of time before the session times out, transaction attributes for the Bean, and environment properties. This provides the information the container needs to host the Bean.

EJB jar file

The ejb-jar file is used to package EJB components and all EJB tools must support this format. The format is similar to JAR files used to package JavaBeans, and the concept is similar as well. A JAR file manifest describes the content of an ejb-jar file. All the Java classes that make up the Bean are also included in the ejb-jar file. Another important piece are the instructions for deployment of an enterprise Bean enclosed in the serialized deployment descriptor. The home interface and the remote interface are also included.

Putting it together

Given the above pieces, a typical interaction of a client with a session Bean would be as follows. The client uses JNDI (Java Naming and Directory Interface) to look up a particular Bean. Once found, the
method is used to create the EJBObject and the Bean itself. This part of the operation happens via the home interface. The client now has a handle to the EJBObject and can now invoke Bean-specific methods that are in turn delegated to the Bean itself. The Bean-specific methods are handled by the remote interface and the EJBObject. Once the client decides the Bean is no longer necessary, it will destroy it (again using the home interface).

Entity Beans

Unlike session Beans, entity Beans are optional in EJB 1.0. They will likely be required in EJB 2.0, yet many vendors plan on implementing entity Beans with their servers. An entity Bean is shared among multiple clients and represents specific data. Entity Beans are transactional in nature and are persistent. An entity Bean represents an underlying data object or context, such as a record in the database or a connection to an application.

With entity Beans, the container maintains a pool of unused Bean instances. A primary key is used to uniquely identify an EJBObject. Clients can obtain the primary key by using the

method implemented by the EJBObject. All EJBs will provide a primary key to their containers at the time they are created. A client can find a Bean by using its home interface to call the
findByPrimayKey(Object key) 
. It can also find a Bean by using application specific primary keys. For example, the
method in the home interface, corresponds to the
method in the Bean itself.

When the client requests an entity Bean, the container searches the Bean instances inside a pool to see if a match is found. If one is found, then the Bean instance is taken out of the pool and an EJBObject is associated with it.

Transaction support

EJB is often praised for its support of complex transactions. This capability is built on top of the Java Transaction Service (JTS). It represents a subset of OTS 1.1 (CORBA transaction service). You will have to study JTS documents to learn about it. The EJB specification discusses how JTS works in the context of EJB. Transaction control for a Bean is specified in its deployment descriptor. Control can be specified for the entire Bean or for a particular method of the Bean. There are six types of transaction controls supported by EJB. They are:

  • TX_NOT_SUPPORTED: existing transactions are suspended and no transaction can begin
  • TX_SUPPORTS: will not start a transaction, but an existing transaction is not suspended
  • TX_REQUIRED: will use an existing transaction, will start new a transaction, and commit when method completes
  • TX_REQUIRED_NEW: always starts a new transaction, commits when completed, and suspends any existing transaction
  • TX_BEAN_MANAGED: the Bean may use JTS interface to control the transaction itself
  • TX_MANDATORY: must be called within a transaction


Sun's efforts in creating the Enterprise JavaBean specification takes a giant step toward not only a framework for server-based operations but also for promoting Java as a player in the heavy transaction-oriented back-end operations of an enterprise. The vendor community has embraced EJB with much enthusiasm and despite its young age, there are already a number of implementations available. In this article, we have provided an overview of the key parts of the EJB architecture and how they fit together.

The problem space that EJB addresses is inherently complex, but EJB provides a systematic way for developers to create complex applications by focusing on business logic rather than environmental and transactional issues. That combination should be a win-win situation for vendors, developers, and the enterprise alike.

About the author

Piroz Mohseni is a senior managing consultant with Automated Concepts Inc. (ACI) in New York City. He specializes in enterprise Java, XML and e-commerce applications. You can contact him at: piroz.mohseni@autocon.com.

Page 2 of 2

This article was originally published on December 30, 1998

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date