Last fall, software provider Hyperic started on a release plan that by all accounts is a major shift in infrastructure by migrating their EJB layer to Spring 3.0 and their internal server to Apache Tomcat. Originally built in 2002, and released as open source in 2006, the Hyperic software, a web infrastructure monitoring and management application, helps some of the largest web shops in the world monitor and manage their production web applications. For any well established software, such a fundemental change to the application architecture is surely not a decision that was made lightly.
The obvious answer is to follow the proven mantra of eating your own dog food. In 2009, Hyperic was acquired by SpringSource, who has significant investment in both their flagship product Spring and the Apache Tomcat, through their commercial distribution of Tomcat, vFabric tc Server, and the number of Tomcat committers and experts employed directly by the company. By adopting the "company standards", they have better access to engineering support and follow software best practices of using their products just like their customers do.
However, with such an established code base and number of production customers, a shift of this magnitude is bound to delay the development of new features and potentially bug fixes, which are critical improvements needed to keep customers happy. This type of a decision therefore needs to translate quickly into financial or customer benefit.
So why the change? The answer is the Hyperic engineering team wanted to move towards lean software development, a system of development processes popular with the Agile development community. The result of the move would allow future development and bug fixes of the product to happen more quickly through simpler configuration, reduced code complexity, decreased application start time, and faster debugging process which improves the maintainability, testibility, and reliability and their Hyperic HQ 4.5 software, which was released this month. In essence, a temporary delay on a stable product release would quickly pay dividends to their development costs and ultimately provide faster development of features for their customers.
For more information on the rationale, and a detailed walk through of the migration itself, check out the complete webinar that Hyperic technical lead, Jennifer Hickey originally delivered at the SpringOne 2GX conference held in Chicago in October. A link to an audio recording of her presentation with her original slides can be found in the Knowledge Based section of the Tomcat Community here: Hyperic's Migration to Spring and Apache Tomcat Case Study presentation.
![]()
Jennifer Hickey of SpringSource presents a Case Study of migrating Hyperic from EJB to Spring.
You will need quicktime to play the video.
![]()
Jennifer Hickey of SpringSource presents a Case Study of migrating Hyperic from EJB to Spring. From the 2010 SpringOne 2GX conference.
This case study on migrating the web application monitoring and management software, Hyperic, to the Spring Framework and Apache Tomcat was originally delivered by Jennifer Hickey at the 2010 SpringOne 2GX conference.
I’ve been sharing some thoughts about what’s become a significant trend in many IT organizations, and in particular with my clients…converting Java applications from JEE Application Servers to Tomcat, and more typically Tomcat+add-ons.
Many IT organizations are re-thinking their commitment to commercial JEE Application Servers, due to both challenging business environments that drive the need for more cost effective application architectures and the need to transition to more responsive/agile applications development. When IT organizations talk about “migrating” their applications, I’ve noted that they generally are focusing on one or more of three distinct situations. These are:
I’ve been focusing on the migration of existing JEE applications to the most popular of the light weight containers, Tomcat. There are many excellent reasons to consider moving applications off of the commercial JEE servers sold by Oracle/BEA, IBM, etc. While we are focusing on the migration process, many of the business and technical decision factors apply equally well to the second and third situations.
This time, I will be discussing the technologies involved in migrating JEE application code from commercial JEE servers to Tomcat. I’d like to thank the kind (and very expert) folks at SpringSource, as well as a number of other friends around the industry, for their valuable insight regarding the technologies involved. Any errors (and opinions) are mine alone. Additionally, some of the material draws on information published by SpringSource and other open source materials found on the internet.
Popular Links