想要将遗留系统的服务组件迁移为面向人的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来通过更高效的变更管理来缩短构建/发布周期，从而提高工作效率。