Enterprise Java Beans, otherwise known as EJB's, are gaining popularity
in the Java community. The purpose of this article is to learn how
EJB's should be coded.
So far only bean managed persisence entity beans are covered (BMP
EJB's), using the EJB 1.1 specification. Thankfully the up and coming
EJB 2.0 spec does not have any drastic changes with regards to these
types of beans.
This article is divided into three sections.
- This section briefly introduces EJB's
- The next section explains how
bean managed persistend entity beans should be coded.
- The last section explains how
a deployment descriptor should be written.
Software development is always changing. Enterprise Java Beans
are an interesting approach to software development.
EJB's are in effect a set of rules Java programmers should follow
to write their software as a set of components. The specification
clearly defines the roles an EJB container should play (sometimes
referred to as an application server), and which roles a bean should
play. This means that a bean programmer no longer needs to write
code to deal with transactions, security, or distributed computing:
the container is meant to implement these features, and make them
available to the beans it manages.
EJB containers are currently available from many sources. Some
commercial implementations are available, some free open source
implementations are also available.
The EJB design, which leverages many technologies, ensures that
the end application is scalable, robust, secure and maintainable.
Also, by breaking down an application into a set of components,
code reuse in projects is more likely than ever before.
It is assumed that the reader of this article will have configured
and run a very simple EJB application, such as that supplied in
Sun Microsystems "Getting Started" section of the J2EE
SDK. This ensures that the reader has correctly installed and configured
an EJB server and related tools.
Hopefully the reader has also grasped some basic understanding
of what an EJB can be (session or entity). Also the reader is aware
that an EJB can be packaged in in some kind of archive along with
a deployment descriptor. The exact details of developing EJB's and
packaging EJB's are the goal of this article.
As a refresher, the following steps need to be followed to put
together a simple stateless session EJB application with Sun's Java
Please note that other application servers may do things differently
to achieve the same goal of running a simple EJB client.
- Code the Enterprise Bean classes.
- Code the remote interface class. This interface
defines the business methods a client application can call.
- Code the Home interface class. This interface
defines the methods that allows a client to create, find or
remove an enterprise bean. Some types of bean, such as entity
or session beans, require more methods than others.
- Code the enterprise bean class. This class
is in effect the bean instance. Code has to be written to
carry out the bean's functionality. If it talks to a database,
the methods to interact with the database should be in this
- Create the Application
- An EJB is not deployed directly into the application server.
It needs to be deployed in an application. In effect an application
is a way of partitioning groups of enterprise Java beans into
- No code needs to be written for the application.
- This step involves creating an "ear" file
- Package the bean and place it in the application ear file
Deploy the application
- The bean classes created in step 1 are added to an EJB
Jar file, along with the bean's deployment descriptor.
Code the client
- This step transfers the application to the application server.
In effect, once deployed, all the EJB's within the application
are available for clients to use.
Run the client
- The client can be written in a variety of ways. As a JSP
page, as a servlet, a Java application...
- The client needs to create an instance of the Bean's
home interface. This is done via JNDI.
- The Home interface is used to create an instance of the
bean's remote interface.
- Now the client can call the bean's methods found in the
remote bean interface.
That's quite a complex list of tasks. The next section explores
BMP entity beans, in detail.