A Thought about Java EE Applications

Most of the software houses in my country seem to have embraced the concept of EJB3 hardly, for new projects. They develop new projects (and ports) using EJB3 as the middle tier technology, for various reasons.  Majority of the companies also employ Spring Framework as a part of their solutions as well. With the additions of JEE support (XML Bean Definitions) in Spring, the two technologies complements each other, and can be used to promote good programming practices like coding to interfaces, through Spring’s Inversion of Control support. Also, companies are embracing JPA, due to the simple nature of the technology, through “convention over configuration”. Finally, because of the use of EJBs, the solution is deployed into a full blown application server such as JBoss, Websphere, WebLogic etc. 

However, most of these applications are just web applications. And the architecture of these solutions are not distributed. All components of the solution live in a single VM. This raises the question, why do we need EJB? Well, in my perspective, I think it’s basically due to the fact that most developers think EJB is a core part of J2EE stack, and it should be there no matter what. If the final solution is deployed into a clustered environment, if the app is going to be executed in a distributed manner on several VMs, then yes, EJB is the way to go; but why for a webapp which runs in a single VM? Majority of the projects out there are not multi-modular distributed applications. They are single module web applications. IMO, using a technology like EJB is overkill for this type of projects. 

Spring is a good alternative in this kind of scenarios. With Spring, you don’t have to use EJB, and you can reap the benefits of writing a “full-blown EJB app which runs in a Application Sever”, but still deploy on Tomcat. As I mentioned before, most people still use Spring with EJB3, just for the sake of using it, and to gain the benefits of IoC. While this is good for projects where the use of EJB is really worth, it is not the case for most of the projects. What they don’t understand is that Spring itself can provide all the facilities that a EJB + Application Server stack  could provide. Consider the following table, 

Java EE (EJB + Application Server) Feature

Spring Feature

JPA based ORM

JPA based ORM through Spring

Connection Pooling

Connection Pooling through various open source libraries (Apache DBCP, etc)

Message Driven Beans

Message Driven POJOs

Container Managed Transactions

Spring Managed Transactions (JTA)

RMI Remoting

Remoting through RMI, JMS, Spring HTTP Invoker, Burlap, Hessian, WS


Spring Scheduling support through Quartz

Though the J2EE Spec says its portable, in reality, we will end up using AS specific features. So portability from AS-to-AS requires some degree of modification, in most real life scenarios.

Can be ported to any Web Container, Application Server without issues (along with Spring).

? (Depends on AS)

In built support for AOP


Looking at the above table, it is obvious that Spring has support for most of the features of JEE Stack, which drives developers to hug the JEE Stack. Yes, EJB + AS Stack is good, and should be used for problems where the application should be clustered, and executed in distributed manner. But for most of the applications out there, Spring is a far more lightweight, low cost, and robust solution. And more than anything, we don’t have to use an Application Server. We can deploy to Tomcat and get the benefits of running on a high cost application server. Finally, the best thing is that with Spring, the services layer (augmenting EJBs) will consist of mere POJOs, and you can test the POJOs using JUnit, inside your IDE (without deploying at all – you heard it right 😉 ). Why should we go through all the hassle of EJB, if we can do the same using a simpler solution? After all, “simpler IS the better (and lesser bugs)”.

 So, in conclusion, EJB should be used in cases where it will really provide benefits, like clustered environments and some distributed architectures where it will really be useful. For all other cases, I believe it’s better to go for the simpler solution through Spring, than relying on EJBs and Application Servers, which will not payback end of the day.


  1. This is really a good post. It explains very common problems or problematic approaches that ppl face in JEE application development especially during the technology selection phase of a particular project. As Yohan explains we as JEE developers have the “EJB mentality” which causes lots of overhead in long run. So its better to keep everything simple rather than trying to build perfect solution for all unexpected scenarios. The Best approach is keep it simple, and you do it when you need it.

  2. This is a great post. But I have a concern here, I have been told too many times to use the EJBs in a clustered web application. and in this post you are telling the same thing. but I don’t see any benefit for the EJBs in a clustered web application.
    I mean even with a clustered web application there is no need for the EJBs.
    Can you please tell me or send me an article or reference explains why do I need the EJBs in a clustered web application?

    Thank you in advance

    1. Hi Haitham,

      Actually, you don’t have to use EJBs for clustered ‘web applications’. For a web application, container support for session replication is fairly enough to be clustered.

      However, if you are looking at remoting at service level (ex. to physically break down the application into two tiers, web and application services), then EJB’s are easier to use since they support RMI based remoting out of the box.

      But if you are looking at a web application which is deployed as a single unit, you can easily run a cluster without EJBs.

      Even for the case where you need service level remoting, frameworks such as Spring support various remoting mechanisms such as RMI, Burlap, Hessian and various other methods. See http://static.springsource.org/spring/docs/2.0.8/reference/remoting.html.

Leave a Reply

Your email address will not be published. Required fields are marked *