SpringSource tcServer - The Tomcat You Know, The Enterprise Capabilities You Need
Comparing Tomcat with a JEE server makes Tomcat look very bleak:
For a sales person – it would have a very limited feature set to use as selling points
For a developer – it implements a very limited set of technologies
For a system administrator – it lacks many of the bells and whistles that commercial vendors have for production support
Of these comparison points, it's the first two that have made Tomcat such a popular platform.
Less is more
During a meeting with a CTO, in the process of migrating from a commercial JEE platform to a more cost friendly solution, I was told that he only had one primary concern regarding the cost of the platform. To my surprise, it was not the cost of acquiring the technology solution, it was the cost of migrating away from it. Acquiring a new technology solution has a known cost factor, that can be calculated before making the decision. The cost of keeping the technology and possible trying to move away from it becomes the unknown factor. When managing long term cost, it is a natural move to choose an application server like Tomcat. An application running on Tomcat is almost guaranteed to run on any other application server. Adding complexity turns out to be easier and cheaper than removing it.
Lacking the coolness factor didn't stop developers, who adopted Tomcat before it became a popular application server for production environments. It turned out that productivity increased, solutions became simpler, easier to maintain and more efficient than the ones that had previously been developed.
Gratification from a well performing, on time and under budget application is as, if not more, satisfying than playing around with technologies that sound enticing.
Similar advancements of choosing simple technologies over complex have become a de facto standard in the development industry. The Spring framework is possibly one of the more prominent examples. Feedback from developers has been that combining frameworks like Spring and Tomcat, simplifies software development, especially for larger, more complex projects.
If there is princess, then there has to be a pea. According to the tale, The Princess and the Pea, written by the Danish poet Hans Christian Andersen, only a princess would be so sensitive that she would have to endure a sleepless night due to a single pea under a layer of 20 mattresses.
One doesn't have to be a princess to realize that Tomcat doesn't measure up to all the needs of a deployed application server in production. The pea is pretty obvious. A savvy Unix administrator accustomed to text based configuration files and with a good knowledge of the TCP stack implementation fares fairly well with Tomcat. Small install, a few configuration tweaks and launch the server. It works well in smaller environments with a few dozen instances running.
Trying to accomplish the same thing in a larger server farms means the administrator has to develop a custom framework to handle these installations. If configuration changes are required the management framework will have to expanded to handle these changes for existing instances.
I have had the fortune to be able to work with numerous operations teams, and be a part of hundreds of different Tomcat installations and environments. All of them share a few common challenges and solutions.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)