When Does EJB Make Sense?
Ted says:
If you’re like most Java developers, you heard the term “EJB” and immediately got a note of distaste in your mouth.
Yep, that’s right. The first thing that comes to my mind is…complexity. You never really write EJBs by hand because there is so much duplication and so much configuration. The fact that EJBs (for all practical purposes) require code generation tools (XDoclet, wizards, etc) is a bad sign. He continues:
You know that if you suggest EJB on your next Java project, you will be ridiculed and shamed and made to stand in the corner with the Dunce Cap on, even if it makes complete sense from a technical perspective.
I wouldn’t suggest EJB for the next project. In fact, I’m trying to imagine how it would ever make complete sense from a technical perspective. I cannot think of any reason to advocate EJB.
The paragraph then suggests:
Companies are choosing instead to build their own transactional-oriented client/server middleware infrastructure, just to avoid the “shame” of using EJB. Because, as we all know, you just can’t test EJB.
I don’t think shame has much (if anything) to do with it, nor do I even think testing is that big a deal. Hardly anybody builds transactional infrastructure, although I guess that depends on what you mean by “transactional infrastructure”.
It is damn easy to grab Spring, Tomcat, and a handful of other open source projects to completely replace EJB. Not even a day’s effort. Hell, I recently put together a server-side app using Tomcat and Guice, and the whole “transactional infrastructure” consisted of little more than some ThreadLocal helper classes, a bit of AOP, and a servlet filter. Shame on me for spending a day to build my own infrastructure and be free from EJB for the next several years of maintenance on this project!
I submit to you that my Guice + Servlet project is far easier for humans to comprehend and maintain than any EJB app.
No Shame Here
We do not avoid EJB for “shame”. We avoid EJB because we know how much of a pain EJB is, and we know that thanks to products like Terracotta, for instance, we can duplicate EJB’s feats with far less pain.
EJB is painful because it suffers from accidental complexity. The programming model encourages duplication, and generally forces us to complicate our build procedures by incorporating code generation steps and/or “wizards”. At runtime, it is painful because it promotes a monolithic, gigantic EAR file that makes scaling out to clusters all that much harder. EJB is painful because it locks you in to a particular app server for all but the most trivial apps. It is painful because error messages are so cryptic. It is painful because of classpath woes. It is painful due to slow deployment, and OutOfMemoryErrors when you hot-deploy one to many times.
I feel no shame by advising my friends and customers: avoid EJB. There are better, simpler solutions, free solutions.
On Second Thought…
Maybe I would feel shame if I advised you to use EJB. I guess Ted’s right. I avoid EJB to avoid the shame.
Your comments are fine if you’re talking EJB2, but have you heard of EJB3? It’s a total departure from EJB2. All the configuration is done via annotations straight in your beans, there’s no extra files and there’s no need for the tedious translation you do with other frameworks, it just works. What’s more Netbeans can generate your beans straight off your database, dependancies and all. Now if that’s not sweet like honey I don’t know what is. We’ve been using it for the last 6 months here with great results.
Sprinkle in some spring, and you have the ultimate J2EE framework.
I should probably address some of your statements:
“The programming model encourages duplication, and generally forces us to complicate our build procedures by incorporating code generation steps and/or “wizards”. At runtime”
- With EJB3 I just don’t see the duplication you’re talking about? Wizards? What wizards?
“it is painful because it promotes a monolithic, gigantic EAR file that makes scaling out to clusters all that much harder.”
-you’re free to deploy the ejb as a jar, and the war as a war. We use Glassfish. Deployment takes under 3 seconds. You can deploy one without deploying the other, and it clusters just fine. I don’t see why scaling is hard at all?
“EJB is painful because it locks you in to a particular app server for all but the most trivial apps.”
- I’ll concede that you are locked into Glassfish or JBoss, which can be a pain for small projects. But for large ones Glassfish is so much superior to Tomcat, I’m not sure why that’s an issue.
“It is painful because error messages are so cryptic. It is painful because of classpath woes. It is painful due to slow deployment, and OutOfMemoryErrors when you hot-deploy one to many times.”
- Classpath woes? Cryptic errors? Slow Deployment? What server are you deploying to? Like I said our large projects deploy the EJB layer in under 3 seconds, as many times as you like, with no OutOfMemoryErrors. We use Glassfish though, your mileage may vary on other servers.
We have two classes of apps where I work. The “legacy” apps that are probably forever mired in EJB 2. The “new” apps have freedom to do something else. Frankly, if EJB 3 is all about POJOs, then I fail to see any benefit of using it. I say just write POJOs and use what you need from Guice and Spring.
Fair call on Guice and Spring, I have no objections to people using other frameworks, I just thought your assessment of EJB was rather out of date.
Personally I’d still take EJB3 and Spring, especially since Netbeans writes the EJB pojo’s for me, meaning I don’t even have to think about persistence, but that’s just a personal choice.
You should check out warp-persist and warp-servlet which provide persistence, transactions and servlet-oriented functionality for guice webapps. We integrate Hibernate, JPA and db4o.
http://www.wideplay.com
Dhanji.
Rusty is right.
Hi!
I work with glassfish and EJB3, and it’s real fun to work with this combination.
Glassfish is a very nice server.
But how do you guys combine spring and ejb3?
An how do you do unit testing? is there a test container, oder do you deploy to unit test?
bye
- stephan
From yours comment I think you are referring EJB2.
Try EJB3 with Glassfish and I’m sure you will see the difference.
Currently we have deployed several application to our customers using JEE5 and works great !
Is it so difficult to develop EJB when we have tools like RAD. I think its just a matter of few clicks to create a new EJB
“Your comments are about EJB2. Have you heard of EJB3? It’s so much better, blah blah blah.”
Is isomorphic to the comment:
“Your comments are about Windows 2000. Have you heard of Windows XP? It’s so much better, blah blah blah.”
Which is isomorphic to the comment:
“Hey Rocky! Watch me pull a rabbit out of my hat!”