During this phase, the project team does a complete analysis on the
differences between version 4.3 and version 5.1, especially on the application
logic layer. The project team can base on the documentation of the existing
application system to identify the part that can be migrated automatically
and the part that can not be migrated automatically and prepare what is necessary
for the migration. Do the following:
- Gather all the definition files of the existing application system version
4.3. In the migration tool, it can migration the definition files on the server
side from version 4.3 to version 5.1. The migration tool can process the tags
based on the specification of version 4.3. If there are any special tag definitions,
the migration tool might not be able to migrate it successfully or properly. For this situation, the project team needs to customize the migration
tool to extend the process to contain the special definition for the application
or do it manually later.
- The migration tool cannot migrate the business logic of the application
to version 5.1 directly. The tool just creates a skeleton with the name corresponding
to the server operation or the action in the flow. However, you can make extensions
on the migration tool to move the business logic to the generated code automatically.
The project team must do an investigation to check whether it is worth or
not to extend the migration tool to add more functions.
- For the integrity, do not customize the migration process on the part
of the screen flow generation. The business flow generation and the version
5.1 tooling artifact generation.
- The project team must package the application into a jar file and then
copies the jar file into the plug-in directory of the migration tool and modifies
the plug-in.xml to include the library because the migration tool refers to
the applications when it does the migration.
- Because the migration tool can migration the non-step server operation
to a Single Action EJB or a Business Process, the project team must separate
the definition files and the application jar into different sets if the application
will be migrated to have both set. The migration tool allows you to create
multiple projects to migrate different sets of applications.
- The supported services in the server side leave JDBC Table Service and
Electronic Journal Service, and the SNA LU0/6.2 communication services are
changed to JCA connectors, the project team must find the substitutive solution
(or implement a new service based on the new service architecture) for these
unsupported services. For example, Lotus Notes(R) support, LDAP support,
MQ connector, the relevant JCA connector. The migration tool can migrate the
server side service definition by modifying the class information regarding
the services that supported in BTT 5.1. The migration tool also modifies the
DummyDB2Journal.
- The event mechanism is changed to fit version 5.1 framework to be distributable
and span different server. The project team must check and modify the application
accordingly if the event mechanism is adopted in the server side in the current
application system.
- For the client application, there is no change. The project team does
not need to migration it to version 5.1. The only thing is to verify the migrating
invoker and the related property files to check whether they match the server
operation name or not.
- If the future application only runs on WebSphere(R) Application Server, use WebSphere Studio
Application Developer to migrate the application. If the future application
runs on WebSphere Business
Integration Server Foundation, using WebSphere Studio Application Developer
Integration Edition and you will have more features supported. The migration
tool will provide fewer features on WebSphere Studio Application Developer
than WebSphere Studio
Application Developer Integration Edition. The difference is there will be
no supported for generating the business process. In WebSphere Studio Application Developer,
the step operations or the flow processor will not be able to migrate. The
project team needs to change it to be non-step operations, or just skip it
and create the Single Action EJB manually. Also, the non-step operation can
only be migrated to a Single Action EJB.