Quick Review of EJB Technologies

Hold on to your hat ”this is going to be fast. There are already many good books about EJBs, so this section is going to skim and provide just the information you need to know. Fasten your seatbelt; we're on our way to 30,000 feet!

EJBs Live in an EJB Container

EJBs are defined by the J2EE specifications. These specifications also define the requirements for EJB containers. EJBs containers provide the system services and API support that are required to allow EJBs to run. That is, an EJB without an EJB container is like an engine without a car to put it in ”you're not going anywhere .

Formally, an EJB container is a software application that can host EJBs because it supports all the APIs defined by the EJB specifications. Among the APIs that must be supported are JNDI, Java Mail, JDBC, and a number of others. If a container is EJB compliant (so the story goes), an EJB developed for one container should be easy to move to another container. The truth is, of course, that this depends on a number of things, including the particular container you choose and how you go about developing your code.

At JavaWorld 2002, the three top EJB containers selected by judges were JBoss, BEA WebLogic, and IBM WebSphere. Other popular containers are JRun from Macromedia, Orion Application Server, Borland Enterprise Server, and ATG Dynamo. Users of the SAP ERP system can host applications on the SAP Web Application Server (formerly In-Q-My J2EE Application Server). Oracle users can deploy EJBs either in Oracle Application Server or directly in the Oracle database itself. In addition to JBoss, OpenEJB on SourceForge provides another viable open source option. (Of course, we've now likely offended someone by leaving his favorite container off this abbreviated list!)

As you can see, there's no shortage of options when it comes to EJB containers. For the sample applications in this chapter, we use JBoss 3.0.3. You can acquire it by downloading it for free at http://www.jboss.org. It is also included on the companion CD.

Because your Struts code is servlet-based, it can't live in the EJB container itself. For Struts to run, it needs a Web container (also defined by the J2EE specifications). In the examples throughout this book, the Web container is always Jakarta Tomcat.

Struts lives in the Web container (Tomcat) and EJBs live in the EJB container (JBoss), so the Struts code must connect to the EJB container to access the EJBs. The details of how to do all this are covered in later sections.

Anatomy of an EJB

Creating and using an EJB requires coding a number of classes as well as making a few important deployment decisions. The required classes are

• Home interface ” This interface defines the methods in the EJB bean class that are used to find, create, and delete EJB instances. All EJB access done in Struts is initiated by first acquiring the home interface for the EJB you need. This is done via a JNDI lookup and is covered later in more detail. An EJB home interface must extend javax.ejb.EJBHome .

• Remote interface ” Any business logic methods implemented in the EJB bean class must be defined in the remote interface for the container to allow access to them. Examples of methods defined in the remote interface might be calculateAverage() or getCustomerName() . These are the methods you invoke on the EJBs after you locate or create them using the home interface. A remote interface must extend javax.ejb.EJBObject .

• EJB bean class ” The EJB bean class is the actual class that implements all the methods defined in both the home interface and the remote interface. After your Struts code locates or creates an EJB instance using the EJBs home interface, it invokes the methods exposed by the remote interface. Those methods are actually implemented in the EJB bean class. The bean class must extend javax.ejb.SessionBean , javax.ejb.EntityBean , or (beginning in EJB 2.0) javax.ejb.MessageDrivenBean .

• Optional value object ” Value objects aren't defined by, or even a part of, the J2EE specifications. Many applications don't use them. Different people may define value objects differently, but for this book, value objects are defined as simple, non-EJB bean classes that allow information to be passed to and from an EJB "one bean at a time" instead of "one property at a time." Passing data to/from the EJB container this way helps your Struts application use EJBs efficiently .

In addition to creating these classes, you must also create deployment descriptors for your EJBs. There are usually at least two deployment descriptors: the standard ejb-jar.xml that's defined by the EJB specification, and a container-specific descriptor used by the particular EJB container you're using (for JBoss, this descriptor is named jboss.xml ). Among the information in these files is the JNDI name that's needed for Struts to access the EJBs from the Web container.