Table of Contents

1. Overview
2. Examining Migration Objectives: Why Migrate a Java EE Application?
   2.1 Reduce Complexity
   2.2 Reduce Operating Costs
3. Examining Java EE Application Migration Targets
4. Confirming Migration Ability
   4.1 Techniques for Determining Migration Suitability
5. Identifying the Tomcat Version Matching your Websphere Version

 

1. Overview

While it has been commonplace (and well documented) for IT organizations to migrate Java EE applications initially developed on Apache Tomcat upward to commercial Java application servers, such as IBM’s WebSphere, in recent years the trend has been reversing. There are a number of compelling reasons for creating new web applications using today’s deployment architectures on Tomcat instead of WebSphere, but perhaps even more interesting is the trend to migrate existing Java EE applications from WebSphere to Tomcat.

In this white paper, we explore the reasons for migrating from WebSphere to Tomcat, considerations for making the decision, and techniques to be followed for a successful migration. Note that when we talk about Java EE applications, we are including applications, application components, and SOA service instances, each of which is an “application,” even when the user is another service or application, rather than a human.

When we are discussing “migration,” we are focusing on those applications that would transition from WebSphere to Tomcat without major re-architecture or re-write. While it is theoretically possible to move any application from WebSphere to Tomcat, those involving sophisticated transactionality (EJB or CORBA, for example) would require so much development effort that they should be considered a completely new application, not a migration.

While there is no single process for determining migration requirements and strategy, this white paper describes steps that can be used to make a migration decision and successfully implement it. The steps typically include:

  • Examine migration objectives: determine the reasons for the migration program. These may include business needs, cost savings, technical/architectural objectives, etc.
  • Examine migration targets: identify those Java EE applications with migration potential based on meeting the above objectives.
  • Confirm migration ability: assure that the selected Java EE applications can be migrated from WebSphere to Tomcat. This step will typically involve code analysis, trial migration, etc. Watch in particular for the use of “hidden services”... portions of WebSphere “auto-magically” used by your Java EE application without explicit developer activity. Also important would be considering any WebSphere or third-party administrative tools used by IT staff, which might not be available for or compatible with Tomcat.
  • Identify external services: Determine those services external to Tomcat that may be needed, factoring in costs to provide those services.
  • Convert code: convert selected Java EE applications to Tomcat, coding as required and migrating administrative/deployment/management tooling as required.

 

2. Examining Migration Objectives: Why Migrate a Java EE Application?

This is the first, and probably most important, question to ask, particularly when you already have a stable running Java EE application on WebSphere and there will be both costs and risks associated with making the changes. There may be a number of answers to this question, including the need to expand capacity, reduce IT systems complexity, retire WebSphere licenses due to vendor changes or to reduce overhead, and to reduece ongoing costs.

2.1. Reduce Complexity

Another frequent objective for migration is to reduce the complexity of the IT environments. While WebSphere is extremely powerful, it is also very complicated, both to program and to administer. Today’s IT budgets require “do more with less” processes and staffing, making it difficult to sustain such server environments.

Developer productivity is also somewhat higher with Tomcat, particularly for those applications that do not require the complexity of WebSphere. Whereas a Java developer may take days to set up and configure instances of WebSphere, they can often do this in hours or even minutes for Tomcat. During development/debugging, Tomcat can be stopped and re-started (“bounced”) in a few seconds, rather than the minutes required each time by WebSphere. In one study, this impacted developer productivity by more than an hour per day.

Also driving complexity reduction is the need for IT agility. Whereas business applications used to take years to develop and deploy, business requirements now demand applications in weeks/months. This requirement drives architectural and process changes, including a transition to a more horizontal, lighter-weight, more modular deployment architecture. WebSphere is both too costly and too heavyweight to meet these requirements.

2.2. Reduce Operating Costs

Maintaining WebSphere is very costly, not the least because of the vendors service contract pricing, but also because of the amount of hardware required to support a WebSphere instance and the associated space/power/cooling costs. With typical Tomcat operating costs/server coming in at 1/4 to 1/6 the cost of WebSphere, many IT organizations are investing in transitioning all possible web applications from WebSphere to Tomcat, reserving their WebSphere servers for Java EE applications that require EJB or other major Java EE facilities that Tomcat does not offer.

 

3. Examining Java EE Application Migration Targets

Selecting suitable Java EE applications for migration is an important step. Typically, it depends on the objectives from above, some educated guesswork regarding what applications might be suitable for migration, and some thoughts about cost savings. With multiple interacting factors in play, this is typically a somewhat iterative process. For example, migrating a specific application might achieve business objectives, but upon detailed analysis, it might prove to be too highly integrated into WebSphere services that are not available in Tomcat and too costly/complex to provide as a separate Java process or separate add-on Java component.

There are three general types of applications for which Tomcat is highly suitable. These are:

  1. Any web application that has primarily been developed using Tomcat during development and is currently running on WebSphere in production.
  2. User interface (GUI), including sophisticated dynamic interfaces with features like user-specific content, forms validation, etc.
  3. Application components (including SOA services), particularly those requiring highly horizontal scaling and non-demanding business logic.

