SpringSource tcServer - The Tomcat You Know, The Enterprise Capabilities You Need

I still remember the day I first evaluated Enterprise Java Beans (EJB). It was in late 1998 and we were considering switching to Weblogic to take advantage of an already existing application server to host our business logic. This was the first implementation of EJB 1.0 that we were introduced to.

We had developed an application server in-house built on top of CORBA, and we had learned the lessons of remote object invocation performance and scalability the hard way. Our application server has been optimized to serve the business needs and it was doing well but the time to maintain and upkeep our own implementation became a hindrance when trying to focus on business logic. So we ventured out into the unknown.

You can imagine our disappointment when we realized both the conceptual flaws of the EJB specification and the irony of the fact that we had bypassed them all in our proprietary implementation.

In 1999 I started to use Tomcat as an alternate application platform. By 2001 I was using it so much that I contributed enough to become a committer on the project itself and since then I have never looked back. In retrospect it has been interesting to evaluate the reasoning behind, and the outcome of, that decision.

When a standard comes out, especially from an organization like the JCP that is backed by large companies such as Sun Microsystems, IBM, BEA and others, as a developer one would expect that the engineers, with their vast amounts of experience, would have done their homework, and the specification itself would steer one away from complexity towards a well performing solution. Operating under those assumptions have proven to be a costly mistake for many organizations.

In an ideal world, solutions are implemented using the KISS principle; a principle I was not familiar with back then, but it must have been ingrained in my spine for I did never use Enterprise Java Beans and some other JEE technologies in the way the specification promoted them. I did, however, work in several projects that did, and the code base became large, complex and often did not meet the performance needs of the business.

The JEE specification today contains many interesting and advanced technologies. Various vendors have managed to create impressive and well engineered implementations of these technologies. Making a technology available to a development team doesn't guide the team to the optimal solution. Couple this with software sales that are often based on a feature list comparison with the competitors products and you end up paying for technology you don't need. Looking into almost any software company you also realize that the real money is often in the maintenance contracts and not in the initial sale. The more complex solution I create, the more technologies I decide to use in my solution, the better for the software vendor providing the maintenance contract.

I'll never forget the day a developer in my team was tasked to provide a utility class to easily send an email with an attachment. A week later, about 4 more days than anyone had anticipated for the task, we received an Enterprise Archive (EAR) containing the solution. As a consumer of this library one had to open a remote connection to a JNDI library, get a handle to an EJB and invoke the EJB method. The EJB would send a message to a JMS queue which was picked up by a message driven EJB that in turn invoked the javax.mail library and sent the email. Of course the JMS queue was configured to be persistent in a RDBMS, so we had to configure a JDBC data source. The EJB was transactional, so we managed to fit JTA into the mix as well.

What I learned was that development teams during the era of J2EE/JEE:

• often structure their solutions around the technologies that are available

• have a tendency to try to use as many technologies as possible

• when choosing technologies are driven by

  • the desire to try out new technologies while still learning them

  • being able to document the skills on their resumes

While my example seems to trivial and over engineered, even ridiculous, it is an exaggeration of common mistakes of over engineered solutions that represent many applications running in today's production environments.

We are in the 2^nd recession in the last 8 years, a fairly bumpy ride for the economy, and companies are forced to take a deeper look into what their software solutions actually cost. By software solution we encapsulate the whole system life cycle, not just license costs, but cost to develop, cost to deploy, cost to run and cost to maintain and so forth. Its time to look at solutions that not only solve the problem, but also do it within budget.

More companies are turning to Apache Tomcat, a lightweight Java application server and an open source implementation of the Servlet and the JSP specifications. It provides a platform for web applications, also known as Web Archives or WAR files. Tomcat is not a JEE server and hence does not implement many of the JEE specifications.

Tomcat, with its very small download footprint of 6MB, has been around for a decade. It was donated to the Apache Software Foundation in 1999 where it for a long time served as the reference implementation to the Servlet and JSP specifications. Back then it was common for developers to use Tomcat as a development platform while production deployment used a commercial JEE server. That has changed. Today, Tomcat is the most popular application server in the market.

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.

Typical Tomcat installations today have:

• Custom installation methods

• Custom management and configuration solutions

• Custom monitoring tools

Another obstacle is the JVM itself. It is seen as a big black box often misconstrued as being part of Tomcat itself, after all, that is how most commercial JEE servers ship their products in an attempt to simplify the system to the end user.

If you are using or are planning on using Tomcat today, you are, or soon will be, faced with these challenges. What may seem like basic functionality, always assumed to be present with an application server stack, has long been missing, and there are no plans to add it. These challenges are real and have not, until today, been been addressed with an enterprise solution.

Springsource tc Server  is a new offering addressing the need for enterprise capabilities in large or small Tomcat installations, completing the feature set that has been missing for so many years

Based on Apache Tomcat 6, tc Server is able to leverage the simplistic Tomcat approach that so many have benefited from with the addition of the a key enterprise feature set including:

• Centralized application and server management console

• Distributed server configurations

• Intelligent and proactive server diagnostics

• Enterprise class support

A key differentiation between Tomcat and other Java application servers, is that Tomcat is very light weight. One side effect mentioned was the download size, however the most important factor is that there are less moving parts within the server itself inevitable leading to less things that can go wrong. 9 out of 10 times, when we troubleshoot Tomcat environments, we end focusing on the OS/JVM, the web application or the combination of the two.

In January and February we will be touring cities in both Europe and the US sharing our knowledge and experiences around enterprise Tomcat installations. We are calling this the Apache Tomcat Expert Series  where we will be focusing our sessions on production usage, scalability and performance in enterprise environments. In these sessions we will presenting some of the tricks of the trade that you can use in your Apache Tomcat environments today. Features that will also be automated in the Springsource tc Server platform to further ease and simplify enterprise production deployments.

If you have the opportunity, we invite you to join us during the expert series tour. Until then, stay tuned for part II of the Tomcat you know, the enterprise capabilities you need.