Use Apache Tomcat. It is free.

I don’t understand why firms spend millions of dollars on Java application servers like Oracle Weblogic or IBM WebSphere Application Server. I get why firms spend money on Red Hat JBoss — they want to spend less on application servers. But, why spend anything at all? Apache Tomcat will satisfy the deployment requirements of most Java web applications.

Your Java Web Applications Need A Safe, Fast Place To Run

Most Java applications don’t need a fancy container that has umpteen features. Do you want to pay for a car that has windshield wipers on the headlights? (I wish I could afford it.) Most Java applications do not need these luxuriant features or can be designed not to need them. Many firms do, in fact, deploy enterprise-class Java web applications on Apache Tomcat. It works. It is cheap. It can save tons of dough.

Expensive Java Application Servers Sometimes Add Value

There is a need for luxury. But, you probably don’t need it to provide reliable, performant, and scalable Java web applications. Application server vendors will argue that:

• You need an application container that supports EJBs. EJB3 fixed the original EJB debacle, but why bother? Use Spring, and you don’t need an EJB-compliant container. Many applications don’t even need Spring. EJBs are not needed to create scalable or reliable applications.
• Optimized application servers optimize hardware. Some of the vendors say that total cost of ownership (TCO) is cheaper because they contend you need less hardware to support the same volume. The problem is that most of those benchmark tests are orchestrated to exercise every feature provided by the feature-rich application server but not the common Java web application. Prove me wrong. Show me a benchmark of a Java web application that calls servlets. And don’t fool me with database connectivity optimization, or transaction processing, etc. For a large number of servers, hardware optimization may be improved, but only for certain circumstances. The JVM you run is far more important. For example, Oracle built JRockit into its middleware.
• Two-phase commit is serious. IBM says that they have the best two-phase commit capability in the market because they understand transaction processing better than anybody. I cannot argue with that. IBM is awesome when it comes to providing a two-phase commitment that is second to none. However, many apps do not have two-phase commit and could be designed without the need for it. If you need two-phase commit, then IBM WebSphere is the top candidate, but both Weblogic and JBoss provide this capability too. Most Java web applications don’t need two-phase commit in my opinion.
• Manageability. Manageability is super important, but all I want to know is: 1) Is the server up; 2) is my end-user performance acceptable; 3) has my fault-tolerant architecture kicked-in to solve either problem? Application architecture can be designed to auto-detect issues with availability and performance using tools such as Compuware Gomez and open source monitoring tools such as Nagios.
• Clustering supports scalability, performance, and availability. This is probably the best argument for the application server containers because enterprise web applications must be scalable, performant, and reliable. I am a huge fan of stateful web applications. Why not? For Apache Tomcat and for the other products I highly recommend elastic caching platforms (ECP) since it is a technology that is independent of the application server and super-fast. In fact, IBM has WebSphere eXtremescale, Oracle has Coherence, and Red Hat has Infinispan.
• Apache Tomcat is a toy. I question even the need for a container. Seriously, why can’t Java web applications just run on the operating system like the containerless Microsoft .NET applications? The answer is: Then we would not be able to sell hundreds of millions of dollars in application servers. Remember when Netscape sold Web servers for $50,000 a pop? No one buys a Web server now. I think the application server bubble is about to burst.

Recommendations

If you are already deploying large-scale Java web applications on Apache Tomcat, then you already know what I am talking about. If you are considering a new Java application server strategy, then consider these options:

• Existing Java web applications. Do your Java applications really need Weblogic, WebSphere, or JBoss? Ask your developers. They may actually already develop and test the applications on Apache Tomcat that is embedded in their integrated development environment (IDE) such as Eclipse. How will the applications perform, scale, and be highly available running on Tomcat? The answer is probably already architected in your existing infrastructure with a load balancer and monitoring tools.
• New Java web applications. Tell your developers that you wish to deploy the applications on Apache Tomcat. They will probably be thrilled. Just make sure that they incorporate an elastic caching platform (ECP) for applications that must be highly available, scalable, and fast.
• Spend the savings on better development tools. Faster application development and change is a key megatrend. Instead of wasting money on bloated deployment options, spend the saving on tools for faster development such as business rules platforms, business process management, and business event process. IBM, Oracle, and Red Hat all have development tools  in these categories as well as many other vendors.
• Public and private cloud — elastic application platforms. Traditional application servers or containers such as Tomcat will fast become legacy methods for deploying Java applications. The next generation is elastic application platforms (EAP) that are containerless. Instead, these platforms take advantage of public or private elastic infrastructure. For example,  GigaSpaces with XAP, Red Hat with OpenShift, VMware with Cloud Foundry.

Learn how to get faster and close the gap between application delivery and business expectations.

What is your opinion? Make the case for your favorite deployment option.

References

blogs.forrester.com