Introduction

This article is part of a series of IBM ® VisualAge® for Java™ CCF to WebSphere® Studio J2C migration articles that describe the typical activities for migrating CCF CICS® ECI, IMS™, or WebSphere MQ into J2C applications. This series includes the following articles:

• CCF to J2C migration: Part 1: CCF application limitations on WebSphere Application Server V5
• CCF to J2C migration: Part 2: Overview of migrating VisualAge for Java CCF applications into WebSphere Studio J2C applications
• CCF to J2C migration: Part 3: Migrating VisualAge for Java CCF CICS-ECI applications into WebSphere Studio J2C CICS-ECI applications
• CCF to J2C migration: Part 5: Migrating of VisualAge for Java CCF MQ applications into WebSphere Studio J2C JMS applications

Updates to this article

• Guideline for accessing ConnectionSpec or InteractionSpec (May 2004)
• Exploiting Managed Connections (May 2004)

Most of this article is the same as Part 3 of this series, which describes CICS-ECI migrations. In most cases, "CICS-ECI" has simply been replaced with "IMS," but there are some differences:

• Install the WebSphere Studio IMS RAR (Resource Adapter) instead of (or in addition to) the CICS RAR.
• Copy the imsconn.jar from the IMS Connector for Java (IC4J) product instead of (or in addition to) the ctgclient.jar from the CTGateway product. imsconn.jar can also be downloaded as part of the tools available from the IC4J Web page (click IMS Connector for Java, then click downloads). After downloading and installing any of the IC4J tools, look in the directory IMSICO\CCF.
• Install and then migrate the VAJ IMS PhoneBook (Command) sample instead of (or in addition to) the CICS-ECI Adder sample.
• Use the same CCF Migration Assistant (CMA) since CMA processes both CICS-ECI and IMS artifacts.
• There are IMS-specific artifact (command and record) limitations and guidelines.
• There are IMS-specific application limitations and guidelines.

In addition, many IMS programmers probably have not read Part 3: Migrating CICS-ECI applications, so this article is complete and contains all of the IMS migration information.

Back to top

Overview

