Migration / Portability among Application Servers

Lot of time we tend to think that write once and run anywhere is true in case of Java EE applications also as in case of Java. Java EE is a wonderful spec and it has made life easy with respect to portability of the application and made the world for client vendor independent. 

But in practice its not so. In any case the approach of migration the following things we need to take care even if we port the application using some tool like https://migrate2glassfish.dev.java.net/:

• What are the custom things they used in the Deployment Descriptors of the Applications like application variables etc..
• What are the Application Server specific things that are used in application
• Version of Java & Java EE they used in building application
• IDE they used while building application -- 
• Some IDEs have built in-oprtabilities for generation of the Application server specific deployment descriptors.
• Version of the IDE they used for developing the application
• Portability / interoperability of the IDEs -- NetBeans supports importing of the projects developed in eclipse / JBuilder. So once we import the project and make some environmental modifications we should able to generate the stuff req. using NetBeans itself.
• If they have used just plain Ant script also we can import the project into NetBeans / eclipse and we need to do a bit of R&D after the application is imported since it would not be directly interpreted as Web/Enterprise project rather as just Ant based project.
• Have they used any Startup Classes -- This would be Application Server specific. For eg. GlassFish uses LifeCycleModules where as WebLogic has different way of doing the same.
• Have they used any JMS related things -- 
• They might be using some Message Server specific jars. 
• And some times Vendor specific APIs for accessing. 
• Also in other case like MSMQ kind of stuff is used application might be using some Native API.
• What are the external systems the applications are connecting to
• If this is just JDBC there would not be any issue
• If they are connecting to any other external system -- What are the standards they are using like JCA etc..
• In above case we need to port the JCA adapter too to the WLS -- Also this might have been provided by vendor and might have been under some licensing area.. we might have to know about this.
• Are these applications using any other Libraries either Open-Source or Vendor supplied -- If they are using
• Licensing terms and conditions
• Way by which they are deployed and configured -- this might be application server specific 
• What are all configured at JNDI level w.r.t. resources -- Their configuration settings. Tuning for these parameters differ in different application servers.
• Any tuning that has been done to Application w.r.t. 
• JVM -- Version and other details
• Application Server specific
• Which Database they are currently using in the project and the tuning thats been done on Database. -- This would have effect on JTA support and sometimes might effect porting. 
• Sizing details of the Application Servers and the QOS details -- Current Performance details -- premises for the same -- because different  application servers differently. For achieving the same QOS we need to have the bench marking correctly.
• Any serialization & Externalization they used in the projects.
• What is the current server form architecture (Deployment Architecture) -- so that we can evaluate.
• If they are using WebServices which kind of stack they are using. Some kind of tokens / infra might not be supported by All the application servers. 

If we take care of above things most of the things would be taken care. 

SOA based stuff becomes I see become more platform dependent because of the product reasons and becomes even more tougher than Java EE based things because of the following reasons to list a few:

• All the servers do not comply to same standards-- For eg. JBI - JCA etc..
• All the files that are generated even in case of BPEL where there is a standard there are portability issues since lot of time there are vendor specific extensions
• All the external system adaptors are also compliant since again vendor specific extensions
• Security provisioning is also not portable because of different degrees of implementation and extension
• Governance is specific to each of the plat form with different kinds of features etc..

That way SOA based product interoperability is rather non existent.