Migrating JEE Applications to Apache Tomcat: Planning the Migration

posted by avanabs on June 14, 2010 10:14 AM

In recent blogs, I've been discussing a major change in the IT server applications environment, specifically the transition away from last decades JEE Application Servers and "mega-blob" applications architectures. Increasingly, we see applications being assembled, leveraging collections of services...both local and remote, sometimes even very remotely in "the cloud" (more on that in future blogs).

This time I'll be talking about planning the migration process. Perhaps the most important step when considering migration of applications from one environment to another is planning. While our temptation is typically to jump in and start coding, it is critically important to understand the objectives and benefits, assess the risks and costs, and then make the business decision. Yup, it's a "business decision", mainly because migrating a running application from one infrastructure to another affects so many areas of the IT organization, plus it can impose risks for the users. There are many successful migration projects and one common characteristic I always find is that the up front planning process was completed and socialized before launching the actual project.

Planning the Migration Process

Most IT organizations considering migrating applications from JEE to light weight environments such as Tomcat will be focusing on a relatively small subset of their existing applications, at least initially. This is a very good idea because it provides the opportunity to take smaller steps and to assess the results incrementally. Do not underestimate the cost of the learning curve associated with any infrastructure changes.

In many cases, a low impact application, or one with reduced technical risk, is a better choice for early migration than to tackle a high visibility mission critical application. This allows us to understand the technologies, build an effective process, and create comfort on the part of management, development teams, and users alike. Unfortunately, in some cases the business needs are such that the IT organization does need to migrate a large JEE application. In that case it is critical to carefully plan the migration, take it step by step, and above all be realistic about the time and effort the migration may take. While it does happen that large scale complex applications migrate smoothly, they are rarely “plug and play”, even between JEE servers from various vendors, and virtually never when migrating to a different infrastructure, such as Tomcat.

Focus on the long term as well as the short term. Understand scope, complexity, and technical challenge. Migrating a codebase involves more than simple direct effort cost. Consider both legacy issues and expected new, “greenfield” development as part of the analysis.

Technology/Architecture Vision

It's really important for the cross function decision team to form a cohesive technology and architecture vision for the organization that addresses these factors:

• Migration criteria and process for legacy applications
• Best practice technology, architecture, and process for new development
• Application server (or in the case of Tomcat, additional services) licensing costs
• Cost of managing the new Tomcat environment, compared with the current JEE application servers
• Resource utilization, hardware, and environment (space, power, HVAC, etc) costs.
• Complexity and direct cost of migration effort, including, where code refactoring is needed, a thoughtful balance between “minimal effort” and “best practice” conversion. This is an area where migration costs can skyrocket, without corresponding benefit.

Don't Assume JEE Migration is Impossible

Fortunately, vendor and customer studies have shown that most applications actually only utilize a small portion of the suite of services provided by JEE Application Servers. This means that while the JEE application server infrastructure has all the capability to do practically everything for anybody (market forces drive this, with a very few extremely demanding customers driving the feature sets), they have become so huge and complicated that JEE Application Servers may not be a particularly good choice for any one application.

With Tomcat, you have to opportunity to select the add-on services you need and leave out all those you don’t need, significantly reducing complexity, cost, and computing overheads. Tomcat provides an excellent environment for today’s improved application environments, such as Spring.

Assessing Applications for Migration

Group candidate applications by the amount of refactoring effort. Assuming no specific external requirements or pressures, it is best to begin migration with those applications that require the least effort. Every company or individual will have their own criteria, but as an example, consider this grouping:

• Minimal effort
  • One day or less of work
  • Runs-as is (packaged as WAR, no use of unsupported APIs).
  • Testing effort only (but DO NOT underestimate this!)
• Low effort
  • Several days to two weeks of work
  • Few changes, plus testing effort
• High effort
  • Many weeks or months of work
  • Extensive changes to many/most modules, perhaps even to architecture

Minimal effort migration projects are relatively unusual (although they do happen, particularly in services architectures) for applications hosted on JEE servers, but it is also fairly common to discover a module/component that can be abstracted relatively easily and provide disproportionate benefit. Assess the level of effort in these areas:

• Java EE APIs used- This seriously raises the effort, but a remarkable number of the applications running on JEE Application Servers use no JEE API what-so-ever
• Third-party libraries- Many IT organizations have widely used libraries and frameworks on their JEE Application Servers, often associated with DBMS, links to business applications, etc. The good news is that many of these are supported on Tomcat...and frequently ship with Tomcat by default.
• Packaging- Typically, JEE Applications will have to be completely re-packaged for Tomcat. While Tomcat is in many ways simpler, it is also different., which can add a surprisingly large amount of effort
• Types and Number of Components- Sometimes the shear volume of working parts can seriously affect the migration effort, particularly for "mega-blob" applications.
• Code Quality Assessment- Initial code quality seriously affects migration, particularly factors such as coupling, layering, and so on.
• Maintenance and Manageability History- If the application was difficult to administer on a JEE server, this is frequently an indicator that the application is fragile, so your "migration" can become a "re-write". That may be a justified decision, but everyone involved should note the scope is beyond mere migration. I know one application being migrated from jBoss to Tomcat where the "re-write" requirement discovered during the initial migration assessment more than trippled the project scope.

Migration Complexity Factors

Several factors contribute to application migration complexity, when migrating applications from a full-stack Java EE environment to a Tomcat environment. The following table may be helpful in assessing the relative complexity. Your mileage may vary!

Once application targets are selected and the above analysis is completed, or at least well underway, it is time to rank the targeted applications by cost and benefit. As noted, some of these will be readily measurable, but many are not. In practice it is difficult to assign numeric values, but it is useful to organize the assessment into a comparison chart with best estimates for each task. Experience shows that it's not poor estimates that fracture project plans, but rather the things that never got estimated in the first place.

In my next blog, we will dig deeper into the technologies involved in the JEE Application Server to Tomcat migration process, including a fairly detailed (I hope) review of differences between JEE Application Servers and Tomcat regarding the JEE standards.

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).