VisualAge for Java uses the Common Connector Framework (CCF) to simplify the creation and maintenance of Java applications that access host Enterprise Information Systems (EIS's). These EIS resources are typically Customer Information Control System (CICS) transactions, Information Management System (IMS) transactions, or WebSphere MQ message queues. The VisualAge for Java Enterprise Access Builder (EAB) feature supports this CCF framework by providing tools to create CCF connector objects (Java command and record classes), and applications that use these CCF connector objects.

As the value of the CCF framework became recognized and accepted, IBM submitted it for consideration as an industry standard. After review and modification, it became J2EE Connector Architecture (J2C). While J2C is similar to its predecessor CCF, there are significant differences between the two and migration is not trivial. It is desirable to migrate existing VisualAge for Java CCF applications into WebSphere Studio J2C applications whenever there are J2C equivalents. This article covers two main topics:

• Migration of EAB tool generated CCF IMS connector artifacts
• Migration of developer-written IMS applications that use those objects

Important: If you have fewer than 10 or so CCF IMS commands and records, then the best approach is to just manually regenerate the J2C artifacts within WebSphere Studio, and manually migrate your applications. If you more than 100 or so CCF commands and records, then using this article and the CCF Migration Assistant (CMA) is your easiest migration route to WebSphere Studio J2C. If you have between 10 and 100 CCF commands and records, it is recommended that you read this article and then decide which route to take.

Back to top

Migration assistance services

IBM WebSphere Services has a range of migration assistance that customers can purchase:

1. On-site training or assistance for WebSphere Application Server V3.5 => V4 => V5 application migration
2. On-site assessment of CCF application migration, description of work, and scope of effort
3. Installation and familiarization with the CCF Migration Assistant (CMA) program
4. Pilot migration of small applications or application components
5. Optional migration of larger applications

For further information, contact:

• In North or South America: Mitch Johnson via e-mail at mitchj@us.ibm.com or via phone at 1-919-254-0065
• In Europe or the Middle East: Richard Johnson via e-mail at richardj@uk.ibm.com or via phone at 44-1962-817714
• In Asia Pacific: Rick Jones via e-mail at at rick.jones@au1.ibm.com or via phone at 61-2-9478-8219

Back to top

Best practice for artifact (services) and application (Web or Java) projects

The VisualAge for Java IMS PhoneBook (Command) sample has the generated CCF artifacts and its Ex01Execute application together in one project (since in total there are only nine Java files). Your specific VisualAge for Java CCF applications may have only one VisualAge for Java project, or many, depending on how your CCF application VisualAge for Java projects are organized.

During migration to WebSphere Studio is the ideal time to ensure your ongoing project structure follows a simple "best practice." We recommend that you have one or more WebSphere Studio service projects to contain groups of related J2C Services, and one or more Web or Java projects to contain your application (typically, one Web or Java project for each major subsystem of your overall application):

• For example, you might have one WebSphere Studio service project, PersonnelServices, containing a group of services accessing CICS personnel programs and IMS personnel programs.
• In addition, you might have one WebSphere Studio Web project, PersonnelWeb, using the PersonnelServices project, an InventoryWeb project using some other InventoryServices project, and an AdminJava project accessing administration programs via both Services projects.
• Together, the collection of these Services and Web or Java projects make up your overall application.

A little logical organization greatly simplifies long-term understanding and maintenance of these projects.

Back to top

CCF to J2C IMS migration steps

This article describes in detail how to migrate a CCF IMS application into a J2C IMS application, and includes the following steps:

1. Set up VisualAge for Java and WebSphere Studio Integration Edition.
2. Export from VisualAge for Java the CCF IMS class artifacts and CCF IMS applications source.
3. Import and migrate CCF IMS artifacts (using WebSphere Studio CMA) into J2C artifacts.
4. Import and manually migrate CCF IMS applications (using the CCF to J2C IMS coding guidelines). This application migration activity includes any application life-cycle maintenance to accommodate new JDK levels, new Server APIs, and so on.
5. Deploy and test.
6. Life-cycle maintenance of the migrated J2C artifacts and applications.

Back to top

Step 1. Set up VisualAge for Java and WebSphere Studio

1. As described in the CCF Migration Overview article, ensure that you have VisualAge for Java V3.5.3 or V4.0 set up appropriately:
• This system must include your CCF IMS applications and generated IMS artifacts (Commands and Records).
• Optional: The CCF IMS PhoneBook (Command) sample (if you wish to migrate it as per this article).
2. As described in the CCF Migration Overview article, ensure that you have WebSphere Studio V5.1.1 set up appropriately:
• Ensure that the required fix pack and all required interim fixes are installed as shown below:
  
• Follow the installation instructions in the IMS/MFS samples, "Building a service that submits commands to IMS" sample (to install your IMS RAR, and to ensure everything is set up and operational): and ensure that all required resource adapters (IMS for this article) are installed into RAR projects (CicsEci, Ims, and Hod3270 projects are shown below):
• Ensure that the CCF Migration Assistant (CMA) plug-in is installed:
• The Overview article describes how to request and obtain the CMA plug-in.
  The CMA plug-in is not part of WebSphere Studio and is not supported -- you cannot call IBM Support and request assistance or report problems related to it.
• Please allow one to two weeks for:
• Your e-mail to searle@ca.ibm.com requesting the plug-in.
• Our return e-mail containing the "As-Is" license.
• Your return e-mail stating your agreement.
• Our return e-mail containing the current CMA plug-in (or FTP instructions).
3. The above steps are necessary to ensure that you understand the that plug-in is provided "As-Is", and to enable us to send you CMA updates if any become available. The screen capture below shows how your plug-in registry will appear after you have installed the CMA plug-in:

Back to top

Step 2. Export VisualAge for Java CCF artifacts and CCF applications

You can export the CCF artifact classes (and optional source files) plus the CCF application source (and optional classes) all together in one Java Archive (JAR) file. In fact, this is the easiest approach if you are going to follow the unsupported approach of importing the artifacts plus applications into WebSphere Studio and then editing the source and recompiling everything. As noted in the CCF Migration Overview article, this procedure seems to work for most applications, but it is not supported as it has not been extensively system tested by IBM. There may be subtle problems because of different JDK compiler levels, different support libraries, and so on.

The XxxxBeanInfo helper classes are used only within VisualAge for Java and are not needed during migration (just the XXXXRecord, XXXXRecordType, and XxxxCommand classes are needed). The XxxxBeanInfo artifacts can be included in the exported JAR, but they will be bypassed by the CMA program and a warning to this effect will be written into the CMA log. It is cleaner to just export the Command, Record, and RecordType classes. Source Java files can also be included in the exported JAR file, but they will also be ignored by the CMA program.

Typically, for the CCF Migration Assistant (CMA) migration processes, you would migrate all of your CCF-generated artifacts into a JAR file. If you are migrating the CCF Adder sample, you might export the generated CCF artifact classes into a JAR file named IMSphoneClasses. Therefore, to export the PhoneBook (Command)> artifacts:

1. Expand the com.ibm.connector.ims.sample.phonebook.command package and right-click to multi-select the required EX01Command, InMsg, OutMsg, InMsgInfo, and OutMsgInfo files.
2. Then click Export => JAR file => Next => .class (your can leave .java selected if you wish; the CMA will ignore them).
3. In the JAR file field, type C:\CCF\IMSphoneClasses.jar and then click Finish. The CCF artifacts are exported:
4. Similarly, for the CCF application migration process, select Ex01Execute and export its one .java source file into C:\CCF\IMSphoneExecute.jar:

For this small sample, you may prefer just to export all of the required .class and .java files together into one C:\CCF\IMSphoneEverything.jar. This approach is the easiest if you want to try the unsupported import, then edit and rebuild within WebSphere Studio.

Back to top

Not supported: WebSphere Studio source import and rebuild of CCF artifacts and applications

Most CCF applications and CCF artifacts seem to properly rebuild in WebSphere Studio and then run successfully on WebSphere Application Server. This is not tested and not supported because of differences in the Java compiler level, other updated libraries, and system API changes. Therefore, one unsupported approach to short-term CCF application maintenance is to install the CCF connectors into WebSphere Studio and WebSphere Application Server (see the previous limitations article, and note that the actual CCF connectors require run-time licenses for installation and use within WebSphere Application Server), and then to export the EAB-generated CCF artifacts (Java source for generated commands and records) into WebSphere Studio.

The Java source for developer-written VisualAge for Java CCF applications, and the generated CCF artifacts, can be exported as a JAR file and then imported into an WebSphere Studio Java project, the same as for any other Java program. You can then use the default WebSphere Studio Java editor to manually edit them, since they are just Java source files, but WebSphere Studio cannot regenerate any CCF artifacts. For example, assuming that you exported all of the VisualAge for Java IMS PhoneBook (Command) files into IMSphoneEverything.jar, then within WebSphere Studio, follow these steps:

1. Create a Java project. Click File => New => Project => Java => Java project => Next, then for Project Name type CCFphoneIMS and click Finish to create the Java project.
2. Import the CCF source:
1. Select the CCFphoneIMS project, then click File => Import => Zip file => Next. Browse to your C:\CCF\IMSphoneEverything.jar, and click Finish to populate the Java project.
2. If you also exported the XxxxBeanInfo files (Ex01CommandBeanInfo or InMsgBeanInfo or OutMsgBeanInfo) then you can select them and delete them.
3. Eliminate errors due to dependencies:
   1. Your IMS CCF applications need the IMS Connector for Java (IC4J) imsconn.jar to build and run. You could create a project ImsConn and store it there for shared usage, but since we only have one CCF IMS project it is easiest just to import it (as a file system file) into this project.
   2. Now click the Libraries tab. The imsconn.jar and the four WebSphere Application Server main run-time CCF jars (ccf.jar, eablib.jar, j2ee.jar, recjava.jar) should all be on the build path, and there should be no compile errors on your Task View:
4. Execute -- right-click the Ex01Execute class and select Run. You should have a successful CCFphoneIMS execution in the Console view:
5. Deploy and Test -- You can also deploy the recompiled CCFphoneIMS application (plus the required CCF runtime JARs) to a remote workstation, and run it.

Back to top

Step 3. Migrate CCF artifacts into J2C using WebSphere Studio CCF Migration Assistant (CMA)

1. Import the CCF artifacts as a file system file (to keep them as a JAR) into the desired Service project.
2. Migrate these CCF artifacts into J2C artifacts using the program.
3. Finally, normal ongoing life-cycle maintenance within WebSphere Studio.

1. Import CCF artifacts JAR into WebSphere Studio Service project

1. WebSphere Studio CMA plug-in: Ensure that it was installed was during WebSphere Studio Setup.
2. WebSphere Studio IMS RAR project: Ensure that it was installed was during WebSphere Studio Setup.
• You need an IMS Connect run-time license to install the IMS RAR on a run-time server. IC4J is a component of that host product (IMS Connect).
• Also remember the CCF on WebSphere Application Server V5 limitations.
3. Create the desired J2C Service project:
   1. Click File => New => Project => Business Integration => Service Project => Next, and enter the Project Name as IMSphoneServices.
   2. Click Next => Projects => Ims => Finish. This adds the Ims RAR project run-time dependency.
4. Import CCF artifact JAR (as a file system file):
   1. Select your new IMSphoneServices project, and click File => Import => File system => Next. Browse to your C:\CCF\IMSphoneClasses.jar file and click Finish to import and retain it as a JAR file.

2. CMA migrate CCF artifacts into J2C Service

1. Right-click IMSphoneClasses.jar and select Migrate CCF artifacts.
2. VisualAge for Java can generate code using several different styles for accessor methods:
   • The "shorten" style is of the form Xxx__Yyyy.
   • The "no shorten style" is of the form XXX__YYYY.
   • The WebSphere Studio Integration Edition style is of the form Xxx__yyyy.
3. Select the no shorten names compatibility option radio button and then click Next:
4. Select the Do not generate JNDI Name entry and then click Finish:
5. The CMA migration proceeds and finishes, resulting in the creation of Command, Record, and RecordFormatHandler Java classes, and WSDL metadata files:

At this point there is a J2C service proxy, and a data bean plus Format Handler helper classes for the CICS ECI Adder program. You still need to migrate an application that actually uses it, as shown in Step 4 below.

At this point there is a J2CsService proxy (CommandBean), and data beans (Messages), plus Format Handler helper classes for the IMS PhoneBook (Command) program. You still need to migrate an application (Step 4) that actually uses it.

3. Ongoing J2C artifact maintenance within WebSphere Studio

Now, you just do normal ongoing lifecycle maintenance of your J2C artifacts with WebSphere Studio. The only special considerations are:

• Whenever you regenerate a J2C artifact, remember to use the same options (name style, and so on) to retain existing application compatibility.
• If you used the CMA-generated CCF compatibility methods to speed your initial application migration, then they will be automatically retained within the service proxy anytime it is regenerated with WebSphere Studio.

Back to top

Step 4. Migrate CCF applications to use J2C artifacts using migration coding guidelines

1. Modify the CCF application to use the migrated J2C artifacts using the CCF to J2C application guidelines.

1. Import CCF applications into Web or Java projects

1. Create the desired application Web or Java projects:
   1. Click File => New => Project => Java => Java Project => Next then type IMSphoneApplication for the Project Name.
   2. Click Next and click the Projects tab. Select IMSphoneServices and then click Finish. This adds the build and run-time dependent IMSphoneServices project.
2. Import the CCF application from its JAR file:
   1. Select your new IMSphoneApplication project.
   2. Click File => Import => Zip file => Next, and then browse to your C:\CCF\IMSphoneExecute.jar file.
   3. Click Open => Finish to import the application (just one Ex01Execute.java file for the PhoneBook (Command) sample).

2. Migrate application using CCF to J2C Application Guidelines

1. One typical error (shown below) results from requiring build and run-time access to org.apache.wsif.WSIFException and other WSIF classes:
   1. A typical time-saver is to define a workbench environment variable (to do so, click Window => Preferences => Java => Classpath Variables, then click New and name it WAS_50_LIB) to permit adding Library JAR files as Add Variable > Extend > WAS_50_LIB\lib extensions.
   2. Right-click the IMSphoneApplication project and then click Properties => Java build path. Click the Libraries tab and click Add External JARs to add the WebSphere Application Server run-time library JAR files j2ee.jar, qname.jar, wsatlib.jar, wsif.jar, and wsif-j2c.jar:
2. Another standard set of errors (shown above) requires removing all old com.ibm.connector.* imports.
3. Another standard set of errors (shown below) requires removing all old JavaRuntimeContext code which is now handled by the J2C Service WSDL (Ex01CommandImsService.wsdl).
4. Also remove any setHostName, setPortNumber, or setDataStoreName code (since that is also done in the same Service.wsdl).
5. Also remove the JavaRASService, RASService, ConnectionManager, and IMSLogonInfoItems code that used RuntimeContext:
6. Another standard set of errors (shown above) relates to the new J2C command invocation style. The CCF to J2C Application guidelines describe standard application changes needed to manipulate commands and records. The optional CMA generated CCF compatibility methods are available to minimize short-term application changes (to speed initial CCF to J2C application migration). Application usage of these short-term (deprecated) CCF compatibility methods should be changed during application life-cycle maintenance to use the current J2C invocation style.

   For example, the old CCF Command.setOperand() plus Command.execute(CommandEvent) pattern:

   • ...is deprecated compatibility invocation new Record() plus Record.setOperand() plus Command.setCeInput(Record) plus Command.execute()
   • ...but best practice is the new J2C invocation new Record() plus Record.setOperand() plus Command.setEx01CommandRequestPart(Record) plus Command.execute()

   Another example, the old old CCF Command.getOutput() pattern (which was Command.getCeOutput0() internally):

   • ...is deprecated compatibility invocation Command.getOutput()
   • ...but best practice is the new J2C invocation Command.getEx01CommandRequestPart().
   
7. Another error (an IMS pattern change) is that CCF IMS Command.getOutput():
   • Is normally used to return an OutMsg and
   • For errors used to return a DFSMsg (from Command.getDFSData1() and Command.getDFSMessage() ) and
   • Therefore the application had to receive an object and then test for the correct OutMsg type:
   • In J2C, the application just gets an OutMsg, but also catches a WSIFException (in case of an imbedded IMSDFSMessageException):
8. After removing all the commented out code, the basic code now looks like this:
9. Best practice: A WSIFException, by itself, is typically not very informative. Since they include a TargetException, that should be obtained and displayed since it may be more informative (it is the real error). Also, many of the TargetException errors are actually javax.resource.ResourceException errors that have a LinkedException containing the root error. A best practice is to always try to extract the most informative message from any caught WSIFException:

Back to top

Step 5. Deploy and test (execute) the migrated application)

