EJB 3: From legacy technology to secret weapon

Four factors that streamline and modernize EJB 3 development

Some say Enterprise JavaBeans earned its reputation for complexity one burned out programmer at a time. But developers today have begun to notice that EJB 3 is an entirely different animal. Convention over configuration, annotations, dependency injection, and aspect orientation make modern EJBs a lean alternative to XML-laden and JAR-heavy frameworks. In this article, Adam Bien explains how EJB 3's new component model and persistence handling help streamline enterprise development -- and even work well for small and midrange applications.

Enterprise JavaBeans (EJB) technology is known for being neither lightweight nor cool. Until the advent of EJB 3.0, this reputation was certainly warranted. Now, though, EJB technology is lean and sound. EJBs are lighter -- even weightless. They no longer require XML configuration, deployment of additional frameworks, or JARs. They integrate well with the Java Persistence API (JPA); scale well on multicore, multi-CPU machines; and are in fact the only vendor-neutral and portable solution for enterprise server-side applications.

Alternative frameworks and solutions, on the other hand, sometimes turn out to be bloated. They can require countless JARs to be configured with several pages of XML and deployed to a Web container that, however "lightweight" it might be, ends up hosting a heavyweight application.

For all of these reasons EJB 3 is worth a second look. Let's consider what has changed about Enterprise JavaBeans.

EJB then and now

No doubt about it: the EJB 2.1 specification was not concise. It severely violated the DRY (Don't Repeat Yourself) principle. Information about an EJB component was spread across its remote interface, home interface, bean class, and deployment descriptor. Without tools, refactoring was unproductive and tedious -- and IDEs in that era weren't particularly good at refactoring.

Developers incurred considerable overhead building even simple functionality. The bean class had to implement the javax.ejb.SessionBean interface and was forced to implement all the life-cycle methods. ejbActivate and ejbPassivate were invoked only in stateful session beans, but most deployed session beans were stateless.

For example, in Listing 1, the one and only "business" method -- sayHello -- is just a fraction of the overall code for HelloWorldBean.

Listing 1. Legacy EJB 2 session bean

public class HelloWorldBean implements SessionBean {
public void setSessionContext(SessionContext aContext) { }
public void ejbCreate() {}
public void ejbActivate() {} //SFSB only
public void ejbPassivate() {}//SFSB only
public void ejbRemove() {}

public void sayHello() {
System.out.println("Hello!");
}
}

The sayHello method had to be declared in an interface too, as in Listing 2:

Listing 2. EJB 2 remote interface

public interface HelloWorldRemote extends EJBObject {
void sayHello() throws RemoteException;
}

The interface had to throw a checked RemoteException. Even so, the bean did not implement the so-called remote interface. This was EJB 1.x/2.x's main flaw from a maintenance perspective. Type and signature checks were performed during deployment, not at compilation time. Deployment errors were hard to find, which significantly increased round-trip times. You had to provide a deployment descriptor in addition to the code and keep in sync with the code. The XML deployment descriptor was the glue for all the disparate parts, so most of the information already contained in the code was repeated in the descriptor.

Although EJB 2.x session beans were verbose, and the programming harder than necessary, the benefits were huge. Remoting, the single-threaded programming model, state management, transactions, and concurrency control came for "free." These benefits are all less important (and less interesting) for development than for production, however, which is one reason why developers didn't really care.

EJB 3.0

From a programming-model point of view, EJB 3 is revolutionary, not evolutionary. The EJB 3 specification is similar to EJB 2.1 behind the scenes, but the changes in the component model and persistence are huge.

To operate, EJB 3.0 beans still need the same amount of information as their EJB 2.1 predecessors. But the way they derive and leverage the information has changed dramatically, and even inverted. Instead of configuring the obvious, you must specify only the deviations from the default. The default case contains metadata -- such as class name, method names, attribute names, and suitable conventions -- that is sufficient for about 80 percent of all cases. You can fulfill specific requirements by using annotations for configuration, or even by overriding the defaults with XML.

1 2 3 4 5 6 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies