In this phase, you need to analyze the differences between
BTT version 5.2 and BTT version 7.0, especially the application logic
layer.
About this task
Based on the documentation of the existing application system,
you can identify the parts that can be migrated automatically and
the parts that cannot be migrated automatically, and then make necessary
preparation for the migration. To get well prepared for the migration,
you need to do the following work:
- Gather all the definition files of the existing application system
version 5.2. The migration tool can migrate the definition files on
the server side from version 5.2 to version 7.0. The migration tool
can process the definition contents based on the given rules. BTT
version 7.0 provides default migration rules, but if there are any
special tag definitions that are not included in the default rules,
the migration tool might not be able to migrate them successfully
or properly. In this case, you need to customize the migration tool
rules to extend the process to cover those special tag definitions
for the application or migrate them manually later.
- The migration tool can migrate the business logic Java™ code of the application to BTT version
7.0 directly. BTT version 7.0 uses the processor, operation, and operation
step on the server side of BTT. There is much enhancement and refinement
in the architecture of BTT version 7.0, so it has different package
names, class names, and changes of APIs. The migration tool can migrate
BTT version 5.2 classes and APIs to the corresponding BTT version
7.0 classes and APIs.
- Migrate the BTT version 5.2 invoker. BTT version 5.2 leverages
the invoker framework to invoke the business logic. BTT version 5.2
leverages EJB as the business logic implementation. The invoker of
BTT version 5.2 is mainly used for EJB calling from the BTT runtime
server. In BTT version 7.0, the architecture is improved. The request
from the channel side will directly call the BTT processor or operation
in the BTT runtime container, where you can handle some channel aware
logic or business logic. If you want to call EJB, JMS, and BPEL, BTT
provides you an invoker to invoke them. BTT version 5.2 invoker framework
is not used in BTT version 7.0, because a more powerful and ease-of-use
invoker framework is implemented in BTT version 7.0. You should migrate
your applications to adopt the new BTT version 7.0 invoker.
- BTT version 7.0 provides more powerful Context and Formatter,
and the API usage is different with that in BTT version 5.2. The migration
tool of BTT version 7.0 can help you migrate the Context, Formatter,
and APIs for the migration.
- Migrate BTT version 5.2 services. The supported services of BTT
version 7.0 on the server side support all of the BTT version 5.2
services. The migration tool helps to migrate the package names, class
names, APIs, and so on. If you have some customized services, you
can customize the migration rule to meet your migration requirements.
- The event mechanism is changed to fit version 7.0 framework
so that it can be distributable and spans different servers. You must
do some manual migration to run the BTT version 5.2 event in BTT version
7.0.
- There are two kinds of client applications in BTT version 5.2.
There is no change to the Swing based Java client,
so you do not need to migrate it to BTT version 7.0. For JSP/HTML
based client, the migration tool migrates JSP Tablib uri, BTT customized
tag, page import, and Java code in JSP file.
- Migrate the BTT trace. BTT version 7.0 enhances the trace
features to support more powerful functions and comprehensive APIs.
BTT version 7.0 trace is completely compatible with BTT version 5.2
trace. If you do not want to use the new trace framework, the old
trace can still work in BTT version 7.0 runtime container. If you
want to use the new trace, use the migration tool to achieve the trace
by defining specific migration rules.
- If the future application only runs on WebSphere® Application
Server, use Rational® Application Developer to migrate
the application. If the future application runs on WebSphere Process
Server, use WebSphere Integration Developer to migrate
the application.