本文中，我们将提取遗留系统的服务组件并将其迁移为面向人的可发现 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 服务能够共享的存储库中，以供稍后进行分析和重新配置。