Migrating Applications Between Servers
By Geertjan on Apr 15, 2005
...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 servers.
- 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 specification).
- 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.