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.

1. This section briefly introduces EJB's
2. The next section explains how bean managed persistend entity beans should be coded.
3. The last section explains how a deployment descriptor should be written.

Why EJB?

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.

Prerequisites

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 2EE SDK.

Please note that other application servers may do things differently to achieve the same goal of running a simple EJB client.

1. 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 class.
2. 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 applications.
   • No code needs to be written for the application.
   • This step involves creating an "ear" file
3. Package the bean and place it in the application ear file
• The bean classes created in step 1 are added to an EJB Jar file, along with the bean's deployment descriptor.
4. Deploy the application
   • 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.
5. Code 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.
6. Run the client

That's quite a complex list of tasks. The next section explores BMP entity beans, in detail.

Next Page