1. Open the Ex01Execute.java program and click Run:

If your execution fails due to a "WSIF1008E: Exception port out range:-1 error," then your Ex01CommandImsService.wsdl does not have its ims:addresss correctly CMA migrated (typically because it was dynamically set in the original application). Correct it by manually editing the Ex01CommandImsService.wsdl.

If you do manually edit the Service.wsdl then, depending on the version and FixLevel of WebSphere Studio Integration Edition you are running, you might get an unnecessary "cvc-complex-type.2.4.c: 'ims:address'" warning. Ignore it -- no user edit will eliminate the unnecessary warning.

Important: During WebSphere Studio execution, if the Run => Classpath => Use default classpath option is not checked, then you may get a WSIFException failure due to codepage-037 not being available. Ensure you are running with the default classpath (which includes full codepage support).

Back to top

Step 6. Ongoing life-cycle migrated application maintenance within WebSphere Studio

Now, you just perform normal ongoing lifecycle maintenance of your J2C application within WebSphere Studio. One special consideration is if you used the CMA-generated CCF compatibility methods to speed your initial application migration, then you should replace them with the normal J2C style command and record invocations whenever convenient. They can be done a few at a time since both invocation styles work.

Back to top

CMA limitations and guidelines

This section will be updated if significant new IMS CMA limitations or guidelines are discovered. The CMA plug-in contains online documentation, which is the most detailed and most current definition of known CMA limitations, issues, and guidelines.

