CCF-to-J2C Architecture Migration

94 CCF-to-J2C Architecture Migration

These changes do not modify the basic operation of the application and are

“cosmetic”, all tasks are being done according to the original plan, design and

implementation, but using different classes.

The implementation details are described in 7.2, “CMA-based migration of the

CCF artifacts” on page 97.

7.1.6 Other considerations

The first step in any migration is to consider the goals of the migration: What do

we want to achieve, what are the success criteria, what will make the investment

in the migration worthwhile?

The initial and prime driver for the migration is the need to stop using VisualAge

for Java and CCF in the development of the application. But achieving this will not

make the application any different or give any benefits, apart from releasing the

application from the dependency of unsupported application development tools.

Put bluntly, performing the migration does not give any value-add related to

status quo. The migrated application will be the same to the end users and

operations.

For some time, the programmers of the application have discussed whether the

application would benefit from using a managed connection instead of the

application-managed connection currently in use. Among the reasons for the

original use of CCF classes are the current limitations in the deployment

environment. This is due to the use of WebSphere Application Server V4.0.x in a

V3.5 configuration, inhibiting the use of managed connections and other

advanced features of WebSphere 4.0.x.

There are plans for upgrading the current deployment environment from

WebSphere Application Server 4.0.x in Version 3.5 configuration to WebSphere

Application Server 5.x. With this in mind, we want to migrate the application to

use managed connection instead of the application-provided management of the

connection to CICS.

This can only be done manually, which would also give us the ability to compare

the complexity and investment in time in doing a manual migration, relative to an

almost automatic migration.

Performing a manual migration

Based on our knowledge of J2CA, managed connections, and so on, we decided

that the best approach to use is a CommandProxy model, instead of trying to

utilize the managed connections in the original CICS interface model.

Chapter 7. Migrating a real-life application 95

We decided to replace the use of the NovaGateway in the original

implementation with a J2CA CommandProxy implementation. This would give us

a clean cut, removing all low-level interface code with one simple interface,

externally configurable and using JNDI for storing the connection properties.

The component model in Figure 7-6 shows this change. Note that the

CommandProxy is not a single class used in all CTGCommands, but a number of

CommandProxy classes, one for each interaction with CICS.

Figure 7-6 Component model using managed connections

As a consequence of replacing the NovaGateway with the CommandProxy, there

are some changes to the interactions from the CTGCommands. These are

96 CCF-to-J2C Architecture Migration

presented in Figure 7-7 and should be compared to the original interaction flow in

Figure 7-5 on page 88. The most important change is the removal of the method

performRequest(), which contained calls to two methods: buildEci() and

flowECI().

Figure 7-7 Interaction diagram using a CommandProxy

Instead of performRequest(), a number of method calls have been added to

buildResponse(). This is based on the implementation assessment, from which

we figured that the simplest modification and cleanest cut would be to comment

out the calls in performRequest and comment out the call to buildResponse().

Note: This is not a good use of the CommandProxy classes. But the

CTGCommand class hierarchy is very complex. The execute() method is

overwritten in subclasses of the top-level CTGCommand, and the subclass

implementation contains cascading calls to different transactions. Because of

this, the selected implementation was judged the best approach in the short

time frame available. With more time available we would have created a

different and better design.