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.
|
