Is EJB Relevant Anymore?

Since its inception, the Enterprise JavaBeans (EJB) technology has been a bit of an enigma. While almost all other Java/J2EE (now Java EE) technologies seem to be quite important, somehow knowing how to work with EJB has always been something to be proud about. If someone claims that she has experience in J2EE technologies only to discover that it excludes EJB, the experience in J2EE is more often than not considered as irrelevant.

Against this backdrop, several interesting developments have been happening in the last few years. When Rod Johnson came up with his ideas about the misuse of EJB, it stirred the whole thought process quite dramatically. However, the overall thought process still seemed to be that while there is no alternative people would continue to use EJB. However, this has changed very rapidly of late with the growing popularity of frameworks such as Spring, and several people are claiming that EJB is dead.

While there have been arguments and counter-arguments on the subject for over half a dozen years now, perhaps time has come to have a mature debate about this and decide once and for all, the future course of action. While this would involve considerable efforts and time, this article takes a look at some of the arguments that have been made in the past, and examines them in the context of the new developments surrounding the Spring movement.

The need for EJB

Sun MicroSystems came up with the EJB concept essentially to resolve many of the challenges in the backend layer of the application, such as resource management, transaction management, security, scalability, threading issues, pooling, and so on. While Servlets and JSP thrived and fitted nicely in the C (Control) and V (View) of the MVC architecture, EJB was advertised as the best M (Model). Perhaps, this was the reason behind EJB’s immense popularity, which soon turned into hype.

As Rod Johnson and several others pointed out, it was wrong to always use EJB, regardless of the requirements. More specifically, unless the application was distributed, requiring remote access, there was perhaps no need to use EJB. Within EJB, entity beans were generally considered very heavy and quite unnecessary by most. So was the case also with stateful session beans. So what essentially remained were stateless session beans and message driven beans. However, the challenge was – even if one agreed to not use EJB wherever possible, what were the alternatives that were available at that point in time?

Several solutions were proposed, but those were mostly in the form of writing your own code to implement what EJB would otherwise do. In the process, we would certainly reduce the EJB costs, complexity, and unnecessary hype; but then coding it all ourselves was also quite a task! Naturally, while the debate was on, and some round-about solutions were being suggested all the time, it was difficult to see how one could replace EJB.

It was then that the Spring framework arrived. Without needing any expensive investments in an application server, Spring provided many of the EJB (and other technology) features in an elegant fashion. Moreover, it was all done in the Plain Old Java Object (POJO) style and with the help of some XML configuration files. Now, there was an alternative to EJB, and as more and more people started using the Spring/Hibernate (or another ORM) technology, the equivalent of a developer movement started, trying its best to make lives simpler when dealing with the complexities of enterprise software development.

Arguments for and against EJB

While we have listed some of the perceived drawbacks of EJB, it would help to perhaps list the most commonly stated reasons behind the pro-EJB and anti-EJB movements:

Why should we use EJB?

1. EJB is designed considering the various issues faced by a typical enterprise Java developer, and instead of she having to code for all of it, it is much better left to a mature standard (EJB) implemented by a strong product (such as IBM WebSphere and BEA WebLogic).
2. It fits nicely in the J2EE stack of technologies.
3. Because we do not write logic to handle issues such as pooling, transaction management, security, etc, applications can be easily scaled as per the requirements. After all, we leave all this work to the application servers.
4. There is a strong support from many vendors to the EJB specification.

Why should we not use EJB?

1. The EJB specification is quite complex and unnerving.
2. Coding in EJB dialect is not easy, and leads to a number of extra classes – although they are generated by the underlying technology for us (which is no longer a problem with the introduction of EJB 3.0 specifications).
3. Many times, EJB is used for the sake of it, when simpler architectures can suffice.
4. Although it is claimed that EJB is portable across application server vendors, in reality, it is not.

Where does it lead us?

EJB 3.0 has significantly simplified the developer’s life. It heavily uses POJO, incorporates ORM style of DBMS access, and is well supported by a number of IDEs now so as to further reduce coding complexity. However, the question that many people are asking is, is it too late? Should we use Spring (or an equivalent technology) as the default and look at EJB only when we need to deal with the complexities of remoting and distributing applications? After all, Spring can run without any application server. Why should we invest in these heavy products and use only a few of their features, ignoring a majority?

While EJB 3.0 has certainly made life much easier for enterprise Java application architects and developers, perhaps this reality is slowly dawning upon them. It looks as though more and more applications are going the Spring-Hibernate-Tomcat route (in development, and perhaps to another server in production, if necessary).

While this certainly does not signal the end for EJB, it is certainly moving away from the mainstream in comparison with the alternatives that are emerging in the market.

Related:

• We don’t need these big heavy J2EE application servers
• Spring and EJB 3: All-Star Team or Neighbors with Good Fences?
• Excited About EJB 3.1 & JSF 2.0?