Evolutionary changes in application architectures have made lightweight Java containers an increasingly viable environment for today’s enterprise applications, particularly those using service oriented architectures based on Web Services standards. Increasingly, IT organizations are de-composing huge vertical legacy applications running on mega-servers into collections of more horizontal application components (Web Services, etc.) running on lightweight, low-cost servers. They are also encapsulating legacy systems in Web Services to enable a ‘building block” approach to future dynamic IT requirements. In both cases, migrating portions of the application from the WebSphere server to Tomcat provides operational efficiencies and improves IT agility.

Where architectural changes are the motivating driver, you must still take a close look at both the costs and the details of the migration process. In some cases, portions of the existing application code can be readily split off, but often new code has to be written to glue the results together. Targets of opportunity in a conversion would include portions of the code that have to horizontally scale but that do not require sophisticated services. User interface code is one typical area to focus on, plus application components doing large volumes of relatively simple things.

 

4. Confirming Migration Ability

The next step in assessing migration is to determine whether the functionality used by the application requires a WebSphere server or whether it can be supported by Tomcat, perhaps with a small number of add-on application services. Studies have shown that in most cases, only very small portions of the WebSphere functionality actually was used in any one Java EE application. While having everything you’d ever need at hand in every server instance was convenient, it was also complex and highly costly, both in acquisition cost and ongoing maintenance.

In some cases, the Java EE application from WebSphere will use one or more services not present in the Tomcat server. These may include data access/persistence, messaging, e-mail, etc. In these cases, the selected application services must be installed and configured, and typically the Java EE application code would be changed to use those specific third-party services.

4.1 Techniques for Determining Migration Suitability

With the differences between WebSphere and Tomcat in mind and suitable Java EE applications targeted for migration, we can turn to the migration process itself. There are several steps involved in the migration, starting with determining that the selected applications do not require services that will be missing in the Tomcat environment.

You may use the following checklist to decide if your application can move from WebSphere to Tomcat:

Factor

Migrate to Tomcat?

Next Steps

Application has been developed using Tomcat as runtime during development

Yes

Determine configuration and deployment changes

Application primarily uses servlets and/or JSPs

Yes

Check if app leverages any WebSphere-specific services and identify their equivalent replacements for Tomcat

Application uses Spring Framework

Yes

Determine configuration and deployment changes

Application is written to be strictly standards-compliant

Yes

Determine if other Java EE technologies are used and identify equivalent replacements for Tomcat

Application is third-party software that is also available for Tomcat

Yes

Obtain the Tomcat version of the web application and deploy it on Tomcat

Application uses EJB or other WebSphere server functionality not readily available for Tomcat

No

Need code refactoring to remove the use of such functionality. This is a “new application,” not a migration.

An easy way to do a trial migration is to move the selected web application, perhaps stubbing out those previously noted sections, to Tomcat. This effort is primarily a configuration and deployment exercise and will be described in more detail below. At this stage, it is fairly rare for the web application to function fully, unless the original developers were meticulous in assuring portability. Typically, a short debugging session either will result in a basically running web application or will surface previously unknown reasons that the web application will not readily migrate.

Once the web application is basically running, it is extremely useful to be able to use the same test suites and tooling used to maintain the original WebSphere-based application. Although these are third-party tools, they are almost always Tomcat compatible and typically ship on Tomcat by default. Where WebSphere monitoring and debugging tools have been leveraged, there are no comparable capabilities included in Tomcat, so either third-party tooling or commercialized versions of Tomcat which include monitoring/debugging/administration functions must be used. This is typically the most frustrating and time-consuming part of the migration process, because WebSphere offers a rich suite, and the open source Tomcat does not include these features.

 

5. Identifying the Tomcat Version Matching your Websphere Version

There are several different major versions of WebSphere in use today, each implementing different versions of the Java ServletJSP, and other specifications. There are at least as many versions of Tomcat, implementing matching versions of these specifications, or being compatible with them. This section identifies the WebSphere major version and its corresponding Tomcat major version, and shows which versions of the specifications were in use at the time these application servers were released.

WebSphere Version

Specifications and their Versions

Equivalent Tomcat Version

8.0

Servlet 3.0, JSP 2.2, JSF 2.0, Java 1.6

Tomcat 7

CE 2.1.x and 2.2.x

Servlet 2.5, JSP 2.1, JSF 1.2, Java 1.6

Tomcat 6 or higher

7.0

Servlet 2.5, JSP 2.1, JSF 1.2, Java 1.6

Tomcat 6 or higher

6.1

Servlet 2.4, JSP 2.0, JSF 1.1, Java 1.5

Tomcat 5.5 or Tomcat 6

6.0

Servlet 2.4, JSP 2.0, JSF 1.1, Java 1.4

Tomcat 5.5 or Tomcat 6

5.1

Servlet 2.3, JSP 1.2, (no JSF), Java 1.4

Tomcat 4.1

Note that Tomcat 6 requires Java 1.5 or higher, and Tomcat 7 requires Java 1.6 or higher.

Recommended for you

Download tcat

Download

Related Articles