Tomcat is more than enough to deploy most of the mid-end web applications without any problem but for the high-end applications which require high scalability and high availability, which might need some tune-ups with the support of expertise in this regard. Otherwise, you may realize numerous performance issues, memory leaks, server crashes etc.
Red Hat JBoss Enterprise Application Platform (JBoss EAP) is well suited for deploying high transaction Java EE based applications. It supports many popular Java EE web-based frameworks such as Spring, Angular JS, jQuery Mobile, and Google Web Toolkit.
MOD_CLUSTER integration. JBoss EAP integrates pretty well with mod_cluster. This is an intelligent load balancer especially useful in highly clustered environments.
Supports enterprise-grade features such as high availability clustering, distributed caching, messaging etc.
Supports deployment in on-premise, virtual and hybrid cloud environments.
tomcat is just part of the J2EE specification implementation, majorly focusing on the servlet (front-end) part. If you requires the full J2ee stack, like EJB support, you need consider other containers like Weblogic
tomcat's cluster level support is very limited
tomcat's admin/configuration is not so intuitive, and default logging needs a lot of improvement
Jboss CLI is a great tool but we had trouble using it to get values that are displayed on Jboss GUI. It also has limitations parsing the applications.xml files and we had to use a mix of jboss-cli and linux bash commands to automate certain application administrative tasks.
JBoss doesn't really provides performance tuning recommendations. It would have been nice if it could learn from the current demand vs current settings for things like connection pool, server configurations, garbage collection etc.
Tomcat has a very rich API set which allows us to implement our automation script to trigger the deployment, configure, stop and start Tomcat from the command line. In our projects, we embedded Tomcat in our Eclipse in all of the developer's machines so they could quickly verify their code with little effort, Azure Webapp has strong support for Tomcat so we could move our application to Azure cloud very easy. One drawback is Tomcat UI quite poorly features but we almost do not use it.
Tomcat doesn't have a built-in watchdog that ensures restart upon failure, so you have to provide it externally. A very good solution is java service wrapper. The community edition is able to restart Tomcat upon out of memories exceptions.
Tomcat support to customize memory used and allow us to define the Connection pool and thread pool to increase system performance and availability, Tomcat server itself consume very little memory and almost no footprint. We use Tomcat in our production environment which has up to thousands of concurrent users and it is stable and provides a quick response.
Commercial application servers are available that support enterprise application needs, but many times this is overkill for most web applications running in the cloud, particularly for independent software vendors. The capabilities and management tools provided with these applications are superior to Tomcat, but most times unnecessary for the vast majority of web applications developed in Java.
WebSphere Application Server is propriety and increases project cost. It is slightly complicated to learn when compared to Jboss EAP. These were the two main reasons why we chose Red Hat JBoss EAP over WebSphere Application Server. Also, JBoss EAP is light weight and requires less server resource
It has simplified administration efforts, thus saving much time to focus on other projects and issues.
It saves us in costs, as there are no licensing requirements.
It gives us the ability to manage all of our java applets in one place, so as to be able to host both development and production systems on one server.
Jboss EAP is easy to deploy and configure. This lead to lower cost and faster delivery.
Even though we have large number of machines running JBoss, we have only two Jboss Administrators. It doesn't requires too much administration and maintenance on daily basis and reduces number of administrators required for large implementations.
