Geertjan's Blog

  • April 15, 2005

Migrating Applications Between Servers

Geertjan Wielenga
Product Manager
I occasionally teach English here in Prague. Just recently, I've been teaching the phrasal verb "to dawn on". Well, here's a great application of that verb: "It suddenly dawned on me that even though Ant-integration in NetBeans IDE 4.1 (and 4.0) enables you to integrate as many servers into the IDE as your Ant skills and server-knowledge allow (see previous blog entries), that does not mean that you can simply deploy any application wherever you want without going through a painful migration process." (Okay, so it's a rather long and unwieldy sentence. I guess I won't use it as an example in my next English class.) In this article, it appears that Ajit Sagar had a similar dawning, after thinking it would all be a piece of proverbial cake (and he's only talking about migrating from one version of a server to another):

...I couldn't have been more mistaken. The migration was a big deal. After working on a few of these projects, I can verify that the amount of moving parts in a machine composed of various portfolios, frameworks, third-party vendors, and a variety of stakeholders made the planning for such an initiative a formidable undertaking.

That's actually a pretty interesting article. Anyway, so it dawned on me that, on the lowest level, for example, the Sun Java System Application Server has a sun-application.xml file and JBoss has the jboss.xml file (and that all of these servers have one or more server-specific files that need to be migrated). Until this dawning of realisation, I had thought that the only question one would need to ask is whether a server supports a particular specification (e.g., J2EE 1.4) or not. So, even if you're dealing with two application servers that support J2EE 1.4, that does not mean that you're home and dry as soon as you've created Ant scripts and hooked them up to menus inside NetBeans IDE 4.1 (as I've been doing in my recent blog entries). For example, click here to see a recipe for frustration.

So you can imagine how happy I was to discover the Migration Tool for the Sun Java System Application Server 8 Download! Here's a nice summary of the various issues involved (taken from a 110-page document called "Moving from WebSphere Server 4.0 to the Sun™ ONE Application Server 7", which I found on the aforementioned Migration Tool's whitepaper site, and which, according to its summary, only "provides an overview"):

J2EE Application Migration Issues

The varying degrees of compliance to J2EE standards can make migrating applications from one
application server to another a daunting task. Some of the challenges when migrating J2EE
applications are:

  • Differences in interpretation and implementation of the J2EE API by the various application
    server vendors.

  • Difference in the J2EE specification level implemented by the source and target application

  • Ambiguity about what J2EE technology-compliant means (usually, this means the application
    server has J2EE technology-compliant features, not code-level compatibility with the J2EE

  • The number of vendor-supplied extensions to the J2EE standards in use, which differ in
    deployment methods and reduce portability of Java code. Differences in clustering, load
    balancing, and failover implementations among application servers are sparsely documented,
    creating an even bigger challenge to the migration process.

  • Lack of knowledge about the implementation details of a given J2EE application.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.