EJB inflation

Ever since the JavaEE standard introduced the Local interfaces (and especially in EJB3), I see people abusing EJBs. The logic is simple – if EJB calls are local, let’s use EJBs, and enjoy dependency injection.
Recently I assisted a customer who had over 200 EJBs in a project that had about 500 classes! I call it EJB inflation, and it’s bad. Really bad.
The reason – the EJB container does more than just proxy remote calls. It handles security, transactions, pooling and more. Using those, for every class, is paying a huge price in performance. Let’s just say that when I run a profiler on the customer code I saw that over 20% of the server time is wasted on the application server EJB related code (JTA, specifically).
I will post workarounds for this in future posts, but in the mean time – beware abusing EJBs. Don’t fall to the “if you have a hammer, everything looks like a nail” trap.

One thought on “EJB inflation

  1. I vividly recall, back then in the mid-1990’s when EJB technology just came out, people would bend over backwards and twist their architecture and design for the sole purpose of fitting their problem domain to the technology, instead of the other way around.
    If you’re not going to use EJB technology for its container benefits (transactions, security, etc) then don’t use it at all. EJB should be treated as a deployment layer only, and once designers start realizing that, we’ll see a dramatic decrease in the number of EJBs living on this miserable planet.

Leave a Reply

Your email address will not be published. Required fields are marked *