Filip is a Senior Software Engineer for SpringSource and a key participant in the company’s Apache Tomcat initiatives. Filip has extensive experience working in the architecture, design and development of distributed application frameworks and containers and is recognized for his top-quality system development skills and continuous participation of open source development projects. Filip is an active committer to the Apache Tomcat project and a member of the Apache Software Foundation (ASF) where he is a leading authority on Tomcat clustering and author of the Hitch-Hikers Guide to Tomcat. Prior to SpringSource, Filip worked as a Senior Software Engineer at Covalent Technologies which SpringSource acquired in early 2008. Previously, Filip was a Senior Software Engineer/Architect for La Quinta Corporation. Filip has made contributions to software initiatives for, Sony Music, France Telecom and has held a variety of senior software engineering positions with VRP Consulting, Pakana Corporation,, Extrico Data AB, IRIS Data AB, and SEBA Data AB. Filip received his education at Chalmers University of Technology in Gothenburg, Sweden where he majored in Computer Science and Computer Engineering. Filip has posted 1 posts at DZone. View Full User Profile

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

  • submit to reddit
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 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.

Published at DZone with permission of its author, Filip Hanik.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Otengi Miloskov replied on Thu, 2009/04/30 - 4:31pm

Geez I missed this article anyway it is late my comment but the SpringSource people does not get it yet. Andrew way to go with your comments, This put in their place to this Spring people. Every time SpringSource talk or launch a solution everytime I want to go more far from them. It is a shame.

Oliver Plohmann replied on Thu, 2010/09/16 - 9:41am

earlier: tomcat.jar + spring.jar = Tomcat with Spring

today: spring.tomcat.jar = Spring

 These Spring guys do this with anybody else as well and then tell folks that it is all Spring. I wonder how long it takes till people get mad at this.


Carla Brian replied on Fri, 2012/06/22 - 8:31pm

EJB covers a lot of territory, and without first understanding the basic concepts involved, code snippets and programming tricks are meaningless.  - CWD Construction

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.