July, 10 2003

J2EE applications use too many EJBs. The correct¹ number of EJBs is one per component. My reasoning is below, but first a quick review of the technical pros and cons of using EJBs.

Pros:

• If you follow all the rules, individual EJB-wrapped components can be distributed.²
• Container provided resource pooling can be useful.
• Container manages transaction scope for you.

Cons:

• Any EJB takes a LOT more effort to implement than a standard Java object.
• Any EJB takes a LOT more effort to use than a standard Java object. PortableRemoteObject anyone?
• Any call to an EJB takes a LOT longer than a call to a standard Java object.
• Getting hold of container provided resources requires JNDI.
• CMP Entity EJBs are more effort to use even a roll-your-own persistence layer, let alone a purpose-built Object-Relational mapper.
• BMP Entity EJBs ditto.
• Stateful session beans are useless for any real world problem.³
• Configuring an EJB container ranges from inconvenient through to painful.
• Most commercial EJB containers are heavy-weight monsters that eat memory and CPU cycles for no discernable benefit.

Each of the advantages gained from EJBs, is gained, in full, with the first EJB you use. Additional EJBs don’t give additional advantage.

On the other hand, (most of) the disadvantages of using EJBs accrue with each and every EJB. Each additional EJB gives a bigger helping of disadvantages.

From here it’s a very small step to the conclusion that you should use as few EJBs as possible, preferably zero. However, if you find the advantages of using an EJB container compelling, then I recommend a maximum of one stateless session bean as the interface to each component.

¹ If you know of an application that would benefit from more EJBs than this, please let me know. I’ve yet to encounter one.

² Though I’ve never seen an EJB application gain any performance or reliabilty by distributing itself over multiple machines. IMHO, most applications don’t follow the rules strictly enough to allow transparent distribution.

³ Except that they are the only mechanism available to get hold of the SessionSynchronization interface, and thus the only way for EJB 1.1 objects in a container to “listen” for whether a transaction is successful or is rolled back.

Updated: This new entry extends and clarifies my argument.