Types of migration issues

When ever, you are trying to move a J2EE application across vendor platforms, we usually run up many issues. I have listed down, some of the high level issues that crop up when doing this kind of migration.

Application uses vendor-specific services.

Some vendor-specific services provide proprietary features that may be critical to your application. In this case, you will probably have to do some redesign to obtain the desired result, possibly becoming dependent on another vendor’s services.

Older applications may be using vendor-specific services simply because that was the only service available when the application was written. As the J2EE specification evolves, some of these cases have become standardized. A migration project is a good time to upgrade to the newer specification. Since you will have to make a change anyway, why not move
toward the current J2EE standard?

Application uses J2EE standards, but still contains non-portable code.

It is possible to use the J2EE standard and still write non-portable code. For example, the JDBC APIs provide many opportunities to embed vendor-specific strings, for example, table names and database types. An EntityBean with bean managed persistence could therefore easily be no portable. For this case, we may recommend the use of the Enterprise JavaBeans environment services in conjunction with more portable JDBC APIs. Use good judgment and good programming practice to make these decisions.

J2EE support is partial or differs between server products.

The J2EE specification is a moving target and vendor support is bound to lag behind the latest standard. Although your application may be running on a J2EE-compliant server, loopholes in the J2EE implementation may expose migration issues. In some cases, the J2EE specification has been interpreted differently. Since it is difficult to predict these migration issues, we rely on experimentation to identify them. In these cases, we try to guide you in the direction of the latest J2EE specifications to avoid future problems.

Vendors support different versions of the J2EE specification.

It is relatively easy to identify these migration issues by reviewing the relevant J2EE specifications. We are faced with the fact that the one vendor supports Enterprise JavaBeans 1.1 while the target system supports Enterprise JavaBeans 1.0. This impacts both Java code and deployment descriptors. For each of these migration issues, we try to preserve as much of the EnterpriseJavaBeans 1.1 class=GramE>code as possible, to facilitate future updates to Enterprise JavaBeans 1.1. These migration issues are generally localized and well-defined, making the use of automation attractive.

Vendors provide needed services that are not yet covered by the J2EE specification.

The J2EE specification does not cover all situations. The J2EE 1.4 and Enterprise JavaBeans 2.0 draft specifications provide clues for future directions, and vendor might be supporting these in some format.