The Problem with EJBs
I had someone post a question in the comments section of my last post on Behavior-Driven Development “asking about EJBs”:http://www.fuzzylizard.com/archives/2006/09/15/794/#comments. I thought I would answer it with a new post instead of just a comment. Where do I start?
First, I need to define the term EJBs. For me, EJB means either Session Bean (stateless or statefull) or Message-Driven Bean. It does not mean Entity Bean. Entity Beans are just wrong and will not be considered further. As far as I can tell, no one really uses them (yes, there are exceptions, but those people are just masochists).
What is the state of Session and Message-Driven Beans? Some people use them, others do not. I personally would advise against them. The vast majority of applications are not distributed, run in a single app server, and can be completely implemented in the web container.
The main problem with EJBS is that they are completely untestable. This is a huge problem. There is no way for me to run a simple JUnit test against a session bean from within an IDE such as NetBeans or Eclipse. In order to test an EJB, I need to build and deploy the entire application inside of the application server. I then need to figure out some artificial way of entering into the app server and executing a method or two on a single bean. Not a fun way of doing development.
In order to do any kind of real development with EJBs you need to abstract all of you business logic out of the bean and place it into POJO that the bean then calls. In order to do this, you need to introduce another interface to ensure that the bean and your business POJO stay in sync. Then, you are able to test the POJO instead of the bean. However, now, in order to implement a bean, we need to not only implement the bean interfaces (local and remote), but also our own interface.
So now, not only is the bean aware of its environment, through having to implement the bean interfaces, but it is also aware of the business rules as well because of our own interface that it implements. So even to test a bean’s functionality (which eventually does not exist in the bean anyway) we need to jump through hoops. Ugh.
Basically, my personal feeling, and that of many other people, including Sun is that EJBs (at least EJB 2.x) are fundamentally flawed. Thus they were rewritten for EJB 3.0 and the Java Persistence API (JPA).
If you want an excellent article detailing what is wrong with EJBs then check out Bruce Tate’s “Don’t Make Me Eat the Elephant Again“:http://today.java.net/pub/a/today/2004/06/15/ejb3.html.
Well what about scalability. How can you scale applications the way you can with EJB. Because with EJB you simply add another server with your EJB code and you’re good to go. How would you do it, the “non-EJB” way?
My initial answer to that question is actually twofold: first, I am not convinced that you can just “simply add another server” and get a true 1x scaling factor (i.e., double the throughput of the application) and second, I am not sure that using a distributed method of scaling is the right method of scaling an application. My second answer to your question is that I am not really sure. I have not worked with EJB applications enough to fully answer your question.
Over and over again I keep hearing on the net two things, the first is that most real applications only use the web container and second that scalability is highly overused.
I think that if you really do need an application that must service millions of transactions a day with 99.999% availability and must be distributed geographically, then EJBs may be the way to go.
If I can find some links to better answers, I will post them because I realize that my answer is definitely lacking in evidence to support my opinions.