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.
In our experience, the product performs really well when interfacing systems with ERP's through SQL server database tables, but we've even made some interfaces with the web service functionality included with the magic xpi integration platform. Also, we've made some SAP Business One - SAP Business One interfaces, for copying information from one company to another and even between two different ERP systems.
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
Although the scenarios may be online, the main service usually freezes and the processes can't transact any data. With a single restart of the service, the processes will be functioning again.
The support for more applications would be nice, even though there is a nice number of them. Most of the main applications in the market are supported.
The licensing for the software may be a little confusing; you can't buy individual licenses as they come in packages of four.
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.
Honestly, we have only used and evaluated magic xpi/xpa platforms because of the recommendation of our SAP Business One main supplier, who has previously used the platform for their developments. So far, we have no regrets with the acquisition of the platform and we are very happy with its performance.
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.
The implementation time for this kind of projects has been greatly reduced.
Certifying an In-House resource in the Magix xpi and xpa platforms is probably the best option, considering all of the projects that can be developed in the future without the need of an external consultant.
The processes that have been automatized with the Magic xpi platform helped reduce human error and the time those processes took to finish.
