The Great EJB Debate
During the initial architecture and analysis of our J2EE-based application,
one Java issue generated a lot of attention on our team : Enterprise Java Beans or EJBs.
Should we use EJBs?
What flavor of EJBs should we use?
At the time, we received no practical advice on EJB usage.
We got a lot of general advice. "Use what is best for you, etc."
Quite often, we were referred to a diagram with a lot of boxes and lines on it. "Do it like this."
We also got plenty of advice\best practices on JSP and Servlet usage.
Thus began our debate on EJBs.
Our application server had just started supporting EJB 2.0.
The arguments against EJB use were the following:
- too complicated to develop with
- too new and untested to be of any value
- would result in bad performance for the application
The arguments for EJB use were the following:
- could be used to support any kind of function within the application
- allows for a complete decoupling of business functionality from user interface functionality
- developer tools will assist with generation of the various EJB-specific interfaces and classes
Eventually, we decided to go ahead and use EJBs in our application.
This was a team decision. No one forced us to use EJBs.
When we resolved the question of EJB usage, the next question was:
Which type of EJBs do we use?
- Stateless Session Beans (SLSB)
- Stateful Session Beans
- Entity Beans
A key part of the debate was that our app was not just a web-based application.
Our app included some long running processses that needed to be executed from the app server.
So we wanted a J2EE host component for these long running processes.
We decided to use Stateless Session Beans.
Stateless Sessions Beans seemed to be the choice to fit all of our application needs.
Soon after this, we realized an important best practice for SLSBs.
That the granularity of SLSBs is very important.
We decided to adopt a course-grained approach to SLSBs.
Each distinct screen or function within the app would be guided by a single Stateless Session Bean.
No SLSB would call another SLSB within the application.
Stateless Session Beans would become so important, that we sometimes called our app an "EJB-based" application.
From SLSBs, our application's business logic and database access were performed.
We have never found a reason to use Stateful Session Beans. Never found any value for its state-saving feature.
We initially used Entity Beans.
Each time we changed a table in the database, we had to redo the Entity Bean that mapped to that particular database table.
We did not like the tight coupling of database and Java code.
So after more debates, we stopped using entity beans.
So that was our great EJB debate.
What have we been doing, EJB-wise, since then? Plenty.
Another application server upgrade enabled us to start using EJB 2.1.
We made immediate use of the timer features included in EJB 2.1.
EJB timers have become a very useful tool for our application.
We have adopted Message Beans. Message Beans (and JMS) have become a major and vital part of our application.
We have completely abandoned Entity Beans. Nobody misses them.
We continue to use Stateless Session Beans as the backbone of our application.
Lastly, we recently upgraded our application server, so we are now beginning to use EJB 3.0.
We have high hopes for EJB 3.0.
EJBs. We can't live without them. Go EJBs go!