为何需要将遗留系统集成到 SOA 中

拥有遗留系统的组织对于采用 SOA 用于从其遗留系统获得最大价值的需求越来越大。遗留系统可提供大部分产生价值的业务流程，因为它们实现自动化的时间比其它现代系统更早。大部分自动化并不能有效地利用遗留系统，因为这些系统更旧一些，当时自动化专家还没有想过将其业务价值应用到自动化活动中。因此，任何旨在带来价值却没有将遗留系统包含起来的战略，其成功都有一定的限制。

开始时作为各自项目的重点区域的遗留系统逐渐失去了作为持续系统开发源的地位，因为常识认为只会有越来越多的技术成为旧技术。考虑到计算机技术的换代性变化已经缩短到三年一次，此处所述的问题会定期出现。

但很明显，您现有的遗留系统可以继续供您的企业用于改进现有流程。因此您在技术变更方面的业务战略应该将遗留系统包括进来。

本文将基于以下标准对组织中可能存在的各种遗留系统进行归类：

• 其运行所需的运行时环境是什么？
• 其开发针对的平台有哪些？
• 它们使用哪个用户界面环境？

遗留系统的运行可能会需要 Oracle Frames 之类的运行时环境，或者可能独立在操作系统上运行。能够直接在操作系统上运行的遗留系统可以较为容易地加入到 SOA 中来。在 DOS 或大型机系统上运行的系统就是这样的遗留系统。因此，最好谨慎地选择所使用的语言和技术。

遗留应用程序可以根据所使用的用户界面分为多种类型，包括：

• 绿屏应用程序。
• 不基于 GUI 的应用程序。
• 基于客户机/服务器的 GUI 应用程序。
• 基于 Web 的应用程序。

其中，在与基于 SOA 的应用程序进行集成时，由于其固有的本质，基于 Web 的应用程序和基于客户机/服务器的 GUI 应用程序处理起来最简单。这些应用程序在服务提供者和 GUI 之间存在清楚的区别，因此很容易变成 SOA 的服务。但这并不意味着其他应用程序不能加入到 SOA 中，但这些系统需要添加消息传递机制才能成为 SOA 中的服务。

尽管此处已经给出了各种遗留应用程序类型，但本文剩下的部分将详细说明更多常见问题，在将遗留应用程序转换为基于 SOA 的应用程序时可能会遇到这些问题。本文将不讨论各种遗留应用程序的独立处理方法。

回页首

确定应该将哪些遗留系统包括到 SOA 中来

务必注意遗留系统与 SOA 集成时所面临的挑战，想通过一个阶段就完成为所有应用程序实现 SOA 支持是一种错误的想法。这可能会让这一个阶段更为复杂，从而极大地降低成功的几率。

要确定哪些遗留应用程序应该启用 SOA 支持，请按以下方法进行：

• 按照其提供的业务回报和组织为了继续使用其而产生的维护成本对所有遗留应用程序进行分类。
• 考虑机会成本：由于应用程序未启用 SOA 支持而未加利用的潜能有哪些？

业务价值高的应用程序应该为加入 SOA 中的首批应用程序。另外，发挥潜能不多的应用程序也是进行转换的优先备选项。

回页首

标识服务和业务的价值

确定了候选遗留应用程序后，同样重要的是要标识服务候选者。此工作可决定整个转换工作的成功程度。

这是一个包括两个阶段的过程：阶段 1 需要标识能够将哪些定义为服务。阶段 2 处理您能够认识到的某些服务而不是其他服务所带来的业务价值。

阶段 1：标识服务

将业务流程标识为服务时，应该检查以下事项：

• 输入和输出参数的数量不应太多。如果数量多，则通常可以将此业务流程拆分为多个服务。之所以这样做，其原因很简单：形成服务后，参数与本机格式之间的转换可能会需要相当长的时间。
• 服务应该执行单个功能。要让服务保持尽可能小，粒度活动将处理这个问题，以便在更多的场景中方便地使用。
• 每个服务应该具有一个业务功能而不是 技术功能。您应该严格地避免出现没有对应业务流程的技术服务。这是因为业务分析人员并不能很容易地理解技术服务。SOA 最重要的目的之一是让业务分析人员理解服务。

