一些技术刊物和IT分析师们曾多次强调SOA不是一种产品或者解决方案，而是一段旅程。如果说SOA是一段旅程，那么遗留SOA现代化是一个你用来“打包额外衣物”的客栈。这是因为你的遗留SOA现代化旅途将会遇到意想不到的曲折，并且在旅途中随着企业目标，关键人员和技术的变更，你将会经过一些意想不到的地方。
 
　　我们将使用一组我们遇到过的常见的遗留SOA情景，在你走向现代IT平台的旅途上帮助你。然后我们对每一种用例应用我们已经发现的成功的设计模式。

　　用例一 ——遗留SOA企业信息集成（EII）

    也称为：数据集成，文件共享，文件信息

　　问题

　　我们当前为信息集成建立的基于大型机的基础设施又脆弱，又昂贵，并且难以维护。

　　这个问题的特点往往是没有共同的工作流方法，缺乏对数据质量和数据分析的能力和对每个订阅数据源定制的转换逻辑，实时监测能力不足，无法迅速添加新的订阅数据源。

　　背景 

　　数据需要在开放系统开发上的新系统，其他大型机系统，及内部的和外部的公司和/或我们效力的组织之间共享。

    几乎所有的大型机系统都有数据订阅源融入它们，或脱离它们。这些数据订阅源通常由调度作业系统控制并且在夜间批量地循环运行。

　　影响

　　过去应用和组织是独立的，而现在在应用和企业之间共享信息成为一种迫切的需要。

　　解决方案 

　　用例一架构概要

　　遗留SOA集成的目标是不破坏当前业务流程和遗留系统。对这而言，我们通过保持相同的数据订阅源来使其有效。尝试对数据订阅源做很小的修改几乎是不可能的，因为：

• 如果有第三方或者甚至你控制的之外的组织参与其中，即使拥有完全修改的能力，也要花好几个月。
• 由于内部拥有的数据订阅源对源系统，当前进程和目标系统都产生影响，因此即使一个小小的改变也会产生连锁效应，导致需要好几个月来修改。

　　目前的数据订阅源将保留并下载FTP到一个目录，同时将最有可能保持批量下载。上图显示了当业务流程发生变化时，可以采用像遗留适配器和Oracle消息这样的技术。

• Oracle ESB（Oracle企业服务总线）—Oracle ESB将使用文件或者FTP适配器来读取平面文件，然后将平面文件转化成通用的（标准的）XML文件格式。基于数据订阅源的来源，消息将被路由到适当的Oracle BPEL进程中。
• Oracle BPEL（Oracle业务处理执行语言）—这是我们前面讨论时提到的工作流和处理所发生的地方 ：
• Oracle BPEL会调用Java或者Web服务的处理来完成任何验证过程。验证过程可能访问Oracle数据库，基于数据库中数据来验证信息。

　　验证之后，特定文件类型处理才会发生。基本上是把“业务规则”应用到输入数据文件。这个业务处理可以调用Oracle规则引擎（我们将在第六章讨论这个话题）。

　　常见错误处理—验证和/或业务规则处理错误将被传递到一个错误处理路由。BPEL工作表会被填充，所以人们可能需要纠正问题文件或记录。

　　数据持久性Web服务—数据会在Oracle数据库，IMS数据库和/或Oracle Ebusiness套件中持久化。