级别： 初级 Ellen Matheson McKay (ecmckay@ca.ibm.com), WebSphere 信息开发人员, IBM 多伦多实验室
Barry Searle (searle@ca.ibm.com), WebSphere Studio 开发人员, IBM 多伦多实验室
2004 年 6 月 01 日 这篇由五个部分组成的系列文章向您介绍如何将应用程序从 VisualAge for Java Common Connector Framework（CFF）迁移到 WebSphere Studio J2EE Connector Architecture。第 3 部分将向您展示如何设置 WebSphere Studio CCF Migration Assistant，并迁移 CCF CICS-ECI 构件，以及如何手动迁移 CCF CICS-ECI 客户端应用程序。
引言
本文是一系列介绍从 IBM
®VisualAge
®for Java
™CCF 到 WebSphere
®Studio J2C 的迁移的文章的一部分，这一系列文章描述了将应用程序从 CCF CICS
®ECI、IMS
™ 或 WebSphere MQ 迁移到 J2C 的典型活动。这一系列文章包括以下几个部分：
对本文的更新
概述
VisualAge for Java 使用 Common Connector Framework（CCF）来简化访问主机 Enterprise Information Systems（EIS's）的 Java 应用程序的创建和维护。这些 EIS 资源是典型的 Customer Information Control System（CICS
®）事务、Information Management System（IMS）事务或者 WebSphere MQ 消息队列。VisualAge for Java Enterprise Access Builder（EAB）能够提供创建 CFF 连接器对象（Java Command 和 Record 类）的工具以及使用这些 CCF 连接器对象的应用程序，从而支持 CFF 框架。
由于 CCF 框架的价值已被认可和接受，IBM 已经提交它以考虑将其制订为行业标准。经过评审和修改，它就成为了 J2EE Connector Architecture（J2C）。虽然 J2C 和它的前身 CCF 相类似，但还是存在许多显著的区别，迁移还是有很大价值的。因此，将现有的应用程序从 VisualAge for Java CCF 迁移到 WebSphere Studio J2C 是可取的（只要存在等价的 J2C）。本文包括两个主题：
- EAB 工具生成的 CCF CICS-ECI 连接器构件的迁移
- 开发人员编写的使用这些对象的应用程序的迁移
如果您的 CCF CICS-ECI 命令和记录的数量还不到十来个，那么最好的方法就是在 Application Developer 中手动重新生成 J2C 构件，并手动迁移您的应用程序。如果您有多于 100 个左右的 CCF 命令和记录，那么使用本文介绍的方法和 CCF Migration Assistant（CMA）是您迁移到 Application Developer J2C 最简单的途径。如果您有 10 个至 100 个 CCF 命令和记录，那么推荐您阅读本文，然后自己决定采取哪种途径。
迁移帮助服务
IBM WebSphere Services 有各种各样的迁移帮助，顾客都可以购买到：
- WebSphere Application Server V3.5 => V4 => V5 应用程序迁移的在线培训或帮助
- CCF 应用程序迁移、工作描述和有效范围的在线评估
- 安装并熟悉 CCF Migration Assistant （CMA）程序
- 小型应用程序或应用程序组件的试验性迁移
- 大型应用程序的选择性迁移
要获取进一步的信息，请联系：
构件（服务）和应用程序（Web 或 Java）项目的最佳实践
VisualAge for Java Adder 样本将生成的 CCF 构件及其 ExecuteAdder 应用程序放在一个项目中（因为总共只有六个 Java 文件）。您的特定 VisualAge for Java CCF 应用程序可以只有一个 VisualAge for Java 项目，也可以有多个，这取决于您的 CCF 应用程序 VisualAge for Java 项目的组织方式。
迁移到 WebSphere Studio 的期间是保证正在进行迁移的项目结构遵循简单的“最佳实践”的最佳时间。我们建议您准备一个或多个 WebSphere Studio Service 项目来包含相关的 J2C Service 组，以及一个或多个 Web 或 Java 项目来包含您的应用程序（一般来说，您的整个应用程序中的的每个主要子系统都有一个 Web 或 Java 项目）：
迁移到 Application Developer 的期间是保证正在进行迁移的项目结构遵循简单的“最佳实践”的最佳时间。我们建议您准备一个或多个 Application Developer Service 项目来包含相关的 J2C Service 组，以及一个或多个 Web 或 Java 项目来包含您的应用程序（一般来说，您的整个应用程序中的的每个主要子系统都有一个 Web 或 Java 项目）：
- 例如，您可能有一个 Application Developer 服务项目——PersonnelServices——它包含一组访问 CICS 个人程序和 IMS 个人程序的服务。
- 另外，您可能还有一个使用 PersonnelServices 项目的 Application Developer Web 项目——PersonnelWeb， 一个使用其他 InventoryServices 项目的 InventoryWeb 项目，以及一个通过前两个 Services 项目来访问管理程序的 AdminJava 项目。
- 这些服务和 Web 项目或 Java 项目组合在一起就构成了完整的应用程序。
一个小小的逻辑结构大大简化了对这些项目长时间的了解和维护。
从 CCF 到 J2C CICS-ECI 的迁移步骤
本文详细描述了如何将应用程序从 CCF CICS-ECI 迁移到 J2C，其中包括以下步骤：
-
设置VisualAge for Java 和 Application Developer。
- 从 VisualAge for Java
导出CCF CICS-ECI 类构件和 CCF 应用程序源代码。
-
导入 CCF CICS-ECI 构件并将其迁移到（使用 Application Developer
CMA）J2C。
-
导入并手动迁移 CCF CICS-ECI 应用程序
（使用
从 CCF 迁移到 J2C CICS-ECI 编码指导原则）。 这种应用程序迁移活动包含了所有的应用程序生命周期维护，从而能够适应新的 JDK 级别、新的 Server API 等等。
-
部署和测试。
- 迁移的 J2C 构件和应用程序的
生命周期维护。
步骤 1. 设置 VisualAge for Java 和 Application Developer
- 如
第 2 部分：迁移概述所述，请确保您正确设置了 VisualAge for Java V3.5.3 或 V4.0 ：
- 本系统必须包括您的 CCF CICS-ECI 应用程序和生成的 CICS-ECI 构件（命令和记录）。
-
可选项：CCF ICS-ECI Adder 样本（如果您希望像本文所介绍的那样对它进行迁移的话）：
- 如
第 2 部分：迁移概述，确保您正确设置了 Application Developer V5.1.1：
- 确保必需的补丁包和所有必需的临时补丁以下图所示方式进行安装：
- 遵循 CICS-ECI 样本中的安装说明：
并确保所有必需的资源适配器（在本文中为 CICS）都已经安装到 RAR 项目中（以下所示为 CicsEci、Ims 和 Hod3270 项目）：
- 确保安装了 CCF Migration Assistant（CMA）插件：
-
第 2 部分：迁移概述介绍了如何请求和获得 CMA 插件。
CMA 插件
并非Application Developer 的一部分也
不受它支持——您不能访问 IBM 支持来请求帮助或者报告与其相关的问题。
- 要获得该插件，请允许有一到两周的时间来完成以下的事情：
- 发送电子邮件到
searle@ca.ibm.com请求该插件。
- 我们返回给您包含“仅此状态”许可的电子邮件。
- 您返回给我们接受该许可的电子邮件。
- 我们返回给您包含当前 CMA 插件的电子邮件（或者 FTP 指令）。
- 以上步骤是必要的，它能够让您明确该插件是我们按“仅此状态”提供给您的，并且如果有什么 CMA 更新的话，我们也将会发送给您。以下屏幕截图显示了在安装完 CMA 插件之后插件注册中心看起来的样子：
步骤 2. 导出 VisualAge for Java CCF 构件和 CCF 应用程序
您可以将 CCF 构件类（和可选的源文件）及 CCF 应用程序源文件（和可选的类）一起导出到一个 Java Archive （JAR）文件中。事实上，如果您现在还采用将构件及应用程序导入到 Application Developer，接着编辑源文件并重新编译所有的文件这种不受支持的方法，则上述过程将是最简单的。正如
第 2 部分：迁移概述所提到的那样，这一过程看起来对大多数应用程序都是有效的，但事实上它是
不受支持的，因为它还
没有由 IBM 进行广泛的系统测试。由于有不同的 JDK 编译器级别、不同的支持库，所以它们可能还存在着一些小问题。
XxxxBeanInfo 助手类只用于 VisualAge for Java，在迁移的过程中不需要使用它（只需使用 XXXXRecord、XXXXRecordType 和 XxxxCommand 类）。XxxxBeanInfo 构件
可以包含在导出的 JAR 中，但 CMA 程序不会运行它们，并在 CMA 日志中写入一个对这种现象的警告。如果只导出 Command、Record 和 RecordType 类 ，则 JAR 文件会显得更加简洁。Java 源文件也可包含在导出的 JAR 文件中，但它们通常会被 CMA 程序忽略。
在通常情况下，对于 CCF Migration Assistant （CMA）迁移过程，您需要将所有 CCF 生成的构件迁移到一个 JAR 文件中。在您迁移 CCF Adder 样本时，您可能需要将生成的 CCF 构件类导出到一个名为 AdderClasses 的 JAR 文件中。因此，要导出 Adder 构件，您需要执行以下操作：
- 展开 com.ibm.ivj.eab.sample.eci.adder 包，右键单击来选择必需的 AdderCommand、AdderRecord 和 AdderRecordInfo 多个文件。
- 然后单击
Export => JAR file => Next => .class（如果愿意，也可把
.java文件选上——CMA 会忽略它们）。
- 在
Jar file 字段内，键入
C:\CCF\ECIAdderClasses.jar ，然后单击
Finish。这样就可导出 CCF 构件了。
同样，对于 CCF 应用程序迁移过程，请选中
ExecuteAdder 并将它的一个 .java 源文件导出到
C:\CCF\ECIAdderExecute.jar 。
对于这个小样本，您可能更倾向于将所有必需的 .class 和 .java 文件放在一起导出到
C:\CCF\ECIAdderEverything.jar 文件中。如果您想尝试不受支持的导入，然后在 Application Developer 中对它进行编辑和重建，那么这种方法就是最简单的。
不受支持：Application Developer 源代码的导入以及 CCF 构件和应用程序的重建
大部分的 CCF 应用程序和 CCF 构件看起来都能够在 Application Developer 中很好地重建，然后在 WebSphere Application Server 中成功地运行。但由于 Java 编译器级别的不同、使用其他最新的库文件以及系统 API 的改变等原因造成了它们
不能进行测试和受到支持。因此，短期 CCF 应用程序维护的一个不受支持的方法是将 CCF 连接器安装到 Application Developer 和 WebSphere Application Server 中（请参阅前面
关于局限的文章，并注意实际安装 CCF 连接器时需要运行时许可，另外，还需要在 WebSphere Application Server 中使用），然后将 EAB 生成的 CCF 构件（生成的 command 和 record 类的 Java 源代码）导出到 Application Developer 中。
开发人员编写的 VisualAge for Java CCF 应用程序的 Java 源代码以及生成的 CCF 构件可以作为一个 JAR 文件导出，并可将其导入到某一 Application Developer Java 项目中，与其他的 Java 程序一样。因为它们仅仅是 Java 源文件，同时 WebSphere Studio
不能重新生成任何的 CCF 构件，这样您就可以使用缺省的 Application Developer Java 编辑器手动对它们进行编辑了。例如，假设您要将所有的 VisualAge for Java ECI Adder 文件导出到 ECIAdderEverything.jar 中，然后将其导入 Application Developer，您就可以按照以下的步骤来进行操作：
- 创建一个 Java 项目。单击
File => New => Project => Java => Java project => Next， 然后在
Project Name 字段中键入
CCFAdderECI ，并单击
Finish，这样就可创建一个 Java 项目了。
- 导入 CCF 源文件：
- 选择
CCFAdderECI项目，然后单击
File => Import => Zip file => Next。找到您的
C:\CCF\ECIAdderEverything.jar，然后单击
Finish将它植入到 Java 项目中。
- 如果您还导出了 the XxxxBeanInfo 文件（AdderCommandBeanInfo 和 AdderRecordBeanInfo），则请选中它们并将其删除。
- 排除因依赖性而引起的错误：
- 右键单击
CCFAdderECI项目，再选择
Properties => Java build path。然后单击
Projects选项卡。确保您的 CICS-ECI RAR 项目（您在
Application Developer Setup中设置它）位于构建路径。
- 单击
Libraries选项卡。CICS ECI RAR\connectorModule\ctgclient.jar 和四个 WebSphere Application Server 主运行时 CCF Jar（ccf.jar、eablib.jar、j2ee.jar、recjava.jar）都必须在构建路径中：
- 执行——右键单击
ExecuteAdder类然后选择
Run。这样在控制台视图中就会有一个成功的 CCFAdderEci 执行结果。
如果 CCF ExecuteAdder 类正确运行，这也表示您的 CICS ECI RAR 和 CICS 事务网关 （CTGateway 或 CTG）文件已正确设置并正常工作，您需要在 J2C CICS ECI 操作中使用它们。
- 部署和测试——您也可以将重新编译的 CCFAdderEci 应用程序部署到一个远程的 WebSphere Application Server 上，然后运行它。
您需要一个 CTGateway 连接器运行时许可来把 CICS ECI RAR 安装到一个运行时服务器上，而且您还需要注意
CCF 应用程序在 WebSphere Application Server V5 中的局限性。
 |
