Releasing a new product into one of the worst economic climates ever would generally be considered a bad move, but for SpringSource it may prove a master stroke. Recently they announced that early next year (Jan/Feb) version 1.0 of tc Server, a fully supported, business-friendly edition of Tomcat 6.0, will be available. For those in the Java world Tomcat is the first port of call when developing or deploying web applications. This is because it is free (open source), lightweight and relatively easy to use compared to the Java application server competition; JBoss, GlassFish, WebLogic and WebSphere.
Unfortunately when compared to alternatives Tomcat has never been as well supported in the role of mission critical, business server. JBoss does support Tomcat so that it can fulfill the role of servlet engine for their application server, but most will acknowledge the two are quite different beasts. Other companies ship Tomcat as part of their products, for example Novell and Alfresco, but in these cases support is of a token nature and generally extends only to how the company's own software runs within it. So in this cloudy support and economic environment it is easy to see why SpringSource is moving to offer a supported, business-friendly edition of Tomcat.
Why is the inferior Tomcat better than the competition?
Without significant marketing Tomcat has become more prevalent than its competition through simplicity and availability. Compared to alternatives it has managed to stay trim and easy to use by staying clear of all the inherit complexities of the Java EE specification. Instead the development team has focused on being the best Java servlet/JSP container, and let adoption handle itself.
For those not versed in Java understanding the difference between Tomcat and a full blooded Java EE server is a challenge. In a nutshell Tomcat focuses on a small, but significant, portion of the specification, for example it does not internally implement JMS messaging, web services or persistence (EJB). This does not mean similar functionality cannot be added to Tomcat, but as a developer it must be assumed these things are not present. This may seem like a drawback but it has proven to be advantageous given the torrid history of Java EE, which only recently has delivered promised developer productivity benefits. In the meantime Tomcat-compatible frameworks such as Spring, Hibernate, Axis and CXF have emerged which embody many of the practical characteristics of Java EE without the complexity. So whilst Tomcat cannot claim to be a full-blown application server, it can for most purposes practically act like one.
If Tomcat is so good why do businesses need SpringSource?
Tomcat is used extensively in business today but the general level of expertise available in the market is limited. This can partly be attributed to the excellent job Tomcat developers do in shipping a production quality product. Unfortunately there is a significant step up between using Tomcat at a small scale and having it run business critical applications 24/7. Attaining this level requires a significant investment in time by the internal I.T. department, or migration to a fully supported application server like the ones referred to earlier. SpringSource are aiming to provide a third alternative by packaging their experience in Tomcat performance optimisation, management, clustering and monitoring into an easy to use and well supported product. The benefit of this is that businesses can continue to rely upon their existing Tomcat investment without having to commit significant internal resources, or worse, migrate to a different application server platform.
How are SpringSource delivering on this?
In recent months SpringSource have announced two separate (but related) products, tc Server and dm Server. In a nutshell tc Server is does not change Tomcat, whilst dm Server is a heavily modified, OSGi compatible variation that solves the long running problem of JAR hell.
Okay you lost me, OSGi and JAR what?
Unlike .Net the Java web platform is not dominated by a single, all powerful company such as Microsoft. Sun certainly exerts control over the Java language, but the majority of commonly used libraries are contributed by third parties, either working independently, or towards an agreed upon specification (JSR). This distributed lineage has created a complicated dependency problem often referred to as JAR hell. This is where applications or third-party code requires similar, but incompatible library files. Not only does this complicate development but it also causes serious headaches when it comes to deployment.
To combat this problem three initiatives have emerged which are functionality similar to Ruby's gem or Linux's apt package management. The first, Maven is a tool-set that goes a long way towards resolving a developer's immediate issues. In the long-term Sun is undertaking Project Jigsaw which will hopefully become an integral part of Java 7. In the meantime to address problems in production environments the OSGi Alliance has developed a framework for library management. IBM, Oracle, Sun and JBoss all plan or have implemented OSGi support, whilst SpringSource's dm Server is the first derivative of Tomcat to support it.
The problem with OSGi is that it requires considerable changes to the way applications are developed and deployed. As a result whilst OSGi seems the obvious long-term answer, most businesses are more interested in deploying their existing, non-OSGi compliant applications. Given this landscape SpringSource's strategy is to gain immediate market share with the conventional tc Server, and then be in a position to capture a share of the OSGi market with dm Server.
What is the secret "source" in tc Server?
It is very difficult to sell support for a single open source project that has a strong community like Tomcat's. Generally commercial support is only perceived as valuable if it covers a range of projects (Red Hat), or the company has a single, controlling stake in the future of the project (Alfresco). If neither of these conditions are met then the business must provide an extra layer of valuable functionality. SpringSource are not breaking this rule, and plan to add the following to their Tomcat distribution:
Performance patches and tuning
Parts of Tomcat are quite conservative and rather old. SpringSource are significant Tomcat contributors and have developed patches to address less performant parts of the code. Added to this their experience has given them unique insight into how Tomcat can be tuned to operate at peak efficiency during various demanding scenarios.
Server and Cluster management interfaces
The Tomcat development team has never invested serious time in tools that ease server or cluster management. A basic administration tool does come with Tomcat, but it is one of the first things deleted given its limited functionality. SpringSource are aiming to rectify this with a set of management tools that ease setup and configuration of standalone or clustered Tomcat instances. Versioned configuration and scheduled changes are planned, but whether this will be available in the 1.0 release is uncertain.
The Application Monitoring Suite (AMS)
Prior to tc Server, SpringSource developed the Application Monitoring Suite, a Spring-centric monitoring and analytics system built on top of Hyperic. In practical-terms it allows developers and system administrators to monitor a running Spring application at a very low level. The suite takes all the guesswork out of troubleshooting and can automatically respond to, or alert others of, events within the system.
SpringSource intend to leverage this comprehensive monitoring tool-set during tc Server support incidents. Anyone that has tried to remotely troubleshoot a Tomcat problem will understand what an edge this gives the SpringSource engineers. As a consequence businesses will feel comfortable their support requests can be efficiently addressed, even if the engineer is on another continent.
From an operations perspective having monitoring built-in to tc Server is a great time and resource saver. For many monitoring is one of those New Year's resolutions that never quite eventuates. However once in place the statistics generated are invaluable, and the peace of mind knowing everything is working within defined parameters lets everyone sleep easy at night.
What will this cost?
Whilst the final price has not been confirmed, this blog post suggests tc Server will be priced at US$500 per CPU per year. This is no doubt the base price and different support-tiers and discounts will be factored into the mix at release. If $500 is correct then this would appear to be a very good deal considering the functionality delivered and the cost of competing Java application servers. Plus from a cost/benefit standpoint businesses would not need to invest in an in-house Tomcat expert, or undertake a complicated migration to a completely foreign, but supported, server platform. Hence once these costs are factored in it may well turn out that adopting tc Server actually saves the company money over the long-term.
If SpringSource can execute they could win big
These recent Tomcat-based server announcements are shaping up to be very compelling product offerings. Given the changing face of the Java application server landscape and SpringSource's reputation, both tc and dm Server stand strong chances of success. What is really interesting to watch is key pieces of a long-term strategy fall into place. Spring has captured a significant amount of developer mind-share and their Application Monitoring Suite illustrated they are serious about production environments. It would seem these new servers are building on these strong foundations, and in the process turning SpringSource from small-time developer of tools into a serious competitor within the Java application server marketplace.
For more information on SpringSource tc Server checkout this webinar.