CCF-to-J2C Architecture Migration

Chapter 7. Migrating a real-life application 111

Our result was the Build Path shown in Figure 7-23.

Figure 7-23 Updated Java Build Path

112 CCF-to-J2C Architecture Migration

Runtime references

Changing the runtime references for the application was a bit trickier.

Initially we tried adding the newly created Service Project to the EAR containing

the Web module with the application. Unfortunately, we had to abandon this idea

because of classloader issues. Classes that loaded in the Web-module class

loader used classes loaded in the EAR file class loader, which used classes only

available in the Web-module classpath and therefore were not available to the

classes loaded by the EAR file class loader.

We resolved to deploy the new Service Project in the Web module as seen in

Figure 7-24.

Figure 7-24 Web module setup for migration using CMA

Chapter 7. Migrating a real-life application 113

We also had to add the Web Service libraries to the WebSphere V4 server

configuration to get the application to run under WebSphere V4.

Figure 7-25 WebSphere V4 setup to support the CMA-migrated application

Updating the code

As the result of the conversion, we received three types of errors, caused by:

򐂰 Using the getBytes() method of former Record type.

򐂰 Using xxxRecord_SystInfo_xxx beans in the application code. These classes

are not the part of J2CA architecture, so there were no corresponding classes

in the migrated code.

򐂰 Using the Record constructors with the byte array (COMMAREA) as an

argument. The J2CA does not allow creating records from the byte array.

In this chapter, we show how to eliminate of all of these errors.

114 CCF-to-J2C Architecture Migration

Modifying the use of getBytes

We performed the following replacements for CCF getBytes calls (located in the

buildRequest methods()).

Example 7-6 The original code (buildRequest())

...

MessageRecord request = new MessageRecord();

/*some message parameters settings*/

requestArray = request.getBytes();

...

Example 7-7 The replacement code (still in buildRequest())

...

request = new MessageRecord();

/*some message parameters settings*/

MessageRecordFormatHandler handler = new MessageRecordFormatHandler();

request = (MessageRecord)handler.setObjectPart(request);

request.fireElementEvents();

requestArray = handler.getBytes();

...

Here the MessageRecord designates an arbitrary input record class. The reason

for creating the MessageRecord on its own and not from the FormatHandler

class is that the method containing these lines (buildRequest) was heavily

overwritten to accommodate common initialization of common parts of the

Record objects. To minimize impact of the migration, we opted not to change the

standalone instantiation of the MessageRecord objects.

Note: We did some experimentation to gain this implementation design. One

hard lesson was that when one creates a Record object on its own, the

associated FormatHandler is not instantiated, meaning that the return value of

the _getFormatHandler() method on the Record object will always be null.

Only when the Record object has been instantiated by a FormatHandler will

the return value of _getFormatHandler() be not null (and of course if a

FormatHandler has been set on the Record object using the

_setFormatHandler() method).

Chapter 7. Migrating a real-life application 115

Replacing the use of SystInfo classes

The original code contained the calls to xxxRecord_SystInfo_xxx classes:

MessageRecord_SystInfo_MRec mRec = responce.getMRec(0);

We replaced these calls by calls to the corresponding Record classes:

MessageRecord_MRec mRec = response.getMRec(0);

Now the MessageRecord designates the arbitrary record.

Modifying the use of constructors

The CCF framework enabled Record objects to be initialized with the byte array,

conveniently provided by a constructor that accepted a byte array as input. This

was used in all of the buildResponse() methods.

The J2CA framework does not allow this, so we figured out another way of

initializing a response Record object with the byte array received from CICS. We

ended up with the following code modifications.

Example 7-8 The original code (from buildResponse())

...

response = new MessageRecord(eciRequest.Commarea);

...

Example 7-9 The replacement code

...

MessageRecordFormatHandler outHandler = new MessageRecordFormatHandler();

outHandler.setBytes(eciRequest.Commarea);

response = (MessageRecord) outHandler.getObjectPart();

...

Now the Message designates the arbitrary output record.

Modifying the exception handling

The application error handling is based on converting all exceptions into an

application-specific exception, the NovaException.

This means that all places where there could be a CCF-specific exception, the

application already contained a try{...}catch{...} block as in Example 7-10.

Example 7-10 Original exception handling code (buildResponse)

try {

...