|
步骤 3. 使用 Application Developer CCF Migration Assistant（CMA）将 CCF 构件迁移到 J2C
- 将 CCF 构件作为一个文件系统文件（使之成为一个 JAR 文件）导入到期望的 Service 项目中。
- 使用程序将这些构件从 CCF 迁移到 J2C。
- 最后，在 Application Developer 中进行正常的生命周期维护。
1. 将 CCF 构件 JAR 导入到 Application Developer Service 项目中。
- 确保 Application Developer CMA 插件是在
Application Developer 设置过程中安装的。
- 创建您想要的 J2C Service 项目：
- 单击
File => New => Project => Business Integration => Service Project => Next，然后在
Project Name 中输入
AdderServices 。
- 单击
Next => Projects => CicsEci =>Finish。这样就加入了 CicsEci RAR 项目运行时依赖性。
- （作为一个文件系统文件）导入 CCF 构件 JAR 文件:
- 选择新的
AdderServices项目，然后单击
File => Import => File system => Next。定位到您的 C:\CCF\ECIAdderClasses.jar 文件，然后单击
Finish导入并保留为 JAR 文件。
2. CMA 将 CCF 构件迁移到 J2C 服务中
- 右键单击
ECIAdderClasses.jar并选择
Migrate CCF artifacts。
- 选择
Shorten names compatibility option单选按钮，然后单击
Next：
- 选择
Do not generate JNDI Name entry，然后单击
Finish：
- CMA 进行迁移并最后完成，其结果是创建 Command、Record 和 RecordFormatHandler Java 类以及 WSDL 元数据文件：
在这个阶段已经有了一个 J2C 服务代理、一个数据 bean 以及一个 CICS ECI Adder 程序的 Format Handler 助手类。您还需要迁移一个实际使用它的应用程序，参见
迁移一个应用程序（步骤 4）。
3. 在 Application Developer 中进行 J2C 构件维护
现在，您只需要对 Application Developer 中的 J2C 构件进行正常的生命周期维护。惟一需要特别注意的是：
- 无论什么时候您重新生成一个 J2C 构件，都请记住要使用同样的选项（
name style等）来保持现有的应用程序的兼容性。
- 如果您使用 CMA 生成的 CCF 兼容性方法来加速您原始应用程序的迁移，那么任何时候在 Application Developer 中重新生成您的应用程序时，这些方法都会自动保持在服务代理中。
步骤 4：按照迁移编码指导原则迁移 CCF 应用程序来使用 J2C 构件
- 将 CCF 应用程序导入到需要的 Web 或 Java 项目中。
- 按照
CCF 迁移到 J2C 应用程序指导原则修改 CCF 应用程序以使用迁移的 J2C 构件。
1. 将 CCF 应用程序导入到 Web 或 Java 项目
- 创建您想要的应用程序 Web 或 Java 项目：
- 单击
File => New => Project => Java => Java Project => Next，然后为
Project Name 键入
AdderApplication 。
- 单击
Next，然后单击
Projects选项卡。选择
AdderServices，然后单击
Finish。这样就添加了 AdderServices 项目的构建和运行时依赖性。
- 从 JAR 文件中导入 CCF 应用程序：
- 选择您新创建的
AdderApplication项目。
- 单击
File => Import => Zip file => Next，然后定位到您的 C:\CCF\ECIAdderExecute.jar 文件。
- 单击
Open => Finish来导入该应用程序（也就是用于 Adder 样本的一个 ExecuteAdder.java 文件）。
2. 使用从 CCF 迁移到 J2C 应用程序指导原则来迁移应用程序
- 需要在构建和运行时访问 org.apache.wsif.WSIFException 及其他的 WSIF 类会带来一个典型的错误（如下图所示）：
- 一种典型的节省时间的方式是定义一个工作台环境变量（要定义该变量，请单击
Window => Preferences => Java => Classpath Variables，然后单击
New 并将它命名为
WAS_50_LIB ）来允许添加 Library JAR 文件，与
Add Variable => Extend => WAS_50_LIB\lib 扩展一样：
- 右键单击
AdderApplication项目，然后单击
Properties => Java build path。单击
Libraries选项卡并单击
Add External JARs来添加 WebSphere Application Server 运行时库 JAR 文件 j2ee.jar、qname.jar、wsatlib.jar、wsif.jar 和 wsif-j2c.jar。
- 另一组标准错误是要求我们删除所有旧的 com.ibm.connector.* 导入：
- 同时还有一组标准错误是要求我们删除所有旧的 JavaRuntimeContext 代码：
- 从 CCF 迁移到 J2C 应用程序指导原则描述了为使用命令和记录而需要对应用程序进行的更改。我们可以使用可选的 CMA 生成的 CCF 兼容性方法来使短期应用程序改动的时间减到最少（从而加速应用程序从原始的 CCF 迁移到 J2C 的过程）。使用这些短期的（已弃用的）CCF 兼容性方法的应用程序必须在应用程序生命周期维护期间做一些改动，以便使用当前的 J2C 调用方式：
- 例如，旧的 CCF Command.setOperand() 和 Command.execute(CommandEvent) 模式...
- ...是已弃用的兼容性调用方法，即新的 Record() 和 Record.setOperand() 和 Command.setCeInput(Record) 和 Command.execute()...
- ... 但是最佳实践是新的 J2C 调用，即新的 Record() 和 Record.setOperand() 和
Command.setAdderCommandRequestPart(Record) 和 Command.execute()。
- 另一个例子是旧的 CCF Command.getRes() 模式（它在内部是 Command.getCeOutput0().getRes()）...
- ... 是已弃用的兼容性调用方法，即 Command.getCeOutput().getRes() ...
- ... 但是最佳实践是新的 J2C 调用方法，即 Command.getAdderCommandRequestPart().getRes()。
- 另一个标准错误集（如上所示）需要 org.apache.wsif.WSIFException 处理，还需要添加一个导入 org.apache.wsif.WSIFException 声明：
-
最佳实践： WSIFException 本身通常并不能给我们提供多少信息。但最佳实践包含了一个 TargetException，它能给我们提供更多的信息（因为它是一个真实的错误），所以我们应该获取并显示它。同时，许多的 TargetException 错误是真正的 javax.resource.ResourceException 错误，它们具有一个包含了根错误的 LinkedException。最佳实践就是始终设法从任何捕捉到的 WSIFException 中提取包含最多信息的消息：
|
|
步骤 5. 部署和测试（执行）迁移的应用程序
- 打开
ExecuteAdder.java程序并单击
Run：
如果您由于
WSIFException -- Port 'AdderCommandCICSECIPort' is not available 错误而执行失败，则表明您的
AdderServices 项目没有将它的
Properties => Java Build Path => Projects设置为包含 CicsEci CICS-ECI RAR 项目。这
不会引起任何构建错误，因为它是
运行时依赖性。
重要：在 Application Developer 执行期间，如果
没有选中
Run => Classpath => Use default classpath选项，则您可能会由于代码页 437 不可用而得到一个 WSIFException 失败。确保您是以缺省的类路径运行的（它包含完整的代码页支持）。
步骤 6. 在 Application Developer 中正在进行迁移的应用程序的生命周期维护
现在，您需要执行的步骤是在 Application Developer 中对您的 J2C 应用程序进行正常的生命周期维护。有一点需要特别注意的是，如果您使用 CMA 生成的 CCF 兼容性方法来加速初始应用程序的迁移，那么在方便的时候您应该将它们替换为正常的 J2C 方式的命令和记录调用。由于同时使用两种调用方式，所以您可以一次替换几个。
CMA 的局限性和指导原则
如果有新的
重要的CICS-ECI CMA 局限性或指导原则，这一部分将会进行更新。CMA 插件包含了在线文档，这些文档是关于已知的 CMA 局限性、问题和指导原则的最详细和最新的定义。
当前已知的最重要的 CMA 局限性和指导原则可以归纳如下：
- 只有 CCF CICS-ECI（或 IMS，或 Beta-JCA）构件（请参阅
IMS 文章以了解关于 IMS 的详细介绍）。没有 CICS-EPI、HOD-3270 或 MQ 构件。
- 只有 COBOL 记录，没有 C 和 PL/I。
- 只有单段记录。手动更改应用程序需要 IMS 多段记录。
- 固定长度和动态记录必须使用正常生成的访问器。任何基本框架访问都需要手动迁移。
- 所有的记录都要有一个 RecordType——否则它们在迁移时会被跳过而需要手动迁移。
- 只有缺省映射是受 RecordTypes 支持的。每个首选类型更改后都需要手动迁移。
- 没有层次样式的记录。需要进行手动迁移。
- CCF 构件中的自定义方法不会被保持并需要手动复制。
- 没有 CCF Navigator 迁移。需要手动迁移，最合适的是迁移到 Processes。
- 没有 CCF Mapper 迁移。需要手动迁移，最合适的是迁移到 Transformers。
- 没有 EAB 会话 Bean 和业务对象迁移。需要手动迁移：
- 如果 EAB 会话 Bean 是通过使用 Command Bean 包装生成的，则这些 Command Bean 可以进行迁移，并可以在 Application Developer 中部署生成的代码。
- 如果 EAB 会话 Bean 是通过使用 CustomUserMethods 生成的，则所有的代码都是内嵌的并使用用户方法来命名，所以是不可能自动迁移的。
- 如果匹配的会话 Bean 是在 Application Developer 中手动重新生成的，则用户应用程序就可以很容易地进行迁移，通常不需要改变会话 Bean 调用。
- 通过提升的记录特性生成的 CCF Command 可能要求手动更改应用程序。
- 根据服务器和事务名称来组织和导出 CCF 构件（CMA 采用通用的 JNDI ConnectionFactory）。
- 根据名称样式来组织和导出 CCF 构件（CMA 在整个 CCF JAR 范围内采用单一的名称样式）。
- CMA 以及它的文档只有英文版的——它并不是正式发布的产品。
-
重要： CMA 在线文档是当前的局限性和指导原则的最终来源。如果有疑问，请参阅在线文档而不是本文（因为本文可能已经过时了）。
应用程序的局限性和指导原则
如果有新的
重要的 CICS-ECI 应用程序局限性或指导原则，这一部分可能会进行更新。
当前已知的最重要的应用程序局限性和指导原则可以归纳如下：
- 捕捉 WSIFException（而非旧的 CCFException）。
- 在刚开始的时候，使用新的 CMA CCF 兼容性方法来模拟旧的 CCF Command 超类层次，以便加速短期应用程序迁移：
- CMA 生成的服务代理中的这些 CCF 兼容性方法提供了许多来自旧的 CCF command 超类层次的特征，同时简化了使用这些已弃用的特征的应用程序的迁移。
- 这些 CCF 兼容性方法由 CMA 添加到代理的“用户代码（user code）”部分（不带 @已生成（generated）标记），因此只要同样的代理在 Application Developer Integration Edition 中重新生成，该代码都会被保留。
-
重要：若要使长期兼容性最大化，在正在进行的应用程序维护期间，请修改每个已迁移的应用程序，使它使用新的 J2C 调用方式并停止使用短期（已弃用）CMA CCF 兼容性方法。
- 在数据 bean getters 和 setters 中有细微的改动（命令执行之后不能获得属性，等等）。
- 没有记录复制（如果确实需要，可以使用 FormatHandler getBytes()）。
- BigDecimal 为 int 所代替（签名改变了，精度可能需要应用程序重写）。
- Record 字段属性（例如长度）不可访问。
- 使用了新的 WebSphere Application Server API （新的安全性模型，没有运行时上下文，等等）。
- 当前不能捕捉 DataRangeExceptions（研究发现可能是由于 J2C 工具增强的缘故）。
- Subrecords 并不总被初始化（这可能会引起 NullPointer 异常）。
-
在 J2C 中，有两种类型的 EIS 登录：组件管理的登录和容器管理的登录。这些类型并不存在于 CCF 体系结构中，在该体系结构中，CCF 登录更像是组件管理的登录：
- 在使用 J2C 组件管理登录的情况下，userID、password 和可选的（IMS）groupName 都可以在 ConnectionSpec 中传递（通常不可以用编程方式访问 ConnectionSpec）。
- 要访问 ConnectionSpec，请使用 WebSphere Studio 在线帮助中的指令来修改 WSDL 文件。
- 在在线帮助中查找“Exposing the InteractionSpec and ConnectionSpec”。
- 该部分将列出您可以访问的 ConnectionSpec 和 InteractionSpec 特性，并告诉您如何去访问它们。
- 或者，您也可以将组件别名与连接工厂相关联，这会让您提供用户 ID 和密码（参阅下面的注释）。
-
在 J2C 中，最重要的增强之一是受管连接：
- 在 WebSphere 中，受管连接工厂能够提供服务器名称、CTG URL、用户名、密码等等的详细信息。
- 因此该信息在应用程序代码以外，并且系统管理员可以容易地修改这些信息（不需要更改代码）。
- 应用程序建立 JNDI 查找，该查找绑定（由系统管理员）到适当的受管连接工厂的地址。
- 该查找在任意时刻都可以重新绑定到一个不同的受管连接工厂。
- 并且/或者该受管连接工厂本身可以很容易地进行更改（由系统管理员）。
|
|
结束语
WebSphere Studio Application Developer Integration Edition 有一组全新的工具，可以优化用于创建和维护 J2C 对象和应用程序。对于将现有的应用程序从 VisualAge for Java CCF 迁移到 WebSphere Studio J2C（只要存在等价的 J2C）来说， 这组工具是非常理想的。本文涵盖了两方面的主题：迁移 EAB 工具生成的 CCF CICS-ECI 连接器构件和使用这些构件来迁移开发人员编写的应用程序。
作者简介 | | |
Ellen Matheson McKay是 IBM 加拿大有限公司的信息开发人员。她撰写了 WebSphere Studio Application Developer 的在线帮助和在线发布。
|
| 
| |
Barry Searle是 WebSphere Studio Application Developer 的迁移小组负责人。他已在 IBM 加拿大实验室工作了十余年，曾涉足各种应用程序开发工具的领域，是一位专业工程师。在此之前，他已从事了多年的命令与控制系统的开发和领先的复杂通信开发项目工作，具有多年的业界工作经验。
|
对本文的评价
| 
