Tomcat vs WebSphere: How these application servers compare

Java EE API support

A product must implement the Servlet and JSP API to quality as a Java application server. Both Tomcat and WebSphere meet this criteria, but WebSphere pushes one step further with its implementation of a complete Java EE software stack. That means the traditional WebSphere Application Server provides support for an extended set of APIs, such as the Java API for RESTful Web Services, the Java Messaging Service and the Java API for XML Web Services. Tomcat only supports a subset of APIs required by the Java EE Web Profile, which is itself only a subset of the full Java EE spec.

There is also an Apache project named TomEE that builds upon Tomcat to provide an open-source implementation of the Java EE stack. If you’re looking for a Tomcat-based Java EE application server, it’s definitely worth some consideration.

Tomcat vs. WebSphere installation

The installation of the two products is also markedly different.

Tomcat is distributed as a compressed archive with two dependencies, a JDK installed and JAVA_HOME configured. With these dependencies met, the installation of Tomcat only requires you to unzip a file and run the startup script.

In contrast to Tomcat, WebSphere requires a product named the IBM Installation Manager to be installed first, after which updates to the IBM Installation Manager must be downloaded and installed. After the IBM Installation Manager is updated, new patches to the IBM Installation Manager must be applied.

The IBM Installation Manager then takes care of the IBM JDK installation, product licensing and finally the WebSphere Application Server binaries installation. The WebSphere Application Server installation itself typically requires several reboots because the IBM Installation Manager applies subsequent patches and fix-packs.

It should be noted that there is value to the overhead of the IBM Installation Manager. By orchestrating the installation of a variety of IBM and WebSphere tools, it has the ability to ensure that products are installed in a manner that maintains comparability between them, while ensuring patches that address feature, performance and security issues are applied before the software goes into use.

A Tomcat installation can be performed in minutes. A WebSphere Application Server installation that requires patches and fix-packs would be difficult to perform in under an hour.

Tomcat vs. WebSphere Application Server support

Perhaps the biggest difference between WebSphere and Tomcat is the fact that while Tomcat is an open source project managed by the Apache Software Foundation, the WebSphere Application Server is a commercial product backed by IBM. This tends to be the key differentiating factor between the two when it comes to product adoption.

Established organizations such as banks, governments, insurance companies and the like — especially ones who already have a working relationship with IBM — like the security and peace of mind that comes with a server that is backed by one of the largest software services companies in the world. Furthermore, organizations who already have IBM support contracts in place can often negotiate favorable WebSphere pricing terms, such as bundling product support hours with existing services contracts.

There’s an old saying that when things go wrong, it’s good to have a single throat to choke. In more polite terms, there is value in purchasing IT infrastructure components from a single, established vendor. As such, many organizations that use WebSphere-branded software also use other IBM products such as DB2 and MQSeries. As such, the customer can take advantage of the vendor’s expert knowledge on how to integrate all the systems together.

There are vendors who specialize in Apache Tomcat support, such as Tomitribe, Payara and others. However, they have nowhere near the name recognition of IBM.

Tomcat vs. WebSphere performance comparison

One of the biggest complaints leveled at the WebSphere Application Server is its massive thirst for resources.

A traditional WebSphere Application Server download exceeds 2 GB in size. A JVM profiler such as Java Mission Control shows that a bare-bones WebSphere installation process will consume half a GB to 1 GB in memory. Furthermore, the need to load a massive number of files into memory for the server to run has a negative impact on startup times.

These issues are somewhat trivial when WebSphere is deployed onto powerful servers that rarely need a reboot. But for modern, microservices-based architectures, or even for developers that work with a WebSphere installation on their local machines, the resource consumption is problematic.

Compared to WebSphere, Tomcat’s resource requirements are minimal. Tomcat can be compressed into a file that is less than ten MB in size, and a running server with only the default applications deployed would never consume more than 100 MB of RAM. It’s probably not a surprise to hear many WebSphere developers test locally against Tomcat or TomEE installations and only test on WebSphere for quality assurance or pre-production validation.

Tomcat’s small installation size and minimal memory footprint make it ideal for microservice deployments and hosting RESTful web services, although organizations really focused on startup-time and performance often prefer the Eclipse-based Java application server Jetty.

In terms of performance, both Tomcat and WebSphere can be clustered for both high availability and increased throughput. With a clustered configuration, there isn’t a difference between the two servers when it comes to capacity planning. However, WebSphere will consume a greater amount of memory and file system resources to handle a comparable number of requests.

Tomcat vs. WebSphere: Which server to choose?

As you can see, when it comes to comparing enterprise Java tools, the Apache Tomcat vs WebSphere Application Server comparison reveals greatest disparities. While the open source community maintains Tomcat, WebSphere Application Server development and support is provided by IBM. While Tomcat can be installed quickly, a WebSphere installation is more involved. While the Tomcat binaries are small in size, WebSphere is a substantial download. The two products couldn’t be more different. So which Java application server should you choose?

Typically WebSphere is the right choice for companies that have a working relationship with IBM, are happy with an existing suite of IBM products, and anticipate the need for ongoing software and services support from IBM to not only help with their infrastructure, but also to develop applications destined to be deployed to WebSphere. For these types of organization, the traditional WebSphere Application Server is the right choice.

For smaller organizations that lack the rich IT budgets of banks, governments and insurance companies, and ongoing software support isn’t a priority, choosing Apache Tomcat versus IBM WebSphere is probably a more sustainable long-term option.