本文内容包括:
想要将遗留系统的服务组件迁移为面向人的 Web 服务吗？了解如何理清组件依赖关系以及如何将这些组件迁移为可发现
Web 服务。您将看到一些示例，可通过其了解如何在迁移过程中将 IBM? Rational? Requisite Pro? 和
IBM Rational ClearCase? 作为协作工具使用。
引言
系列文章“在企业级 SOA 中使用 Web 服务”的第 2 部分说明了如何将包含两个组件的企业遗留应用程序与 Web 服务进行链接，以便更为高效地处理频繁的服务更新。在第
9 部分，我们将 Web 服务作为多 SOA 环境中的后端遗留系统集成到 EAI 应用程序中。
本文是本系列文章的第 14 部分，我们将提取遗留系统的服务组件并将其迁移为面向人的可发现 Web 服务，同时将讨论遗留问题的解决方案。
回页首
遗留系统依赖关系
当规划在较新和较旧的大型机和服务器上开发和部署的遗留系统的迁移工作时，要考虑的两个关键问题是遗留系统依赖关系和 SOA 约束。
服务组件和运行这些组件所需的代码间的遗留系统依赖关系可能会非常复杂。例如，在大型机上运行的服务组件可能会直接调用服务器上的 Windows?
等特定操作系统来完成服务功能。相同的服务组件可能会通过接口与仅在 Windows 环境中提供的商业产品进行通信。
我们可以根据用户需求和目标环境的特征接受或丢弃依赖关系。必须对可以接受的依赖关系（如对 IBM DB2 产品的直接调用）进行分析，以确保所提取的服务组件不会带来冗余服务。如果所提取的服务组件提供类似的服务（如均通过
IBM Database Add-Ins for Visual Studio 2005 之类的接口连接），则应该进行合并，以提供单个服务功能，减少或消除服务冗余。
另一方面，如果不允许从服务组件调用 Windows 产品，或者服务组件中不允许使用其代码，则我们可能会需要替换相应的服务功能。可以采用这样的替换方法，即向用户提供独立的用户界面代码，用以调用遗留组件。
回页首
SOA 约束
第二个问题是有关迁移服务组件的六个 SOA 约束。它们分别是：
- URL 位置
- 数据转换
- 可重用服务组件
- 目标操作系统
- 外部发现
- 文档不足
接下来让我们对每个约束进行一下简单的分析。
URL 位置
如果没有 URI，SOA 就无法工作；需要使用 URI 来标识用于与由提取的遗留服务组件组成的 Web 服务通过接口进行通信的资源。SOA
对资源进行了标识后，就会通过 Web 服务间的消息（包括警报）操作资源。消息必须具有自我描述性，需明了易懂，以说明在生命周期的各个点是哪个服务获得或发送
XML 消息。
数据转换
虽然开发人员处理服务组件能够转换为 XML 格式的基本数据类型相当简单，但在转换复杂数据类型时可能会出现问题，此类数据类型包括用于在较新的遗留系统中构建基于
XML 的 Web 服务的音频、视频和图形。这意味着，必须使用另一种能够构建 XML 来操作复杂数据类型的语言替换用于构建遗留组件服务的编程语言。
可重用服务组件
为了能在迁移过程中有用，必须提取每个组件服务的功能，还必须将其依赖关系从遗留系统中清理出来。可以对这些服务进行重建，以允许将功能作为服务组件进行调用和重用，而且具有可接受的对其他服务的依赖关系（如果有）。功能的代码应该存储在
Web 服务能够共享的存储库中，以供稍后进行分析和重新配置。
目标操作系统
在目标操作系统上部署的完全提取的组件服务必须与其原始操作系统上的对等项相同或类似。例如，如果遗留系统是基于 Linux 的，则提取的组件服务必须部署在手持设备、轻量级便携式计算机或重量级工作站的类似操作系统上。如果遗留组件服务基于
Windows，则这些服务中的功能应该替换为在 Linux 操心系统上运行且能接受 IBM Database Windows Add-ins
之类的类似功能。
外部发现
如果提取的组件服务依赖于其他服务来完成一系列任务，则需要编写代码来发现和连接到其他服务。将这些服务放置在存储库中，以便应用程序能够发现和选择完成服务功能所需的服务。
文档不足
为了理解组件服务依赖关系，需要相应的文档来确定冗余情况、保留哪个部分以及丢弃哪个部分。缺少文档或文档不足（如手册、流程图、建模图和代码注释等）都可能对理解依赖关系造成困难。如果分析表明大部分文档都已过时，则需要构建一个相应的数据模型，以说明遗留系统的依赖关系的交织情况，发现要提取、替换或丢弃的组件服务中的功能冗余和缺失。另外，在对要迁移的服务组件进行变更的时候，还需要对所有的任务进行记录。
回页首
迁移服务组件
一个可能的解决方案是重建遗留服务组件的体系结构。而更好的方法是开发和编排 Web 服务，以提供从多个冗余服务组合而成的单个服务功能。
在进行体系结构重建或开发 Web 服务编排前，需要确定用户对服务功能的需求以及目标环境（如手持设备、便携式计算机和工作站）的特征。您还需要访问有关遗留服务组件的文档——手册、流程图、代码注释等。如果文档不足，则可以使用
IBM Rational Requisite Pro 对用户和环境要求进行分析。
重建
收集了所需的所有信息，将能够更好地确定如何重建体系结构。这包括如何记录理清依赖关系的复杂性以形成有组织的服务组件层次结构的过程。
作为重建过程的一部分，请确定供应商是否计划使用遗留系统的服务组件 Unix 版本。这将使得不需要对 Windows 操作系统或基于
Windows 的商业产品进行直接调用。
稍后可能需要变更对涉及法律方面的组件的处理方式。可以使用 IBM Rational ClearCase 来更为有效地对变更进行管理。
编排 Web 服务
可以与 DB2? 之类的 IBM 信息管理产品一起使用的那些依赖关系应保留在服务组件中。应该对无法和 IBM 产品一起使用的其他依赖关系进行分析，以确定应该丢弃还是替换组件。如果存在冗余，如
Net Visual Studio 外接程序等，则需要在 SOA 中开发编排 Web 服务来将冗余组件合并为一个服务功能。
图 1 显示了编排 Web 服务的工作方式。它首先接受从遗留系统提取的服务组件作为其子 Web 服务（我们称为 Redundancy
analysis 服务）的输入。如果 Redundancy analysis 非常繁忙，编排 Web 服务则将提取的组件路由到
Repository Web 服务，以稍后进行分析。分析的结果将说明是接受还是拒绝该服务组件。
图 1. 编排单个服务功能
如果接受，则随后将组件传递给另一个子服务，即 Service functionality，此子服务会将要合并的一系列组件服务编译为一个或多个单一服务功能。如果分析拒绝了组件，编排
Web 服务会向开发团队发送一个警报，以索取一个替代提取机制，并将其存储在 Repository Web 服务，供稍后进行面向人的分析工作。
回页首
Repository Web 服务
一旦 Service Functionality Web 服务成功地将冗余组件合并到服务功能或用其替换服务组件，就会随后将结果作为可重用资源存储在
Repository Web 服务。可以将其标记为已就绪，以作为输入构建新 Web 服务（即遗留服务组件的对等项）。如果不成功，Service
functionality 会将其存储在独立的类别中。还可以手动在存储库中存储一个预期遗留服务组件的列表，以供将来对访问时间、执行时间、Web
请求、带宽量和其他性能标准进行分析或研究。
总的说来，Repository Web 服务应该至少包含四个库：
- Reusable components
- Rejected components
- Extracted components
- Wish list
回页首
结束语
为了迁移并将现有服务组件作为 Web 服务向 SOA 公开，需要由开发人员、业务分析人员、系统管理员和潜在用户组成的团队彼此协作。需要事先对遗留服务组件的迁移进行规划，以在不会导致系统过载的前提下解决服务依赖关系和
SOA 约束的问题。编排 Web 服务可作为传统的遗留服务组件重建的替代解决方案，能更为灵活地分析服务组件，并将冗余服务合并为单个服务功能。
您将发现，通过解决这些问题，将服务组件迁移为可发现 Web 服务的工作会变得更为容易了。您可以使用 IBM Rational
RequisitePro 来管理需求层次结构。还可以使用 IBM Rational ClearCase 来通过更高效的变更管理来缩短构建/发布周期，从而提高工作效率。 |
