Loosely Coupled and Peter Yared (former CTO of Sun's app server division) write about dispensing with J2EE and all the paraphenalia of application servers. Peter argues that most web apps are all about aggregating and disseminating textual data, so what we need are powerful text manipulation engines, not app servers. Peter also talks about why Java is poor at text handling, and the rise of PHP, Perl and Python for this sorts of work in The Next Language. I'm surprised to see how savagely Peter Yared gores Java/J2EE in his discussions, given his background.

The Java API’s grow into a morass of inconsistent and incomprehensible API’s, even the most simple things proved to be very complicated. The vast majority of J2EE deployments (over 80% according to Gartner) are simply Servlet/JSP to JDBC applications. Basically HTML front-ends to relational databases. It is ironic that much of what makes Java complicated today is all of its numerous band-aid extensions, such as generics and JSP templates, which were added to make these types of simple applications easier to develop.

I certainly don't think the application server is dead, but that server farms running PHP are a different form of application server. The classic 3 tier architecture with web/proxy servers (running Apache with mod_proxy or Tux or Squid accelerator), app servers with Apache+mod_php serving as powerful content aggregators, and database and RPC servers holding the all-important back-end data is still viable.

You can flatten things by having the web/proxy server running on the same machine as the app server, but they should still be kept logically separate as they serve different tasks. The web/proxy server will be in charge of caching static content, handling keep-alives, and serving as a secure proxy for the app servers, while the app server is the glue that handles input from the client and diverse data sources and back-end services.