The currently known, most significant IMS-specific CMA limitations and guidelines can be summarized as follows:

1. Only fixed length records (manual application changes are required for variable-length records, including IMS multi-segment records). See the multi-segment sample information in the application limitations section.

The currently known, most significant generic CMA limitations and guidelines can be summarized as follows:

1. CCF IMS (or CICS-ECI or Beta-JCA) artifacts only (see the CICS-ECI article for CICS-ECI specifics). No CICS-EPI, HOD-3270, or MQ artifacts.
2. COBOL records only (no C nor PL/I).
3. Fixed-length and dynamic records must use the normal generated accessors (any base framework access requires manual migration).
4. Must have a RecordType (RecordInfo) for all records (otherwise they are skipped and need manual migration).
5. Only the default mapping is supported for RecordTypes (a changed preferred type requires manual migration).
6. No hierarchical style records (manual migration required).
7. Custom methods in CCF artifacts are not preserved (need to be manually copied).
8. No CCF Navigator migration (manual migration required, most likely to Processes).
9. No CCF Mapper migration (manual migration required, most likely to Transformers).
10. No EAB SessionBean nor BusinessObject migration (manual migration required):
    • If EAB SessionBeans were generated using CommandBean wrappering, those CommandBeans can be migrated, and deploy code generated within WebSphere Studio.
    • If EAB SessionBeans were generated using CustomUserMethods, all code was inline and used user method names, so no automated migration is possible
    • If matching SessionBeans are manually regenerated within WebSphere Studio, then user applications should migrate easily and typically require no SessionBean invocation changes
