A colleague of mine just sent me a link to this article from Jeff Hanson on JavaWorld: Is Tomcat an application server?.

That’s funny because another colleague, yesterday during the lunch, asked us if instead of developing for a JEE container it would not be better to adopt a lightweight container like Tomcat? Using frameworks like Spring?

My answer was actually another question (as often): What is a lightweight container?

When frameworks like Spring and Hibernate started, their purpose was to add functionalities that did not exist or were badly designed: flows, inversion of control and injection or entity management. People were complaining about JEE and some switched to Tomcat plus Spring and Hibernate. Some of them did so because at this moment they did not need the other JEE services.

Hanson concludes his article with the following:

When attempting to determine the server environment best suited to a particular application or system, it is helpful to break down the requirements of the system and determine which Java EE components will need to be supported.

I could not agree more with this. However, requirements evolve and people switch to new projects but they usually continue to use the same frameworks.

The result is that when the need for new services increases (transaction, security, messaging, administration) the pressure on frameworks increases and they add those services to their stack because their clients ask for it and that is fun to code.

Then, what is the difference between a JEE server and Tomcat+Spring? I mean at which point a lightweight container is not lightweight anymore? When you add transactions? And in that case why not using JEE? Because it is JEE and it is said to be heavyweight?

My answer is to always use JEE when it offers the services you need. If it does not? Use something else but otherwise use JEE. Today if I was creating a new application I would not use Hibernate for entity persistence, I would use EJB3.