SpringSource tcServer - The Tomcat You Know, The Enterprise Capabilities You Need
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 2nd 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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)