11. CCF Commands generated with promote Record properties may require manual application changes.
12. Group and export CCF artifacts by server and transaction name (CMA assumes common JNDI ConnectionFactory).
13. Group and export CCF artifacts by name style (CMA assumes single name style throughout CCF JAR).
14. The CMA and its documentation is English Only (it is not a production product).
15. Important: The CMA online documentation is the ultimate source for current limitations and guidelines. If in doubt, consult it and not this article (which may have become out of date).

Back to top

Application limitations and guidelines

This section may be updated if significant new IMS application limitations or guidelines are discovered.

The currently known, most significant, application limitations and guidelines can be summarized as follows:

1. An example of IMS multi-segment message handling is available on the IMS Web page.
   • Select IMS Connector for Java => Support => Self-Help Technotes => IMS Connector for Java.
   • The sample is Building an Application to Process Variable Length and Multiple Segment IMS Transaction Output Messages
2. The CCF IMS connector supports IMS transactions that run Commit Mode 1 with SyncLevel Confirm and SyncLevel None.
   • Commit Mode 1 with SyncLevel Confirm allows the IMS transaction output message to be returned to the Java application so the application can decide whether to commit or rollback.
3. The J2C IMS resource adapter (IMS Connector for Java) does not support Commit Mode 1 with SyncLevel Confirm interactions with IMS.
   • However, the J2C IMS resource adapter allows two-phase commit (2PC) control of single or multiple interactions with resources such as IMS, DB2, and CICS
   • 2PC transaction support is available for z/OS LocalOption plus RRS with IMS V8.1 and J2C IMS resource adapter V1.2.5.2
   • 2PC transaction support is available for distributed TCP/IP plus RRS with IMS V7 and J2C IMS resource adapter V2.1.0
