Migrating JEE Applications to Apache Tomcat: Deciding to Move Forward

posted by avanabs on May 24, 2010 03:07 PM

I’ve been researching one of the most interesting trends in IT development and deployment architectures; the migration of development/deployment architectures from JEE Application Servers to light weight JAVA containers. Many IT organizations have been 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, more importantly, the need to transition to more responsive/agile applications development. When we hear IT organizations talk about “migrating” their applications, they generally are focusing on one or more of three distinct situations. These are:

• Migrating existing applications. Moving existing applications (or slices of applications) off of their commercial JEE servers and onto lightweight, modular, horizontally scalable container infrastructures. This trend has been accelerating, particularly with the emergence of JAVA frameworks that replace the “only a computer scientist could love” JEE standards with far more productive (and performant) technologies.
• Extending existing applications and services. Expanding access to existing JEE applications by adding services layers in lightweight containers. This is an even more important trend, which gained significant momentum when IT consulting firms went SOA crazy back in the mid 2000’s. Even without the overheads and complexity of SOA products (from many of the same folks that brought us JEE) the idea of horizontally scaled distributed services is an excellent one. Even where JEE servers maintain their hold on the “back office” business systems, the trend is to convert them to service providers, enabling far more flexible and agile development.
• New development on better architecture. Transitioning new development away from JEE application servers and focusing on light weight containers. Let’s face it, JEE was just plain hard. It required writing lots of redundant (and mostly unneeded) structure and learning to use overly complex interfaces. Today’s JAVA frameworks offer most of the useful power of JEE, with code sizes running as much as 50% smaller, dramatic increases in developer productivity, and in most case significant performance improvements.

In the next few blogs, I'll be focusing on the migration of existing JEE applications to the most popular of the light weight containers, Apache Tomcat. There are many excellent reasons to consider moving applications off of commercial JEE servers sold by Oracle/BEA, IBM, etc. While we are concentrating on the JEE to Tomcat migration process, many of the business and technical decision factors apply equally well to the second and third situations and many IT organizations are doing some/all of them in parallel.

There are multiple steps in the JEE to Tomcat application migration process. These are:

• Migration Strategy. Deciding whether to migrate applications, determining the strategy for migration of your applications, and criteria for selecting appropriate migration targets, including determining risks and costs
• Migration of Application Code. Moving the selected application code to Apache Tomcat, plus adding whatever services the application requires that are not part of  Tomcat
• Adding “enterprise class” management. Optionally, upgrading application deployment, management, monitoring, and tuning processes to one of the emerging commercial application management products that are built on top of Tomcat.

Initially, we’ll focus on some Migration Strategy processes for determining whether to migrate your applications or portions of your applications from commercial JEE servers to Apache Tomcat. Many of these decisions will be based on business factors, although there are also significant technical opportunities and challenges to address. Experience has shown that the projects that work best are those where application owners (business units), development, and operations collaborate in the decision process.

Why Even Consider Migrating a Working Application?

Perhaps the most important question to resolve is “why would you even consider migrating a working, successful, application?” With all of the demands on today’s IT organizations, “if it works, don’t mess with it” surely applies. Additionally, there are many good reasons that today’s JEE Application Servers occupy many hundreds of mega-bytes of system space and cost tens of thousands of dollars, including highly integrated feature sets, very powerful application services, and sophisticated management tools.

While there are certainly valid reasons to leave well enough alone, there are also a number of reasons that IT organizations are deciding to migrate applications from one of the commercial JEE application servers (Oracle/BEA, IBM, etc) to Apache Tomcat. In this context, the term “application” includes complete applications, portions of an application, or functional modules/layers (“services”) which make up an application. I'll be discussing those reasons, a processes to determine a migration strategy, and how to select viable migration targets.

In most cases, migration of JEE applications is not an “all or nothing” process, so a standardized way to select specific migration targets is a valuable tool. Often times migration decisions will be motivated by long term strategic objectives, such as architecture and operating cost reduction plans, but occasionally there is an immediate tactical challenge that can best be met by careful migration.

In one recent case, a consumer facing financial services application running on largely IBM WebSphere was becoming seriously overloaded at critical times of the day. A creative developer decided to understand why this was happening and discovered almost 85% of the processor time was being consumed by a single JAVA service. By abstracting that service (took less than a month) and migrating it to a highly parallel Tomcat deployment, the company avoided purchasing multiple new licenses of WAS, saving hundreds of thousands of dollars in equipment, licensing, and operating (mostly maintenance contracts) costs. In this example, the application was “no longer working” (e.g. not meeting it’s service requirements), so something had to be done fairly quickly, but the brute force approach of purchasing additional costly JEE application server instances was avoided.

In another company, a recent investigation of a large scale application determined that it was almost 100% servlet code, with some utilization of data persistence, and it was hosted in a WLS cluster configuration. Most of the code transported to Tomcat seamlessly, plus adding OpenSource Hibernate technology to deal with the data. This resulted in an annual maintenance contract savings of almost $200,000, an excellent return on the three man months the migration project took.

In future blogs, I’ll be exploring some more of the reasons that organizations migrate from JEE to Tomcat, as well as the costs and problems associated with this migration. We’ll also get into the technologies involved, and provide a summary of differences between Tomcat and a commercial JEE application server.

Andy has recently decided to make the jump from individual consulting to join the Spring Source team. He will continue to be working with major clients to assist them with IT architecture evolution, now as a member of a large and growing organization. His first project will be leveraging Tomcat, Spring, and a Tomcat based data grid/cache called GemFire. He’s looking forward to sharing the lessons learned with the tomcatexpert community. Andy has been architecting, designing, and building enterprise infrastructure and applications software for most of his career. He’s been responsible for BEA’s “Blended Source” initiative, combining the best of Open Source (including both Tomcat and Spring) with WebLogic, BEA’s WebLogic Enterprise Security product family, MEI Software’s financial systems, Netegrity’s SiteMinder security product, Camex’s electronic publishing systems, mainframe applications for Bell Telephone, and many others. During that time his hands on technology experience has ranged from octal coding into neon lighted switches all the way through JAVA and beyond, including many generations of “the best and final thing we will ever need”, and he looks forward to working on the even better things coming in the future. He was involved in the early days of Open Source software as a contributor to EMACS and refocused on Open Source during his tenure as Director of Product Management with BEA Systems, combined with a fascination for the rapidly evolving application deployment architectures and technologies driving today’s development. Andy has provided architecture and technology guidance for both vendors and IT organizations and he shares what he is learning through consulting services and through his web site, Enterprise Software Trends (www.estrends.com).