Failed Technology: Enterprise Java Beans (EJB)
An example of over-engineering.
Enterprise Java Beans (EJB) was a part of J2EE, there are three types of EJBs:
Session Beans
implementation of business tasks, like a service.Entity Beans
bind to a relational database.Message-Driven Beans
receive messages from JMS queue.
Between 2002 and 2004, I worked on EJB projects as a Java Contractor programmer.
Below is a session bean interface:
public interface javax.ejb.SessionBean extends javax.ejb.EnterpriseBean {
public abstract void ejbActivate();
public abstract void ejbPassivate();
public abstract void ejbRemove();
public abstract void setSessionContext(SessionContext ctx);
}Modern web developers might find the above completely nonsensical. Yet, unfortunately, tens of thousands of Java developers dealt with that on a daily basis in the early 2000s.
EJB is so bad, with multiple acronyms, Martin Fowler came up with a cool acronym “POJO” (Plain Old Java Object) to make using plain Java cool.
Frankly, the memory of EJB I rather forget.
Takes longer to develop
Difficult to debug
Difficult to test
Making code more complex
developers have to define several classes for EJBs (session or entity).
What do I learn from the failure of EJB?
When I was working with EJB, I could tell it wasn’t good. Honestly, there was no real comparison, but back then, it seemed like every Java project used it—and EJB developers were paid well. But once I discovered the Ruby on Rails web framework, it became painfully obvious just how wrong EJB really was!
(A humour video by Rails Envy).
1. Avoid Over-Engineering
Based on my 20+ years of experience, I've often seen that over-engineering is actually rather common. For instance, the following technologies are far too heavyweight for nearly every project I've come across.
Microsoft Biztalk
SharePoint
Dynamics 365
I implemented the core CRM Field Service within 3 days, part-time. Check out this article.
2. EJB Container isolation is to avoid testing
The main selling point of the EJB container was: “If you only change A, there’s no need to retest B and C—provided they’re separated into different containers.” Why? Most software companies lack effective regression testing: manual regression testing is costly and error-prone.
The EJB container approach was not alone. There was Java on Google App Engine, which pretty much failed as well.
Years later, there came “Microservices”.
For more, check out the following articles:
DHH’s The Majestic Monolith
