update 2007/02/02: Joel Hockey: points at "History teaches us …" from r0ml I really want to witness a R0ml keynote someday...

Rod Johnson: "The differences that mean that you can run a huge deployment on WebLogic easier than on Tomcat are nothing to do with the Java EE specifications, but to do with QoS and manageability. For the vast majority of users, for example, WebLogic is not superior because of EJB (which they don't want) or JCA or a host of other largely irrelevant Java EE specifications. It's all about stuff beyond the specs that comes from the demands of the BEA customer base"

That would be something of an open secret. Here's Steve Vinoski saying something similar about web services technology:

"The customers that I saw benefit from WS-related technology gained those benefits only because of IONA-specific innovations that were not part of WS-*. In general, WS-* didn’t do anything for them that wasn’t already possible with prior technologies."

I have two other takes on this. First let me say this - the JEE stuff and the container vendors that drive it are tied (still, but maybe less than a few years ago) to a physical three-tier model, whereas physical two-tier is a known good way way to build web systems. I'm assuming you're building web systems because Tomcat and its ilk are in the frame as app server alternates. If not, my apologies, your problem space might well warrant physical 3-tier, and you can stop reading here.

Take 1. You don't need a honking great app server.  Spring+Hibernate is more than enough for most "enterprise" needs. In other words, all the shiny buzzword compliant stuff you wanted but could only get via a honking great app server, you can now get in smaller form thanks to people like Jurgen Hoeller and Gaven King. Rod Johnson then is being far too modest by ascribing the rise of Tomcat to just Tomcat. After buying into light-j2ee, half the battle in the Java space is trying to get your Servlets Session usage as close to zero as possible :)

Incidently, I recall Werner Vogels making a complaint once in a podcat that one of the problems with vendor middleware was too it was too big, and he would like smaller components to deploy, but I don't have a link (it might have been itconversations).

Take 2. You don't want a honking great app server. Ever. Ryan Tomayko explains why:

"Many large enterprise web applications tried really hard to implement a Physical Three Tier Architecture, or they did in the beginning. The idea is that you have a physical presentation tier (usually JSP, ASP, or some other *SP) that talks to a physical app tier via some form of remote method invocation (usually EJB/RMI, CORBA, DCOM) that talks to a physical database tier (usually Oracle, DB2, MS-SQL Server). The proposed benefits of this approach is that you can scale out (i.e. add more boxes) to any of the physical tiers as needed.

Great, right? Well, no. It turns out this is a horrible, horrible, horrible way of building large applications and no one has ever actually implemented it successful. If anyone has implemented it successfully, they immediately shat their pants when they realized how much surface area and moving parts they would then be keeping an eye on.

The main problem with this architecture is the physical app box in the middle. We call it the remote object circle of hell. This is where the tool vendors solve all kinds of interesting what if type problems using extremely sophisticated techniques, which introduce one thousand actual real world problems, which the tool vendors happily solve, which introduces one thousand more real problems, ad infinitum...

It's hard to develop, deploy, test, maintain, evolve; it eats souls, kills kittens, and hates freedom and democracy.

Over the past two years, every enterprise developer on the planet has been scurrying to move away from this architecture. This can be witnessed most clearly in the Java community by observing the absolute failure of EJB and the rise of lightweight frameworks like Hibernate, Spring, Webwork, Struts, etc. This has been a bottom up movement by pissed off developers in retaliation to the crap that was pushed on them by the sophisticated tool vendors in the early century."

The  Tomcat-is-your-app-server approach is a physical two-tier one, and maps cosely to the LAMP model that drives large chunks of the web.  Again, this is no secret, Physical two tier as a good model for web based goes back a decade at least. Here's Phil Greenspun on "Scalability, Three-Tiered Architectures, and Application Servers", which dates back to 1998 at least (ie pre web-1.0, pre the LAMP acronym):

" The Web is fairly young. However, that is not a reason to abandon sound engineering principles. You don't want a complicated untested system sitting between your users and your database. You don't want to be forced into developing dynamic documents with a language requiring compilation.

Maybe you're having second thoughts at this point. You're going to be doing lots of transactions. Your idea is so brilliant that you're going to have half the world using your site. Maybe a simple Web service layer on top of a proven RDBMS is good enough for Greenspun and his pathetic 500,000 hit per day personal site, but you're building something serious here.

Two words of advice: "America Online".

As of this writing (July 1998), AOL has 11 million members. They have a bunch of Unix machines running a replicated Sybase. They interface this replicated Sybase to the Web via a very simple stateless program: AOLserver."

What happened to Greenspun's company is instructive. Senior execs came along, and drove a rewrite in Java to follow a 3-tier model. The company failed soon after. This is not meant to be Java sucks post tho', it's more about choosing an appropriate software design.