4. J2C has enhanced handling of IMS RequestType and DFS messages:
   • For CCF, DFS messages come back as output in the DFSMsg bean.
   • For the J2C IMSInteractionSpec property imsRequestType 1, the request is an IMS transaction.
     • Normal transaction output returned by IMS is used to populate the application's output message.
     • If IMS returns a DFS message, the IMS resource adapter throws an IMSDFSMessageException.
     • This value for imsRequestType is used for applications that are not generated using WebSphere Studio MFS support.
   • For the J2C IMSInteractionSpec property imsRequestType 2, the request is an IMS command.
     • Command output returned by IMS, including DFS messages, is used to populate the application's output message.
     • The IMSDFSMessageException is not thrown.
     • Some commands like /DISPLAY ACTIVE REGION will return a multi-segment message.
     • Since the default imsRequestType is 1, developers need to manually change imsRequestType to type 2 (in the WSDL) if they wish their application to behave this way.
     • Submitting commands to IMS from the Web is not recommended.
   • For the J2C IMSInteractionSpec property imsRequestType 3, this is reserved for applications that are generated using WebSphere Studio MFS support.
     • Normal transaction output returned by IMS, as well as DFS messages, are used to populate the application's output message.
     • The IMSDFSMessageException is not thrown.
     • This value for imsRequestType does not apply to migrated applications, since MFS support did not exist for the CCF connector.
5. Currently, Java applications that run IMS conversational transactions must use the J2C Common Client Interface (CCI), since the programming models provided by WebSphere Studio Integration Edition do not support certain requirements of IMS conversational transactions.
   • For example, a Java application that runs an IMS conversational transaction must maintain the same connection with IMS Connect for the duration of the conversation.
   • CMA could still be used to migrate the input and output messages of the conversation.

The currently known, most significant, J2C generic application limitations and guidelines can be summarized as follows:

