Tomcat started out as the reference implementation for the Servlet specification and eventually also the JSP specification. It became the container that you validated your application against. If it ran on Tomcat, it ran on all the other containers as well. Tomcat through its history then remained very lightweight. As these containers kept growing, kept adding features, kept essentially growing both in size and resource consumption, Tomcat went the other way.
So Tomcat never used to be the fastest container and never used to be the best container, but the focus was always on stability, simplicity and to keep the container and the core of the container very focused on what it was supposed to do, which is run easily. I think a lot of organizations bought into the idea that you do need the whole kit and caboodle when it comes to J2EE. It turned out that in those organizations, the developers were always using Tomcat because it started up so fast, it was so easy to work with, and they knew that if they developed on Tomcat they could deploy it into a commercial server later.
That is one of the reasons. The other part would be the licensing around it as well. The Apache license is one of the more generous software licenses that essentially doesn't hold you as liable. For an organization, there never has to be question of "Do we allow this license or not within our organization?" The Apache license is one of the first licenses to be approved by legal saying "Yes, that one is absolutely fine".
The popularity with developers was always big and what we are seeing now is that the popularity among operations is growing, in the same pace developers did 5-6 years ago it's growing today with Apache Tomcat. And that is operations teams saying "Well, we're running this in our development environment and sometimes in our test environments; we can cut cost by implementing Tomcat in our production environments as well.
2. How does Tomcat compare with other lightweight containers like Jetty?
Jetty is also a great little servlet container. It's lightweight, it's gained a huge popularity in embedded containers. It does have a little bit of a more flexible API, a simpler API for embedding it. I think the big differentiator with Jetty is not feature sets or performance. I think all these containers are pushing the boundaries of network and CPUs today, that we don't really see big gaps like "my container is 40% faster than your container". Those numbers don't exist. I think they are pretty much similar and they are pushing all the same boundaries.
With Jetty I think the difference is essentially the community around it. Jetty has been developed by a group of developers that essentially have taken control of it - "This is our product, this was our product to begin with." Apache Tomcat has been slightly different. Different in the way that Tomcat developers have gone through generations of developers. Some of the people that were there when it began are no longer there and we've gone through cycles of developers coming in and out of the project and helping out.
So that project has always kept around and I think it's been more of why Tomcat became more popular [than] Jetty was not really a feature result, but more of like we know the Apache software foundation, we know what's behind it, we know how it works, we know it's never going to deviate from it's original goals and policies. It is a very trustable organization, it's safe to go with as a corporate entity that you say "Can I actually get software from this place?"
3. What does Spring's tc Server provide on top of the base Tomcat distribution?
tc Server is not really a new concept. The idea comes from we want to provide Enterprise level support. We want to be able to provide a customer with the SLAs they can count on and also a name brand of a vendor that you can trust in your production environments. I think tc Server has a few feature sets that are definitely preferred over Apache Tomcat. What's interesting is that those features do exist in Apache Tomcat as well.
We talk a lot about how we lay out an installation of tc Server on the file system, that a runtime instance is separated from the binary installation. Well this is a feature of Apache Tomcat, it's just that we realize that feature within our deployment model. For developers, this is great. It means I can create a sample instance, I can zip it up and in 50 K or less I can email you and say "Drop this into your installation and you will have my configurations". I don't have to zip up a large binary installation or move huge files around. tc Server provides us with the ability of giving a customer security fixes, bug fixes, updates, new features in a way that is unique and doesn't exist in any other container.
Imagine the scenario where you are actually running 5 different applications. You've decided you want to run those in 5 different VMs, so that you can keep a separate setup and run those all off the same binary. We no longer will give you a single jar file and say "Replace your old file". The minute we do that, we lose track of what changes you actually have in your production environment. We will always give you a complete Tomcat installation that you drop in, and you can have as many installations as you want. They all run parallel and you tell your runtime instance "Use version 6.0.20" or 6.0.21 or any updates in between.
Now as you can switch over one application, because that's the one you QA'd for this version, that was the one that needed the bug fix, the other applications are not affected. Then, of course, there is the support. The support which we always provided for a very long time now, but essentially having a very shallow support organization - 2 levels. You have a senior support engineers team, and then you have the engineers behind the products themselves. We do this with all of our products as we always back the support with a line of engineers that are very keen on helping the customers; that are also out there every day working with customers. I think this is unique to our organization - we do get a lot of real world experience.
4. How are additional monitoring capabilities added into the tc Server distribution?
That is one of the interesting parts. There are a lot of blogs out there and tweets and all kinds of social networking feeds that talk about what tc Server is and the fact that it's not building off of a binary distribution, and what are the other components such as monitoring fit into the whole scheme of things. One of the things is that we can't build off of a binary distribution because then we can't provide our customers with a security patch in a timely manner. If we have an SLA of 48 hours, the customer will get an update in 48 hours. We can't wait for the Apache Software Foundation to say "We need a vote on this, we need to decide the best way to implement it" and so on.
All our fixes, all our contributions, are going back to the Apache Software Foundation and then it can take whatever time it takes there. The monitoring part comes with a toolset that we've got from Hyperic, which is a monitoring tool. The extensions - what we do to Tomcat is we don't change the core of it. We try to open up Tomcat by adding in new components. Tomcat in itself is very flexible. You can create custom components for almost any area of the container itself and that's exactly what we're doing. You can rip out all those through the configuration file and you have an exact Tomcat installation. What we do is we also make sure that that is an open API.
We try to leverage JMX as much as we can. If you don't want to use Hyperic or if you don't have your custom JMX pollers built on top of, for example, Nagios, or Big Brother, or some other framework, you will be able to get all that monitoring information out of the system as well. It's all about add-on components that can be added or removed, depending on how you want to configure your system.
5. Are the development cycles of Tomcat and tc Server related and how does tc Server influence Tomcat?
The development cycles are definitely not related. What we do though is that we follow Tomcat releases; if there is a Tomcat release, we'll make sure there is an update of tc Server that contains that release of Tomcat. Now we can do that because of the deployment methodology that we talked about before. We can drop in a new release, you choose when you are ready to use it. We never overwrite anything you have.
How do we influence the development of Apache Tomcat? I think it's a two-way street there - we take a lot of the great ideas of Tomcat, obviously Tomcat is a preferred platform. We are trying to keep as much of it as we can, but if we come up with good enhancements that could be usable to a fairly large user base out there, we add those in as contributions to the Apache community itself.
The community there can decide to reject any feature they want, if they don't find it useful, but if we find it useful, if our customers find it useful, there is a good chance that those features will work their way back into the code base. What is more to be said about that is that Apache Tomcat is still being developed under the rules of the Apache Software Foundation. Everything is based on general consensus and I think it's an important distinction that we don't really drive the development of Tomcat. We're part of that development community, and we act as part of that community accordingly.
6. What are the future plans for both Tomcat and tc Server?
The plans for Apache Tomcat are pretty straightforward. The servlet specification, Servlet 3.0, is imminent. We had a talk this morning about the new features in Servlet 3.0, and we did a deep dive into asynchronous request processing. That work is the main goal for Tomcat. That's what is going to become Tomcat 7.0, it is in development right now and that's where most of the activity is around. There has also been a fair amount of work on the embeddability of Tomcat.
What used to be a very clunky, fairly difficult API to work with has now become as mainstream as for example Jetty, where Jetty's biggest winner there was that there was no container that you could embed as easily as the Jetty container. Well Tomcat is getting there, it is a very valuable feature to developers.
Of tc Server, it continues to build on the value adds for Tomcat. We do see a large group of customers and users that are requesting, "We want to use Tomcat, for it's a preferred container and we want the support for it, but we also do want a little bit more of a toolset around it".
What I like of what SpringSource is doing, and we'll be able to do even more as VMWare, is we will be able to create much more integration between the different layers We'll be able to go from the SpringSource tool suite, which is the extended Eclipse that we offer with amazing features in there, and take that and apply that to tc Server. Being able to go through QA and production, and now you have management and monitoring added into it, and then extending that into support, and now being able to actually extract diagnostic data and help the customer with issues on a much faster scale than before.
The core component of tc Server will always be Tomcat, so whatever features Tomcat come up with, will be available on tc Server. One of the pitches I like to do for tc Server is that there is a compatibility guarantee there. If your applications run on tc Server, you can go to Apache Tomcat, if you are running on Apache Tomcat, you can go to tc Server, and we will guarantee that that will continue to be that way. We do like the idea of "Here is an Apache license product. If there is a shift in your organizational needs, you are able to make that shift without being tied in".