Is Apache Tomcat really sufficient Java Web Applications? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 9 years ago.

I came across this article: Stop Wasting Money On WebLogic, WebSphere, And JBoss Application Servers via a tweet today.

The article starts with

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.

and goes on giving some reasons why:

• You need an application container that supports EJBs.
• Optimized application servers optimize hardware
• Two-phase commit is serious
• Manageability
• Clustering supports scalability, performance, and availability

I love Tomcat and have developed on it, so I will be happy if all these are true. However, I don't see much convincing reasons that you don't need any other application server at all.

So, my question is: In what situations you think you need an (so called) advanced server like Weblogic/Websphere/JBoss. Is there a business case for Websphere/Weblogic/JBoss at all, or should Tomcat do almost always?

Is there something essential that Tomcat does not/can not provide?

Answer 1

Depends on what your application needs. Tomcat is mostly just a servlet container, while JBoss, Websphere, and the others provide full Java EE support (usually plus additional platform-specific features above and beyond the Java EE spec).

For many applications, a servlet container is sufficient. Especially since you can get a lot of Java EE-like features by just bundling the appropriate libraries as part of your webapp. But sometimes you need this-or-that feature that is only readily available on one of the full-scale application servers.

That said, using a full Java EE server when all you really need is a servlet container does strike me as a fairly foolish thing to do. As a general rule I always start with Tomcat, and only switch to something like JBoss once I've identified a need for something that Tomcat can't provide (doesn't happen often).

It's really trivial to take a webapp that runs on Tomcat and make it run on JBoss, so there's no reason to jump straight to the more complex platform and no real penalty if you decide to do so later on in the game.

Regarding the specific points raised in the blog article:

You need an application container that supports EJBs

He's right, you don't need this. There are popular frameworks like Spring which provide the same sort of functionality as EJBs. You can do just as well with one as with another, and it's generally not the case that you will use both at the same time.

Optimized application servers optimize hardware

No comment. Personally I'm of the opinion that unless your webapp is doing heavy multimedia processing or similar tasks then modern hardware has gotten to the point that it is more than fast enough to run whatever your app may be, even without any special optimization. That's why virtualization is such a big deal. A single server is now way too powerful to dedicate just to a single site, so we carve it up into several virtual servers each running their own site because otherwise all that computing power just goes to waste.

Two-phase commit is serious

Again I don't disagree with the blog post. Two-phase commit is not serious, unless you happen to need it. And I've never once needed it. A database with optimistic transactions and rollback has been sufficient for every project I've ever worked on.

Manageability

In my experience as a developer, JBoss is far less "manageable" than Tomcat. It is just ridiculously difficult to configure. Granted that's not the same type of manageability the article is referring to, but it's still worth noting. Other than that, Java EE containers will generally have far more built-in features surrounding server management, but there are also plenty of third-party tools that you can use to get similar features out of Tomcat (or any other flavor of server).

Clustering supports scalability, performance, and availability

Tomcat supports clustering, and is no less scalable than the other platforms. In fact, JBoss runs on top of Tomcat, so obviously there is nothing about Tomcat that inherently prevents it from scaling or makes it unsuitable for use as an enterprise-level platform.

Answer 2

The article is not really correct.

Glassfish, Resin, Jboss AS, TomEE and a few others are all opensource and free. You don't have to pay a dine to anyone to use them.

The part about EJB is especially nonsense. It's not 2004 anymore! These days EJBs are very simple lightweight pojos. You don't need any heavyweight XML or invasive framework inheritance. They among otherd massively simplify working with JPA and make simple asynchronous methods a breeze.

A big falsehood in "Tomcat in enough", is that actually a bare Tomcat never is enough. Not a single non-trivial application runs only on Tomcat. Even trivial applications have a hard time with that. Instead, people add tons and tons of additional libraries. Typically at least JSF, Spring, Javamail, some JTA impl. and Hibernate. This equals a few dozen jars, of which the user has to make sure they are all working together, and after some time whether they are all still needed.

With a Java EE implementation, you get everything you need in a single package. All dependencies are already worked out for you and it's guaranteed to work together as a whole.

If someone is really concerned about having functionality available, but not using it; there's the Java EE Web Profile. This is a subset of the full Java EE profile that contains the functionality most web applications would use: jsf, cdi, ejb (lite), jpa, jta and javamail.

Web profile implementations can be very small. Resin for instance is 20-something MB, compared to Tomcat's 7 or 8 MB. Yet Resin is a full stack solution, while Tomcat is a bare bones servlet container that as said needs tons of additional libraries. Startup time of Web Profile implementations is mere seconds (Glassfish v3 and JBoss AS 7 start in 2 to 3 seconds).

Answer 3

Apart from all the useful information that was already given, I'd like to say that a lot of customers are willing to pay extra cash to the vendors that provide additional support. Have a look at the IBM Websphere support. I guess it could be very useful for maintaining critical business applications.