级别： 中级 任 志宏 (renzhih@cn.ibm.com), IBM 中国 SOA 设计中心,高级软件工程师, IBM
陈 雷 (cdlchenl@cn.ibm.com), IBM 中国 SOA 设计中心,资深软件工程师, IBM
张 森, IBM 中国 SOA 设计中心，高级软件工程师, IBM
刘 伟 (liuwcdl@cn.ibm.com), IBM 中国 SOA 设计中心,软件工程师, IBM
张 辉 (cdlhuiz@cn.ibm.com), IBM 中国 SOA 设计中心，软件工程师, IBM
2007 年 3 月 21 日 面向服务的体系结构(service-oriented architecture，SOA)从来就不是一个新的概念，只是当它和敏捷业务流程(Agile Business Process)、灵活的IT基础设施(Flexible IT Infrastructure)以及既有资产盘活(Legacy Enablement)所面临的问题相遇时，才成为目前众人追捧的对象。
在这个系列的文章中，我们将抛开那些在SOA身上华丽的口号和玄虚的概念，从不同的实践角度剖析既有资产和SOA的方方面面。
引言
首先我们会谈到企业既有的软件和信息资产，方便起见，企业既有的软件和信息资产都会被统称为既有资产(legacy)，虽然对于某些人来说，既有资产这个词有负面内涵，但实际上不应当是这样的。既有资产基本上来说，是指部署在基础结构中的现有IT资产。通常，它们对业务有重要的价值。要想认识既有资产的重要性，请看这样的事实：据估计，目前存在 2000亿行COBOL代码，而全世界70%的业务数据是由COBOL应用程序处理的，并且每天要处理300亿个基于COBOL的交易。显然，这些程序都是可以利用的、非常有价值的既有资产。从拥有成本的角度来看，我们应当重用这些重要的资产，而不是去重新构建他的替代资产，以便在继续利用现有资产的同时利用新的技术进步。通过这样的方式逐步使企业更灵活、能够更好响应机会，更好地服务于客户，这就是我们称为敏捷业务流程的内涵。
为了使本文更具有普遍性，我们将通过裁减若干已经成功实施的项目，构建本文的样例。如上文所述，在主机时代，以COBOL语言开发的应用程序，为大型的企业和组织提供了众多的核心业务应用，同时对这些业务应用的开发、维护和培训等已经投入了巨大的资金和人力。因此我们选取了在主机运行的库存和目录管理应用作为我们的样例。通过对集成开发者所承担的开发过程的阐述，说明SOA的理念对于既有资产的影响以及通过WDz使二者有机的结合起来。
我们模拟了一般可能出现的场景并给出了具体的讨论和实现。通过本文，读者最终可以自己利用WebSphere Developer for zSeries V6实现通过Web服务访问已有的COBOL应用, 而本文所有的源代码和脚本将会提供给读者作为详细的参考。同时，对于文中涉及的概念和基本操作流程在本文所列的参考资料中都有更多的介绍，在此不再赘述。
样例说明
本样例是一个简化了的零部件目录及库存查询模块，通常，一个零售企业会为所销售的部件维护一个统一的目录服务，提供给用户或者店员查询。在店员查询到顾客所需的部件后，店员同样需要从库存管理系统查询目前该部件的库存情况，决定能否将部件销售给顾客。在本样例中，目录和库存服务都是由CICS应用提供。为了支持多种接入设备的灵活查询，需要将上述应用转换为Web service。下面是这个样例的Use case图：
图 1. 样例Use case图
开发方法
通常的情况下，我们有三种开发方式来将已有的应用转变为SOA环境中可用的服务，具体采用什么样的开发模式，则取决于你所开发的具体项目。下文中，我们对这三种方法作简单的介绍(如图所示)：
图 2. 既有资产SOA化开发方法
自底向上(bottom-up)的开发方法，当用户期望从已有的应用创建一个新的服务时，应当采取这种开发方法。这时候我们需要生成对web service的描述以及指定已有数据结构和运行时的XML消息映射。例如对于一个已有的COBOL应用，首先选取接口的数据结构，然后生成部署所需要的供应商转换工件(artifacts)。
中间会合(meet-in-the-middle)的开发方法，当用户已经拥有定义好的WSDL文件和已实现的应用或者组件的时候，这时我们需要开发附加的代码来实现上述二者之间的映射。例如定义在不同语言如：WSDL, XML, XSD 或 DTD之间的数据结构映射。
自顶向下(top-down)，采用这种方式，用户可以创建一个新的服务满足已有的WSDL定义。通常情况这种服务定义会是工业标准的一部分，可以由不同的服务提供商来实现。这种开发方法需要实现WSDL所定义的数据结构和提供对运行时的XML消息处理支持。
接下来，我们将基于IBM WebSphere Developer for zSeries v6来介绍两种开发方法。
在WebSphere Developer for zSeries v6实现样例开发
在WebSphere Developer for zSeries (WDz) v6中，IBM提供了XML Services for the Enterprise(XSE) 和Service Flow Modeler(SFM)等工具进一步增强对SOA的支持：
XML Services for the Enterprise 工具使用户能够方便地转换基于 COBOL 的业务应用程序，以使其成为 Web Service 并能够处理和生成 XML 消息。这种与被调用应用程序的新接口允许因特网用户访问现有的 CICS 或 IMS应用程序。这些工具还可以帮助用户将 COBOL 应用程序嵌入到使用 XML 来进行数据交换的大型系统中。XML Services for the Enterprise 工具由下列内容构成：
- Web Service 启用向导，它允许生成新 Web Service 接口。通常，这种方法称为自底向上方法，这是因为现有的 COBOL 应用程序处于新 Web Service 创建过程的“底部”。
- XML 至 COBOL 映射工具，它允许将现有 Web Service 接口或 XML 数据定义映射至现有的 COBOL 程序。通常，这种方法称为中间会合方法，这是因为现有 Web Service 定义与现有 COBOL 接口“相遇”或者映射至现有 COBOL 接口。
- 批处理器，它允许以无人照管（批处理）模式运行 Web Service 接口。批处理器目前支持采用自底向上方法来创建 Web Service。批处理器的功能与上面所描述的“Web Service 启用”向导的功能相当。
Service Flow Modeler工具既支持现代的应用开发，也支持已有应用/流程的改编和重用。Service Flow Modeler在帮助用户将已有的企业信息系统和CICS运行环境向SOA平滑过渡的同时，提升用户的既有投资和信息资产。Service Flow Modeler工具由下列内容构成：
- 使用流程或者服务的接口组合新的业务服务。
- 捕获现有的EIS(屏幕或者通讯)接口，生成适合SOA的新接口。
- 根据接口生成请求/响应消息处理的适配器以及流程和接口之间的数据转换适配器。
- 将业务流程发布为web service。
利用XML Services for the Enterprise将COBOL应用转换为Web Services
利用XSE工具实现自底向上的方式将基于COBOL的业务应用转换为Web服务，将分为以下四个主要步骤：
图 3. XSE开发步骤
步骤一：将COBOL数据定义导入z/OS本地项目
将WDz切换到z/OS Projects 视图，创建一个新的z/OS Local Project，并命名为CICSWS。
图 4. 创建本地z/OS项目
图 5. 本地z/OS项目
将被导入的COBOL程序WDZPARTS.cbl包含了数据定义，而WDZPARTS则是被部署在CICS Transaction Server for z/OS V3.1上的CICS应用，提供了对部件的库存查询。 需要将视图切换到Remote Systems，然后在Local目录下找到WDZPARTS.cbl文件，将其copy到CICSWS项目。
图 6. 复制COBOL文件到本地z/OS项目
这时，项目中应该包含一个WDZPARTS.cbl工件，如图所示。
图 7. 包含COBOL文件的本地z/OS项目
步骤二：使用Web Service 启用向导生成供应商转换工件
至此，我们便可以使用Web Service 启用向导来生成WSBind 文件和XML Services for the Enterprise 转换器。其中，WSBind 文件是用来对 CICS描述 Web Service 细节的一种资源。在 CICS 供应商方案中，CICS 将 SOAP 请求和响应消息的转换委托给供应商转换程序。XML Services for the Enterprise 工具将生成适合与 CICS供应商接口配合使用的转换程序。这些程序由一个驱动程序和两个 XML 转换器（入站转换器和出站转换器）构成，入站转换器将输入 XML 文档转换为 COBOL 数据结构，出站转换器将输出 COBOL 数据转换为输出 XML 文档；驱动程序则管理 CICS 与 XML 转换器之间的通信。
为了方便起见，和真实的场景不同，我们将WDZPARTS裁减为不需要后台数据库连接的应用，这样方便将其部署在z/OS 系统上。实现的逻辑是：对给定的一个部件代码， WDZPARTS应用返回部件相关的库存信息。
在z/OS 项目视图中，右键单击包含接口数据结构的程序源文件WDZPARTS.cbl，并选择Enable Enterprise Web Service。
图 8. 选择Enable Enterprise Web Service
将出现一个向导，在向导的第一个页面首先要求输入转换器类型，这里选择Web Services for CICS。
图 9. 选择Web Services for CICS
第二个页面将为应用程序选择入站和出站数据结构。在Web Service for CICS – Language Structures页面，对于入站语言结构选项页(Inbound language structure)， 仅选中DFHCOMMAREA 中PartNo作为入站转换器的数据结构。对于出站语言结构选项页(Outbound language structure)，选中DFHCOMMAREA全部数据作为出站转换器的数据结构。
图 10. 语言结构选项页
第三页提示输入生成的工件的属性。在Web Service for CICS –Generation Options 在页面，对于XML转换器选项页，确保所有的代码页条目都被设置为相应的z/OS 系统的代码页；对于在 WSDL 和 XSD 选项页上，输入此 Web Service 的端点 URI。此 URI 的本地部分将被用作供应商 WSBind中的本地 URI 的缺省值。
图 11. 生成工件属性选项页
接着，显示了供应商 WSBind 属性页。接受缺省的设定。此处的本地URI便是先前指定的URI地址的本地部分。选择下一步。
图 12. WSBind属性选项页
最后一页需要输入生成的工件在文件系统中的位置和名称。选择完成。
图 13. 生成工件的位置和名称选项页
然后Web Services for CICS向导会生成如图所示的文件：
图 14. 完成后的项目文件
步骤三：创建和部署生成的Web Service工件到CICS Transaction Server
使用Remote System资源管理器将 XML 转换器文件复制到远程z/OS项目的目标库或者PDS中。将转换器驱动程序指定为主入口点，生成构建转换器装入模块并将此模块存储在 PDS 或 PDSE 中的 JCL；提交 JCL。应该保证目标 PDSE 应在目标 CICS 区域的 DFHRPL concatenation中，以便 CICS 能找到装入模块。
通过上述步骤我们已将 XML 转换器装入模块部署到了主机系统。现在需要将其余的工件、WSBind 和 WSDL 传输到 CICS PIPELINE 的 “pickup”目录。将在此 PIPELINE 下面安装 Web Service。“pickup”目录存在于目标系统的 HFS 中。
创建一个PIPELINE 资源，并且在PIPELINE的定义中，必须定义 “pickup”目录，此目录允许自动地直接从 WSBind 文件安装 Web Service。关于设置 CICS Web Service 提供者类型 PIPELINE更详细的资料可参考 CICS 3.1 文档中有关设置提供者类型的文档。如下的PIPELINE (WKPIPE01)用来安装Web Service, “pickup”目录/u/dnet/017/cwspickup/ 正是WSBind 文件存放的位置。
图 15. CICS 3.1 截屏
当完成上述操作后，我们可以通过如下命令，进行Web Service的自动安装：
列表 1. Web Service 加载命令
CEMT PERFORM PIPELINE(WKPIPE01) SCAN
|
完成此命令后，我们可以看到和WSBind 相关的WEBSERVICE 和URIMAP被自动安装，通过如下两条命令可以查验：
列表 2. 加载查验命令
CEMT INQUIRE WEBSERVICE(WDZPARTS)
CEMT INQUIRE URIMAP(*)
|
此 WEBSERVICE 的名称从 WSBind 文件的前 31 个字符中派生出来。如果成功执行第一条命令，我们可以看到自动生成了一个 URIMAP 资源。此 URIMAP 资源将一个本地 URI 映射至 WEBSERVICE 资源。
步骤四：使用Web Services Explorer测试基于CICS的Web service
这一节，我们可以通过Web Services Explorer来测试上述我们部署好的CICS based Web service。首先从CICSWS项目中选中WDZPARTS.wsdl文件，选择Web Services-Test with Web Services Explorer。
图 16. 使用Web Services Explorer测试
这时，我们可以看到WDZPARTSOperation是可以用的，单击WDZPARTSOperation的链接，输入PartNo就可以进行测试。
图 17. 测试结果
至此，我们已经可以通过Web Service访问在CICS运行的COBOL库存应用。
Service Flow Modeler
利用SFM工具实现top-down的方式根据已经定义好的WSDL接口生成请求/响应消息处理的适配器以及流程和接口之间的数据转换适配器。在样例中，用户已有的目录COBOL应用中，既有根据SKU查询零部件的生产日期，生产商等等详细信息的COBOL应用；也有根据SKU查询零部件的标价的COBOL应用，为了减少Web service的调用开销，我们将上述两种应用封装起来，成为一个新的Web Service-根据SKU同时查询零部件的生产信息和价格信息；下面便是定义好的 WSDL文件：
列表 3. To-Be Web Service的WSDL
< ?xml version="1.0" encoding="UTF-8"? >
<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://operation.lookupPartsInfo.org/Schema/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
name="LookupPartsInfo" targetNamespace="http://operation.lookupPartsInfo.org/Schema/">
<wsdl:types>
<xsd:schema targetNamespace="http://operation.lookupPartsInfo.org/Schema/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="LookupPartsInfoResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="partSKU" type="xsd:string"></xsd:element>
<xsd:element name="partNo" type="xsd:string"></xsd:element>
<xsd:element name="listPrice" type="xsd:string"></xsd:element>
<xsd:element name="sellPrice" type="xsd:string"></xsd:element>
<xsd:element name="manuDate" type="xsd:string"></xsd:element>
<xsd:element name="manuName" type="xsd:string"></xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="LookupPartsInfoRequest">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="partSKU" type="xsd:string"></xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<wsdl:message name="outMsgs">
<wsdl:part element="tns:LookupPartsInfoResponse" name="LookupPartsInfoResponse"/>
</wsdl:message>
<wsdl:message name="inMsgs">
<wsdl:part element="tns:LookupPartsInfoRequest" name="LookupPartsInfoRequest"/>
</wsdl:message>
<wsdl:portType name="default">
<wsdl:operation name="getPartsInfo">
<wsdl:input message="tns:inMsgs"/>
<wsdl:output message="tns:outMsgs"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>
|
接下来我们将展示如何把已有的COBOL应用组合为满足上述WSDL定义的Web Service。
步骤一：创建SFM项目
首先我们需要切换到WDz切换到Service Flow Modeler视图。在SFM Project Explorer 中点击创建一个新的SFM项目，这时候我们可以看到如下的向导：
图 18. 创建新的SFM项目
加入相关信息后我们得到了一个名为Catalog的SFM项目。注意在向导中服务接口和终端的此时不需要定义。
图 19. 创建SFM项目选项
然后下载附件中的文件ivp_manu.cpy，ivp_price.cpy和lookupPartsInfo.wsdl，并拷贝到Catalog项目的目录下。
这时我们便可以将需要实现的Web service的WSDL文件导入，单击右键，选择导入WSDL文件：
图 20. 导入需要实现的Web service的WSDL文件
从目录中选中lookupPartsInfo.wsdl文件，将其导入Catalog.Interface 项目。
图 21. 将WSDL文件导入Catalog.Interface 项目
然后，我们可以看到在Catalog.Interface生成如下的文件：
图 22. Catalog.Interface 项目中生成如下文件
创建一个新的流程(flow)，选择先前导入的getPartsInfo操作作为该流程所要实现的目标操作。这时生成了一个cataloglookup_flow.seqflow的流程文件和一个cataloglookup_flow.seqmap 的消息映射文件。至此，我们已经根据定义好的WSDL文件生成了一个SFM的流程框架。接下来将讲解如何导入COBOL的记录定义。
图 23. Catalog.Interface 项目中生成的流程文件
步骤二：导入COBOL的COPYBOOK文件
在SFM Project Explorer，单击右键选择倒入COBOL，这时候呈现出COBOL文件的导入向导：
图 24. 导入COBOL的COPYBOOK文件
选中ivp_manu.cpy文件，将其导入到Catalgo.Nonterminal项目中。然后遵循同样的操作将ivp_price.cpy文件也导入。分别生成了对应的两个消息文件，结果如下：
图 25. 导入COPYBOOK后的消息文件
我们根据上述两个消息定义文件在Catalog.Nonterminal项目中创建相关的主机操作文件：
图 26. 主机操作文件
我们以lookupPartsPrice操作为例，说明这个过程。新加lookupPartsPrice操作后，我们为这个操作增加相关的输入和输出，并将这些输入和输出联系到ivp_price的消息定义。具体操作如下图所示。同样的步骤，我们创建lookupPartsManu操作。
图 27. 创建主机操作文件过程
完成上述步骤后，我们在流程的定义中增加对上述两个操作的调用结点，如图所示：
图 28. 流程的定义
然后我们将上述两个结点getPriceInfo和getManuInfo分别关联到lookupPartsPrice和lookupPartsManu操作。首先选择操作选取(Select Operation)操作：
图 29. 操作选取
然后从Catalog.Nonterminal项目中选中之前创建的lookupPartsPrice操作。同样，对getManuInfo结点，使之和lookupPartsManu操作关联。
图 30. 操作选取对话框
步骤三：配置流程中的消息映射
在两个结点之间创建一个连接的同时会在需要创建两个结点之间的消息映射(mapping)，消息映射是SFM模型中用于实现数据在不同结点之间流转的机制。有些类型结点的消息映射可以为空，但是对于Invoke类型的结点，其消息映射一定是非空的，因为，在invoke结点中，消息映射不但负责提供COBOL应用的输入信息，而且还会将COBOL应用的输出结果保存到SFM模型中。
对于上述例子，我们只需右键单击某一结点，选择打开映射编辑器，便可以为该结点添加消息映射。
图 31. 打开映射编辑器
在消息映射的编辑框中，我们可以在上部看到源和目标两个Pane。对于msg_IVPINPUT映射，我们选择inMsgMsg作为消息源，而将 msg_IVPINPUT作为目标消息。拖动inMsgMsg消息的partSKU项和msg_IVPINPUT消息的PART_SKU相关联。重复上述步骤，将相关的消息关联起来，最后对于结点lookupPriceInfo其消息映射如下图所示。
图 32. 建立消息映射关系
点击 Open Mappings -> SignOn_1ns_SignOn_1打开消息映射编辑器。仿照上述步骤，完成其余结点的消息映射后，我们得到了下面的完整的SFM项目。
图 33. 完成的SFM项目
步骤四：设置代码生成属性并生成运行时代码
在产生运行时代码之前，我们必须先创建生成属性文件，该文件包含了运行时的相关信息，允许SFM生成针对特定运行环境的代码。
在New Generation Properties中，我们可以配置流程的生成属性甚至为每个结点单独配置其生成属性。
图 34. 创建生成属性文件
最后我们将根据上述生成属性配置来生成运行时代码。需要指出的是这些运行时代码，COPYBOOKS和JCL必须拷贝到z/OS主机系统中，并且在CICS环境下重新编译和安装它们。关于这一点在4.1节中已有叙述，在此不再赘述。关于CICS应用更详细的技术资料，可在问候的参考文献中获得。
总结
本文介绍了利用WebSphere Developer for zSeries V6.0中XSE和SFM 将既有应用转化为Web 服务的基本步骤和方法，并提供了一个详细样例来帮助读者更快的进入角色和深入了解XSE和SFM。除此之外，本文也介绍了SOA实践中三种经典的开发方法，并以其中的两种为例，向读者阐述了这些朴素思想的具体体现，以期望增强读者对于既有应用如何转化为SOA enable服务的相关开发的理解。
下载 | 描述 | 名字 | 大小 | 下载方法 |
|---|
| Sample code for this article | SampleCodes.rar | 10KB | HTTP |
|---|
参考资料
作者简介  | | | 任志宏：IBM 中国 SOA 设计中心，高级软件工程师，从事 SOA 及 WebSphere 相关的工作，对 J2EE，SOA 和业务流程管理有着浓厚的兴趣，联系方式: renzhih@cn.ibm.com。 |
| | | 陈雷： 是 IBM 中国 SOA 设计中心的资深软件工程师，从事 SOA 和企业整合相关的工作，对 J2EE，SOA 和相关的领域有着浓厚的兴趣，联系方式: cdlchenl@cn.ibm.com。 |
| | | 张森：IBM 中国 SOA 设计中心，高级软件工程师，从事 EMF，SOA 和 WebSphere 相关的工作，对J2EE，SOA 和相关的领域有着浓厚的兴趣。 |
| | | 刘伟：IBM 中国 SOA 设计中心，软件工程师，主要从事 SOAIF Tooling 的设计和开发工作。深入理解和应用SOA、SOMA、Web Services 等技术。个人兴趣：书法，绘画。联系方式:liuwcdl@cn.ibm.com。
|
| | |
张辉 IBM 中国 SOA 设计中心的软件工程师，主要从事 SOA Integration Framework 的研发，目前在做 SOA Domain Analysis 相关的工作。联系方式: cdlhuiz@cn.ibm.com。
|
对本文的评价
| 
