Migrating a J2EE application: Tomcat to Websphere
A piece of cake, you say! But think again. Much of the hype and sales pitch behind J2EE applications has been centered around the fact that they are portable across platforms. Here is how the theory goes. If you build a application to run on a specification and if that specification is used as a standard then any platform that supports the specification should be able to run an application built to that specification. This sounds logical and simple enough. Yet it is difficult to port J2EE applications across all of the major vendors or application servers without an exception. Yes, without an exception!There are a number of reasons for this. They include:
1 - vendors providing features and functionality over and above what a specification provides for
2 - specifications not being comprehensive in their scope. This results in only parts of an application being portable.
3 - platforms conforming to a specification sometimes run on older versions of virtual machines, operating systems or hardware and negating true portability
4 - developers writing code that is inherently non-portable. For example making use of system properties increases the chance that applications will be non-portable.
The bottom line is that firms investing in J2EE technologies do not receive all the potential value they might receive from using a technology. It therefore imperative for a any development effort to account for potential portability issues and try to mitigate them.
I use a case from a recent client to illustrate my point. The source application was built and deployed on a Tomcat application server. It has a three tiered architecture, with a web front end and a database. The client had acquired the application as part of an acquisition and sought to migrate it to the corporate standard, which was IBM's Websphere Application server.
A number of issues were faced during this process. These included:
1 - Exceptions during deployment
2 - JVM mismatch errors
3 - Classpath exceptions during runtime
4 - Library mismatches
5 - Suboptimal performance
While these problems seem straightforward to resolve to an experienced developer, they are not necessarily so. For example, the latest versions of the Websphere Application Server, come packaged with a verification and deployment tool. This tool seeks to prevent unstable applications from being loaded onto the application server. It attempts to verify that the deployment descriptors and the application descriptors conform to the relevant J2EE specification. If it does not however, the tool just gives up and displays an exception that is very user-unfriendly to say the least. To resolve these problems I had to import the descriptors into a XML utility and fix the descriptor files to make them comply completely with the schema.
The second problem was caused by a JVM mismatch. A JVM mismatch??!!! No that can't be. I agree, it should not be. The source application had been compiled on a later version of the java compiler and was being deployed to a target application server that ran on an older version of the java runtime. This caused the runtime to handle the version mismatch most ungracefully. On the bright side though, we have learned something, a good rule of thumb, compile on earlier and deploy on later versions.
The third issue is well known. Libraries that are packaged within a war file may be picked up by one application server but totally ignored by another. The root of this problem stems from how application servers load their classes. Different application servers load their resources differently and at times via different classloaders. This causes numerous headaches for an inexperienced J2EE programmer. Fortunately, the Websphere application server allows the administrator to specify additional classpaths that allows such problems to be ironed out.
The third error is the most difficult to resolve. This is especially so when the target application server has multiple applications running on it that are dependent on the older versions of the libraries. It now no longer is a process of simply updating the libraries. One needs to perform a dependency analysis to ensure that no other applications will be broken by changing one or more of the libraries.
Finally, migrating an application from one application server to another can deteriorate performance. There are a number of factors that can cause this. The source application may be tuned to one application server and that optimization may be counterproductive on the target. For example the manner in which caching, thread synchronization and pooling is done on different application servers does vary and consequently the performance on them varies too. Furthermore some application servers come with JVMs that are tuned to provide a high performance with them. A sub-optimal configuration can degrade performance significantly.
Migration of a J2EE application from one application server to another is therefore a very complex task. It can however, be achieved with adequate planning and the use of skilled resources.
(c) 2005 Vivek Pinto For more details please visit us at Wonomi Technologies
posted by vivek pinto @ 4:21 PM
0 Comments:
Post a Comment
<< Home