At the beginning of 2012, with just a some months to live before the maya prophecy will strike (:-)) it's still common to find people arguing about which is better Tomcat, JBoss or none or them.
Although some months old, this article describes exactly the casus belli
The first thing I don't agree is quite simple:it's not worthy comparing Tomcat and JBoss, because one of them is a superset of the other.In fact JBoss AS (in every release) is bundled with a forked version of Tomcat. So JBoss is Tomcat plus
- JMS messaging provider
- Web Services engine (JAX-WS and/or JAX-RS)
- Management capabilities like JMX and a scripted administration interface
- A powerful data grid solution (Infinispan)
- Advanced security, e.g. out-of-the-box integration with 3rd party directories
- A dynamic and powerful clustering engine
- Transaction management service
and much more
At this point, you might argue:
Instead of using application servers, I can still deliver a full stack application using Tomcat + Spring + Spring transactions + Spring MVC + Spring jBPM or any other kind of integration etc.
Ok. true. But at what price ?
I'll make you an example: currently where I'm working there are two projects with much similar characteristics: Web application using a BPM solution (jBPM), Hibernate and transactions. The first project has been moduled around Spring + Tomcat, with all the integration stuff (transactions, jBPM and Hibernate) configured on Spring. The second one is focused on jBoss, powered with jBPM.
Guess what is the only difference between them: the cost of the people working on it. As a matter of fact, everything you can do with an application server you can do it also with Tomcat + Spring adding the right frameworks and writing the Spring integration layer with these frameworks. But at an higher price. The JBoss project is focused around average-to junior developers. Mastering the same complex stack of technologies with Tomcat and Spring requires skilled and well paid developers. As a matter of fact this project exibits a lower ROI.
So, we should not really care anymore about which is better, but focus on the application requirements. If you need all the stuff you mentioned, choosing an application server can pay good dividends because you will get quickly to the point. And that can match perfectly today's tight budget and always shorter time to deliver applications.
Additionally, we should be aware that application servers are based on a Java EE specification, while Spring is not a specification but a set of well written APIs. So you can use it in different ways according to documentations and experiences you get from the Net.
There's a big difference between these two things, since JEE was written to establish a normalized application stack that manage the redundant technical part ( object pooling to improve performances, manage transaction and distributed transaction, standardized synchronous and asynchronous communication, allow the ability to move components easily to a different server to ensure scalability, persistence mapping, and so on... ) so that developers focus on the functional part that differs. So as a general idea IMHO we can argue that with application server you are more productive and quicker.
Although JEE has made some mistakes (2.0/2.1 BMP/CMP EJBs...). but the specification has evolved to correct those mistakes by including other solutions that were more effective. Great lesson of life. - Thousands of JEE applications are currently in production. The spec is widely implanted: We’ll be able to find JEE developers and architects for years to come.
However there are no reasons why you cannot marry the Spring's IoC with JBoss. Spring is designed to work in any application server (or outside an application server); using Spring does not mean ignoring what the server may have to offer. It just provides greater choice in a lot of cases. And that might be perfectly the case of JBoss AS 7.
JBoss AS 7 is no more an heavyweight monolithic container but a modular application server featuring true classloading isolation, modules loaded on demand, domain management and exceptionally lightweight container.
Debate will continue as it's natural that developers will still draw a line between Spring and application server. However, IMHO you can still use the best of these two worlds in your Enterprise applications.