Apache Tomcat and IBM Websphere application server are two vastly different products that nevertheless often come up in the same conversations.
In this article, we'll take at some of the places where the functionalities of these two application servers overlap, as well as some ways in which they are different, to help you decide which is the best choice for your scenario.
Tomcat vs. Websphere
Originally developed and released around the same time in the late 1990s, and originating from the same Java Servlet specification, Apache Tomcat and Websphere Application Server, or WAS, have grown in two entirely different directions. While Tomcat has remained a lightweight, open-source servlet container, Websphere has become a large stack-based application server, one part of a larger group of interoperating IBM products under the same brand, including IDEs, portal services, data integration engines and more.
When it comes to architecture decisions, there's plenty of opinion to go around. This can confuse people who are looking for a clear, balanced analysis. The Tomcat versus Websphere conversation can get longwinded, but much of the discussion can be boiled down to a few central questions:
Let's unpack each of these points.
Tomcat Vs. Websphere - What is an application server?
At one time, it would have been easy to describe the difference between Websphere and Tomcat by saying that Websphere was an application server, whereas Tomcat was just a servlet container. Let's take a moment to define those terms from a rigid technical perspective before we look at how their definitions are shifting.
What is a Java EE application server
From a technical Java perspective, a Java Application Server is any implementation of the Java EE Application Server specification that fully complies with and supports all Java EE features. These features extend the standard Java platform for use in internet-based business transactions, and include things such as JTA, EJBs, JMS, JSF, and Java EE APIs for session persistence, dependency injection, and more.
In versions of Java before Java 6, in order to call itself a Java EE Application Server, a server must implement all aspects of the Java EE platform. While this is changing thanks to the concept of profiles in Java 6, this is a slow process. Java EE servers deploy applications using the EAR (Enterprise Archive) format, which contain one or multiple WAR files, associated EJBs, JSP pages, servlets, and even resource adapters. This packages is deployed into a single container, so that its classes and resources can be loaded and managed separately.
Additionally, most commercial application servers (including Websphere and its direct competitors, such as Weblogic) include extensive management and monitoring tooling, as well as a family of additional products that integrate with them and provide additional functionalities for a fee.
What is a servlet container
By contrast, a servlet container only needs to implement the Java Servlet and JSP specifications, which deal with the container-managed deployment of web applications, as well as associated transactions.
The servlet specification, which is part of the Java EE platform, includes the use of WAR application files, JSP pages, connectors, JNDI resources, and more, which means that a servlet container can do many of the same things that a web application server can.
In fact, the servlet specification covers so many important web technologies that embedded versions of Tomcat are used as the web and servlet container for many commercial application servers.
The changing landscape of enterprise Java
At surface value, the distinction between Websphere and Tomcat seems simple - one supports the necessary components to run business applications, and one does not. However, recent changes in the world of enterprise Java have complicated this simple evaluation.
For a long time, a major distinction between Tomcat and fully featured Java EE servers was support for Enterprise Java Beans. These specialized Java objects provided a way of encapsulating business logic within a single container, providing support for advanced functions such as session persistence, JMS events, JCE, concurrency, and JTA. However, a few major changes have eliminated this distinction in many cases.
The first was the evolution, first using OpenEJB, and then as specified in Java EE 6, of high performance, embeddable EJB containers. Tomcat and other servlet containers can now handle EJBs simply by using the free OpenEJB plugin. Looking back at the list of differentiators for web servers from servlet containers, we now see that many items have been eliminated, including big items such as JMS, JTA, JPA, JavaMail, and more.
The second major shift was the rise of third party Java software frameworks such as Spring, Seam, Hibernate, Grails, Guice, JRuby on Rails. These frameworks provide methods of easily achieving many of the same things made possible by Java EE features such as EJBs, without the requirement of a full application server. Some of these networks were developed in part to address gaps and frustrations with the EJB and Java EE specifications, which were slow to provide features desired by developers working within an increasingly agile-minded industry.
Lastly, and perhaps most importantly, with the release of Java EE 6, many issues and gaps that made frameworks such as Spring and Hibernate so attractive have been addressed at a native level within the Java framework itself. Recognizing that different situations call for different levels of server complexity, the new release made many of its components modular, as well as creating a new process by which various "profiles" could be proposed through new JSRs, allowing for lighter versions of Java EE Containers to still be considered Java EE compliant. As the Java EE 6 adoption process continues, building business applications designed for lightweight environments and better performance will continue to become easier and easier.
Application servers and servlet containers - Summing it up
To sum it all up, while at one time Websphere and Tomcat would have been strongly differentiated by the Java technologies they supported, new developments in the Java landscape have brought Tomcat closer to Websphere in terms of Java functionality. Value differentiations between the two products are now increasingly centered around other factors.
Simplicity, flexibility, performance and value
As we demonstrated in the last section, the boundaries between servlet containers and application servers have become increasingly blurry in the last few years. A skilled team of architects and developers could feasibly develop a Tomcat-based infrastructure that would provide functionalities mirroring many of those offered by Websphere using frameworks, extensions, and custom tooling. If the technology is not a firm boundary, what are the other factors differentiating Websphere from Tomcat? It all comes down to the best solution for the job.
Picking the right solution for your needs
Ultimately, the choice between Websphere and Tomcat is a choice between two different kinds of risks.
When you host your applications on Websphere, you're choosing a set of known risks, including potentially prohibitive expense, high performance overhead, a single vendor to contract with, and some degree of platform lock-in. When you take on these known risks, you hope to gain a number of benefits in return, including a well-known platform with proven stability, a large set of GUI administration tools, and a contract that includes service assurances.
When you host your applications on Tomcat, you're choosing a solution that could help you to avoid all the risks of choosing Websphere, as well as offer you some additional potential benefits, such as lower costs, faster performance, lower overhead, greater developer flexibility/productivity, and agile positioning.
However, while some of the benefits of hosting your application on Websphere, such as administrative tools and stability, can also become benefits of a Tomcat infrastructure, others, such as the support of a major vendor, or assurance of service, will be harder to attain, and some of them, such as the ability to purchase all of your services from a single vendor, will be close to impossible to recoup. Additionally, you could potentially be shouldering one or more of the following risks: the need to produce your own documentation, the need to assemble a custom architecture from various components, and the need to support your own infrastructure, or purchase support.
Why, if there are so many unknowns, do so many (over 60%) of all Java-based sites run on Tomcat? The answer is that for the majority of developers, the benefits of running Tomcat, such as the freedom to use the IDE of their choice, rather than Websphere's proprietary IDEs, the fast server restart times which save hours and hours in development, and the flexibility to expand the network in the manner that they see as most beneficial to their use case, rather than following Websphere best practice, outweigh both the risks associated with a Tomcat-based infrastructure and the positives of basing a site on Websphere.
The fact of the matter is that the vast majority of web applications do not require most of the features that Websphere offers, nor do they need the additional "added value" differentiators of brand name or reputation. They need a simple, high-performance, low-cost infrastructure that scales well, never breaks, and can grow with their company. In a large number of cases, a well-designed Tomcat infrastructure can meet all these needs.
Often, the only problem area is graphical tooling and group administrative provisions, which a company may not want to develop themselves. Fortunately, the popularity of Tomcat has led to solutions such as Tcat, which provide intuitive, lightweight enterprise-ready management capabilities to enable administration of large Tomcat infrastructures for companies that do not want to build their own tooling.
Now that we've discussed the technical aspects of the Websphere versus Tomcat debate, let's turn to a more pragmatic issue: price.
Price and licensing
All technical differences aside, one of the biggest reasons why Tomcat and Websphere come up in the same discussions is that Websphere is an astronomically expensive proprietary product, and Tomcat is free and open source.
Both Tomcat and Websphere have been used extensively with high success in mission-critical infrastructure roles, and although they go about it in completely different ways, the functionality they offer overlaps in many places. So the fact that utilizing one proven product will require thousands of dollars of initial investment, along with a yearly subscription fee, while using the other will only be as expensive as the hardware to run it and the developer hours to configure it naturally becomes a major factor in the decision making process.
Since 2006, IBM has determined the cost of a Websphere license using a metric they created called Processor Value Units, or PVUs. PVUs are a way for IBM to express the perceived power of a given CPU. For example, a quad-core CPU would have more PVUs than a single core. For every 100 PVUs, another Websphere license must be purchased.
While this model ostensibly is designed to give users more flexibility and reduce costs by allowing a site that requires a large number of weaker CPUs to pay the same amount as a site that uses a small number of powerful multi-core CPUs, it can result in some truly staggering license fees. Powerful CPUs can end up costing companies over $100,000 in licensing fees alone (that is, not including the actual cost of the equipment, or the energy costs, or the A/C bill, or the Websphere support fees).
The huge initial investment required to get a Websphere infrastructure off the ground is a major factor in generating what is known as "vendor lock-in" - when a company feels bound to continue using a specific vendor's software, or buy that company's integrated extension products instead of a competitor's, simply because they have already invested so much money into that vendor's products.
There are two ways to think about this phenomenon. A huge, very wealthy company might like the fact that they can get all of their solutions from a single, familiar vendor - for them, the high price is simply the cost of using a well-established solution, and if they ever did need to migrate to a different service, they'd have the cash to finance the move. On the other hand, a much greater number of companies would view a vendor lock-in scenario as detrimental, not just from a cost standpoint, but from an operations standpoint as well.
Reasons why a company might consider vendor lock-in extremely undesirable include a need to keep operating costs down by always using the most efficient software on the market, a need for fast expansion with limited funds, which could be made difficult if every new CPU represented thousands of dollars of licensing fees, or ease-of-development concerns, which we discuss in more depth in a later section of this article.
The Tomcat option
In contrast to all these cost concerns, Tomcat comes out looking pretty good. Free, lightweight, and simple, yet powerful, efficient, and proven in both production and development environments, Tomcat is an example of a simple thing done right, that in turn becomes a building block for much more complex things. When considered by the kind of companies we discussed in the last section, for whom expensive vendor lock-in is a big undesirable, Tomcat stands out for a number of reasons.
For companies that are just starting out, and are unsure of how much complexity their architecture will require in the future, Tomcat is a safe bet because it allows them to get a very stable iteration of their infrastructure up and running for a very small initial investment. This leaves them plenty of breathing room to expand their network as needed, either by paying developers and architects to build a lightweight custom Tomcat-based solution precisely matched to their needs, which can be expanded in response to the company's growth, or even just by saving them enough money that it's possible to migrate to a proprietary solution if their company reaches a stage where this is the most prudent decision.
For companies who are loaded with developers who like to use the latest and greatest in technology, a Tomcat-based infrastructure can mean that there's enough money left over to try out other products, and because Tomcat is so widely adopted, it's often very simple to integrate that work into the existing network if it proves successful. Avoiding the weight of massive annual license charges is important for these companies to maintain the sense that they are agile and will be able to respond to changes in the marketplace without making money the default deciding factor.
Summing it up
The takeaway from the Tomcat vs. Websphere price discussion is that as a free, open-source project, Tomcat has a distinct and obvious price advantage over Websphere in most situations. However, this advantage is complicated on a situation by situation basis, depending on both a company's actual technical needs and the expectations of its clients.
It's important to remember that even perceived difficulties, without any verification, can have an important role in pushing a customer to shell out big bucks for a stack versus designing their own Tomcat-based architecture.
In other words, sitting down and actually outlining your assets, needs, and wants as a company is vital when choosing your application server solution.
Tcat - Enabling enterprise Tomcat infrastructures
Tcat is enterprise Tomcat made simple. Built with unmodified Apache Tomcat, the world's most popular Java application server, Tcat adds key enterprise features not included in the official distribution, including:
- Continuous deployment of applications to multiple servers or clusters from with a single click.
- Easy, no-mess server configuration - create your server profiles once, and apply them to new servers with the push of a button. Deep diagnostics, reliable restart, and more. All this functionality and more, accessible from an intuitive central web console.
Try Tcat today!