接下来我们举例说明标识潜在服务的工作，假定我们现在有一个订单输入应用程序，其基本操作如下：

• 确认客户的可信度。
• 减少库存。
• 向客户开具帐单。
• 返回订单。

上面每个操作都可能是潜在的服务。不过，务必注意，基本业务操作（如减少库存）可以直接在其它上下文中重用。但向客户开具帐单是太过复杂的操作，因此必须将其进一步划分为：

• 聚合帐单编制项目。
• 计算销售税。
• 获得客户地址数据。
• 生成帐单。
• 发送帐单。

阶段 2：选择能在 SOA 中推动更多业务价值的服务

第二个阶段涉及选择从 SOA 环境中业务价值的角度而言更为合理的服务。选择服务的标准与选择候选应用程序的标准类似，但有一些差异。所选的服务将具有较高的价值系数。潜在服务的价值系数可以定义为：

（服务的业务价值 – 维护成本）/替换成本

因此，业务价值最大、业务成本最小且替换成本最小的服务是作为服务包含到活动中的最佳候选项。例如，如果服务的某段代码分布在多个模块和文件中，则会带来大量的维护成本。

您可以按照语言、用途、类型和关键性对现有服务组件进行归类。项目价值的计算基于开发成本、维护成本、估计替换成本和该项目带来的年度业务价值的分析。

“打捞”遗留代码

此流程的早期步骤之一是从遗留应用程序“打捞”代码（以便重用）。要从现有遗留代码库收集代码，首先必须找到这些代码并确定其重用价值。分析和评估分布在少量小程序中的代码没有什么问题，任何熟悉代码的人都可以使用简单的文本编辑器进行此工作。如果分析数百个大型程序来寻找可重用代码块，这将完全是另一回事。这里也许需要该领域专家，但他或她必须拥有自动反向工程工具的支持，如 Refine/C、Imagix4D、Sniff+ 和 Rigi。

在获取遗留代码过程中最重要的需求之一是标识代码所表示的业务流程。发现业务操作的一个简单方法是对其产生的结果进行分析。也就是说，您必须通过执行的遗留代码的结果标识业务流程。这可帮助在不用进行大量细致工作的情况下了解业务流程。通过确定处理业务操作的功能返回的变量，也可以标识功能。如果程序的结构设计合理，业务功能分配到单个代码块，如 C 或 COBOL 中的代码段，则此任务很简单——但很少出现这种情况。业务功能更可能分散在多个模块的多个代码块中。另一方面，一个代码可能处理多个业务功能。因此代码块与业务操作之间存在多对多的关系。

通过基于最终结果执行数据流分析，可以将结果回溯到对生成此结果有影响的所有语句。标识了语句之后，然后就可以确定各个语句在哪个代码单元（程序、段落等）中。然后仅从原始位置复制这些单元，并带上其引用的变量。此技术通常被称为代码剥离 (code stripping)。

标识了业务操作的代码后，下一步是提取代码，并将其重新组装为具有自己接口的独立模块。此工作是通过以下方式实现的：将受影响的代码单元复制到公用框架中，并将其引用的所有数据对象放置到公共数据接口中。在 C 中，接口是 type 结构的参数，而在 COBOL 中，对象是 linkage 部分中的一级项目。在所有情况下最终的结果都是带有调用接口的子例程。原始输入参数成了输入参数，而原始输出参数成了输出参数。从这个角度而言，业务逻辑代码已从原始用户界面断开，成了一个独立的子程序。这是对其进行包装的先决条件。

包装所获得的代码

找到了与业务操作对应的代码，对其进行记录并发现有重用价值后，下一步就要对其进行包装了。包装流程的目的是为了得到从遗留代码中提取的组件的 Web 服务描述语言（Web Services Description Language，WSDL）接口。此方法要求将每个条目转换为方法，将每个参数转换为 XML 数据元素。数据结构成为了包含一个或多个子元素的复杂元素。方法将其参数和结果作为引用添加到数据元素描述中。方法和参数都构建到 XML 模式中。

市场上目前有多种工具可用于为 COBOL 和 C/C++ 实现此转换的自动化。除了创建 WSDL 接口描述外，还通过两个额外的模块对包装的组件进行了增强：

• 一个模块用于分析传入消息并从其提取数据。然后会将所提取的值分配给包装组件中对应的参数。
• 另一个模块用于从包装组件产生的结果创建返回消息。通过这样，可以将基础操作作为 Web 服务使用，而不用更改代码。

所生成的两个子例程充当 WSDL 接口与原始代码的调用接口之间的桥梁。

将服务链接到业务流程中

从遗留代码创建 Web 服务的第三步（也是最后一步）是将 Web 服务链接到上层的业务流程。可以通过代理组件实现此工作。业务流程实际上调用代理，代理通过与流程定义相同的地址空间提供。与在 CORBA 中一样，代理检查参数并生成 WSDL 接口，然后将由某个消息服务（如 IBM® WebSphere® MQ）发送到应用服务器。

在应用服务器上有一个调度程序，将负责接收传入消息、确定要执行哪个 Web 服务并将 WSDL 内容转发到该服务——这种情况下，即包装的遗留代码。代码的包装将解析 XML 输入数据，并将值传递到包装组件中相应的位置。

包装组件执行之后，其结果将由包装转换为 XML 输出数据结构，此结构将返回调度程序，以传送回 Web 客户机。通过这样，业务流程可以在任何位置的任何客户机上执行，而且仍然能够访问原始应用服务器上的遗留功能。

回页首

结束语

分享这篇文章…… 提交到 Digg 发布到 del.icio.us Slashdot 一下!

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
  
  
• 阅读“开发从遗留的企业 IT 基础架构到基于 SOA 的企业架构的移植策略”。
  
  
• 查看“SOA 解决方案中涉及的遗留系统的设计策略”。
  
  
• 阅读“Adapting legacy systems for SOA”。
  
  
• IBM developerWorks SOA and Web services 专区提供了大量的文章，以及关于如何开发 Web 服务应用程序的初级、中级和高级教程。
  
  
• 使用 IBM SOA Sandbox 进行试验！通过 IBM SOA 进行实际的亲手实践来提高您的 SOA 技能。
  
  
• IBM SOA 网站提供 SOA 的概述，并介绍 IBM 是如何帮助您实现 SOA 的。
  
  
• 了解关于 developerWorks 技术事件和网络广播的最新消息。请特别关注以下 SOA 和 Web 服务技术讲座：
  • Building SOA solutions and managing the service lifecycle
  • SCA/SDO:To drive the next generation of SOA
  
  
• 访问 Safari 书店，浏览有关这些技术主题以及其他方面的书籍。
  
  
• 查看快速的 Web 服务按需演示。

• 使用 IBM 试用软件开发您的下一个项目，可下载或索取 DVD 光盘。
  
  

• 参与论坛讨论。
  
  
• 参与 developerWorks Blog，从而加入到 developerWorks 社区中来，其中包括以下与 SOA 和 Web 服务相关的 Blogs：
  • Sandy Carter 的 Service Oriented Architecture -- Off the Record
  • Ali Arsanjani 的 Best Practices in Service-Oriented Architecture
  • Bobby Woolf 的 WebSphere SOA and J2EE in Practice
  • Eoin Lane 博士的 Building SOA applications with patterns
  • Kerrie Holley 的 Client Insights, Concerns and Perspectives on SOA
  • Simon Johnston 的 Service-Oriented Architecture and Business-Level Tooling
  • Sanjay Bose 的 SOA, ESB and Beyond