1. Catch WSIFException (instead of old CCFException).
2. Initially, use new CMA CCF compatibility methods to emulate the old CCF Command superclass hierarchy to speed short-term application migration:
• These CCF compatibility methods within CMA-generated service proxies provide many of the features from the old CCF command superclass hierarchy, and simplify the migration of applications that use those deprecated features.
• These CCF compatibility methods are added by the CMA into the "user code" section of proxies (without the @generated tag), and therefore that code is retained whenever the same proxies are regenerated within WebSphere Studio Integration Edition.
• Important: To maximize long-term compatibility, during ongoing application maintenance, change any migrated applications to use the new J2C style of invocation and stop using the short-term (deprecated) CMA CCF compatibility methods.
3. Slight changes in data bean getters and setters (cannot get attribute after command execution, etc).
4. No record cloning (can use FormatHandler getBytes() if really needed).
5. BigDecimal replaced by int (signature changes, precision may require application rewrite).
6. Record field attributes (example length) are not accessible.
7. Use new WebSphere Application Server APIs (new security model, no RuntimeContext, etc).
8. Currently cannot catch DataRangeExceptions (under investigation as possible J2C tooling enhancement).
9. Subrecords are not always initialized (could cause NullPointerExceptions).
10. In J2C, there are two types of EIS sign-on: component managed and container managed. These types did not exist in the CCF architecture, where the CCF sign-on was more like component-managed sign-on:
• With J2C component-managed sign-on, the userID, password, and optional (IMS) groupName can be passed in the ConnectionSpec (which is normally not programmatically accessible).
• To access the ConnectionSpec, modify the WSDL files using the instructions in the WebSphere Studio online help.
• Search the online help for "Exposing the InteractionSpec and ConnectionSpec".
• This section lists the ConnectionSpec and InteractionSpec properties you can access, and tells you how to access them.
• Or, you can associate a component alias with the connection factory, which lets you provide userID and password (see the note below).
11. In J2C, one of the significant enhancements is managed connections:
• In WebSphere, managed connection factories can provide details of the servername, CTG URL, username, password, and so on.
• This information is therefore kept out of the application code and can easily be altered by a system administrator (with no code changes).
• The application makes a JNDI lookup that is bound (by the administrator) to the address of the appropriate managed connection factory.
• The lookup can be re-bound anytime (by the administrator) to a different managed connection factory.
• And/or the managed connection factory itself can be easily changed (by the administrator).

Back to top

Conclusion

WebSphere Studio WebSphere Studio Integration Edition has a completely new set of tools optimized to create and maintain J2C objects and applications. It is desirable to migrate existing VisualAge for Java CCF applications into WebSphere Studio J2C applications whenever there are J2C equivalents. This article has covered two main topics: migrating EAB tool-generated CCF IMS connector artifacts, and migrating developer-written applications using those artifacts

About the authors

Ellen Matheson McKay is an Information Developer for IBM Canada Ltd. She writes online help and publications for WebSphere Studio Application Developer.

Barry Searle is the Migration Team Leader for WebSphere Studio Application Developer. He is a Professional Engineer who has worked at the IBM Canada Lab for over ten years on various application development tools. Prior to that he had many years of industry experience developing command and control systems and leading communications development projects.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Overview
• Migration assistance services
• Best practice for artifact (services) and application (Web or Java) projects
• CCF to J2C IMS migration steps
• Step 1. Set up VisualAge for Java and WebSphere Studio
• Step 2. Export VisualAge for Java CCF artifacts and CCF applications
• Not supported: WebSphere Studio source import and rebuild of CCF artifacts and applications
• Step 3. Migrate CCF artifacts into J2C using WebSphere Studio CCF Migration Assistant (CMA)
• Step 4. Migrate CCF applications to use J2C artifacts using migration coding guidelines
• Step 5. Deploy and test (execute) the migrated application)
• Step 6. Ongoing life-cycle migrated application maintenance within WebSphere Studio
• CMA limitations and guidelines
• Application limitations and guidelines
• Conclusion
• About the authors
• Comments

Next steps from IBM

Rational Application Developer features provide the comprehensive Integrated Development Environment (IDE) used to develop J2EE applications requiring Servlets and JavaServer Pages (JSPs).

---

• Try: Try the free Rational Application Developer, which helps developers quickly design, develop, test, analyze, and deploy high-quality Java, Javaserver pages, and J2EE applications.
• Article: Learn how you can deliver accurate, higher-quality J2EE apps with Rational Application Developer, open source JUnit and JUnitEE test frameworks.
• Tutorial: Build a Facebook application using PHP, the Spring framework, and J2EE.
• Buy: Rational Application Developer

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers