在本文中，作者使用中间会合 (meet-in-the-middle) 开发模式，对既有资产进行抽取、分析、编排和映射，生成满足业务目标的可部署代码和接口定义文件，从而实现了对于既有资产的转换和重组。

既有资产（系统）

既有资产 ( 系统 ) ，是指部署在企业基础架构中的现有 IT 资产。通常，它与企业正在运行的业务过程结合，对推动企业完成既定的业务目标、实现相关的业务价值，有着重要的意义。怎样盘活既有资产，重用已有的代码，将它们向新的 IT 技术平台迁移和转换，提升既有资产的价值，是越来越多的 IT 架构师和技术人员非常重视的问题。对于当前的系统和应用，“代替”和“转换”都是实现盘活既有资产切实可行的方法，但前提条件是，所提供的既有资产（系统）对于用户需求来说是高质量、合理的。

图 1 说明了“代替”和“转换”对于利用和提升既有资产的影响。在整个应用程序生命周期中，使用“代替”或者“重构”的方式进行应用程序的开发，会大大提高软件的成本，原有资产的核心价值没有得到充分的发掘和体现；如果使用“转换”的开发方式，重用已有的资产，并利用新的技术进行开发和集成，会逐步使企业更灵活和快速的响应业务变化，更好的服务于客户，从而提升既有资产的价值。

基于 SOA 的既有资产开发

SOA 理念及其技术的出现，为转换企业的既有资产提供了方法实践。我们可以依托 IBM 所提供的软件产品，利用 SOA 的方法论，开发和转换既有资产，并将其迁移到新的环境和平台中。例如：IBM 提供的 WDz (WebSphere Developer for System z) 软件，可以对一些既有资产进行组合、编排和转换，使其能够满足业务目标，生成可以运行部署的代码以及接口定义文件。同时，我们也可以使用 WSAA (WebSphere Studio Asset Analyzer) 对企业既有资产进行“统计”,“分析”和“管理”，为进行既有资产的开发提供符合目标要求的输入。

我们使用基于 SOA 的开发模式，要符合开发的实际情况和企业资产的现有形态。下面提供了三种模式：

(1) 自底向上 (bottom-up) 的开发方法：当用户期望从已有的应用创建一个新的服务时，应当采取这种开发方法。这时候我们需要生成对 Web Service 的描述以及指定已有数据结构和运行时的 XML 消息映射。例如对于一个已有的 COBOL 应用，首先选取接口的数据结构，然后生成部署所需要的供应商转换工件 (artifacts)。

(2) 中间会合 (meet-in-the-middle) 的开发方法：当用户已经拥有定义好的 WSDL 文件和已实现的应用或者组件的时候，这时我们需要开发附加的代码来实现上述二者之间的映射。例如定义在不同语言如：WSDL, XML, XSD 或 DTD 之间的数据结构映射。

(3) 自顶向下 (top-down)：采用这种方式，用户可以创建一个新的服务满足已有的 WSDL 定义。通常情况这种服务定义会是工业标准的一部分，可以由不同的服务提供商来实现。这种开发方法需要实现 WSDL 所定义的数据结构和提供对运行时的 XML 消息处理支持。

 

既有资产转换的目标是维护和提升资产在新的技术环境与平台中的价值。在实际情况中，转换实现的方法是多样化的。例如：转换可以仅仅涉及到源代码级别，也可以根据业务需求重用代码，并为消费者提供基于 Web 访问的能力。本文基于第二种情况，选取 COBOL 语言实现的资产作为要转换的对象，使用 WSDL 描述业务目标，设计和实现了 end to end 的转换场景。

在本文中，作者使用中间会合 (meet-in-the-middle) 开发模式，对既有资产进行抽取、分析、编排和映射，生成满足业务目标的可部署代码和接口定义文件。在开发过程中，主要涉及到以下产品和技术：

1．使用 WDz (Websphere Development for Z system)，进行资产开发和重组，按照业务目标，编排业务流程，进行接口和消息的映射，并最终生成可部署代码和接口描述文件。

2．使用中间会合的开发模式，开发和准备输入的材料，利用 SOA 规约整个场景的设计与实现过程。

本文样例是一个经过裁剪的零部件订单查询服务。在一个零售企业中，该服务可以为用户提供零部件订单及价格的查询，主要包含两部分功能：检查部件订单和检查部件价格。在本样例中，该服务实现的 COBOL 代码是由 CICS 应用提供，为了支持多种零部件的灵活查询，需要将上述应用转换为 Web Service。

作者使用 WSDL 描述实现目标和业务需求，对应的 COBOL 程序被作为在 WDz 中创建一个 Service Flow 工程的输入。下面是关于 WSDL 文件的定义细节，它完全匹配上述用例视图表述的需求，并定义了相关的输入和输出：

在这个场景中，作者使用 Service Flow 实现既有资产的开发和转换。在 WDz 中创建一个 Service Flow 工程，将导入的既有资产的源文件按照业务目标，使用 flow 的方式进行编排和组合，从而生成可部署的 Web Service。接下来，本文将详细介绍实现这个场景的开发技术和步骤。

WD z 与 SFPT

WDz (WebSphere Developer for System z) 主要针对在 IBM Z 系列大型机上运行的既有系统和程序，进行开发，部署和集成的工具，在最新的 7.0 版本中，它提供了以下功能：

1．指导用户部署应用程序到目标运行环境中，包括：WebSphere、CICS、IMS 等。

2．帮助开发者在 Z 系列平台中，创建、维护、调试和部署传统的事务型和批处理应用程序，并实现与 Web 的集成。

3．能够提升既有资产的重用和转换，帮助用户减少成本、缩短开发周期。

4．允许开发者迅速地创建结构良好的随需应变 (On demand) 系统，实现与 WebSphere 和传统的事务处理环境的集成，例如：CICS、IMS 和批处理系统。

5．支持 SOA、Web service 的创建和在 WebSphere、CICS 和 IMS 环境的部署。

6．提供基于 JSF UI 的可视化开发平台，支持 JAVA 和 EGL (Business-oriented Enterprise Generation Language) 语言。

EST (Enterprise Service Tool) 是集成到 WDz7.0 中的一个组件，SFPT (Service Flow Project Tool) 是它下面的一个子项目，在 WDz6.0 中叫做 SFM (Service Flow Modeling)。使用它，创建一个 Service Flow 工程，导入不同的源程序或片断，根据业务目标，进行流程编排、组合和接口及其消息的映射，从而生成可部署的 Web Service 和运行代码，并创建 MVS 应用的连接器。下图描述了 SFPT 的结构和它相关的 artifacts：

一个完整的 Service Flow 工程包含下面几个部分：

• Flow

  在一个 SFP 中，要实现不同的既有系统之间的组合、转换，需要创建一个对应的 flow，对既有系统的接口按照特定的业务需求进行编排，对接口之间的输入、输出进行关联和映射。结果，将会在该目录下生成一个用 EMF 描述的 flow 文件。

• Interface

  对于创建一个 SFP，需要有一个业务目标或者需求的定义，它使用 WSDL 进行描述，并导入到该目录下，生成对应的接口文件 (.wsdl) 和消息定义文件 (.mxsd)。

• Terminal

  支持基于终端的应用程序的导入，例如与 CICS 应用的交互，使用绿屏的命令方式。在 WDz7.0 中，用户可以导入 HATs Connections 和 HATs screens (3270, 5250) 到该目录下。

• Nonterminal

  在该目录下，支持非终端应用程序的导入，例如：COBOL ( 包括：.cbl 和 .cpy)、PL/I 和 BMS 文件。

• OutboundWebservice

  在 WDz7.0 中，SFP 增加了一个新的功能，它支持 CICS 的 Web service 的导入。

在 EST 工程中，所有文件的存储 (MXSD、WSDL、FLOW) 使用 EMF 实现，最后产生的运行代码将部署在 CICS Service Flow Runtime 和 Host Access Transformation Services 中运行。

Service Flow 工程支持两种 SOA 开发方法：

1. 自底向上 (bottom-up) 的开发方法：从既有资产中实现一个 service。
2. 中间会合 (meet-in-the-middle) 的开发方法：当目标 WSDL 和实现的组件都被提供，需要创建两者之间映射和连接的代码。

在本样例中，使用了中间会合的开发方法。

由于文章篇幅过长，所以本文被分成两部分，您可以继续访问 。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-432960/，如需转载，请注明出处，否则将追究法律责任。