可惜的是，许多公司已经着手搭建一个可称为“偶然架构”的架构，而这些公司的系统都已经拥有超过10年的寿命。这个架构就像一碗意大利面条，每一根面条代表一个系统，而所有这些面条的每一个交错点都代表了这些系统之间的一个集成点。这个偶然架构是利用了RPC、FTP消息队列以及许多其它集成技术经历多年时间才发展起来的。但是，这个架构非常复杂，而且很难进行简单的替换或重写操作。
那么，你为什么还要关心这个早已过时、难以操作并且脆弱、简陋的主机系统呢？因为你是一个Java/J2EE开发员，你每天都要和Web服务、BPEL过程管理器和ESB打交道。而《软件开发》杂志的一次调查表明，“……47%的SOA应用中都有主机应用的踪影。”这意味着在一个SOA项目中，你大概有50%的几率要和旧主机系统打交道。
SOA很容易被炒过头，而且经常被IT供应商们捧作软件架构的“圣杯”。然而，在这个“旧资产现代化”的环境下，SOA集成架构可以把一个旧系统引入到互联网、Web2.0以及所有以网络为基础的***的IT架构中。然后，用不了多久，你就可以通过网页来访问一个旧系统了。这正是SOA相对其它旧系统集成技术的***优势。你的上市时间是以周为单位的，而不是月或年。我们现在生活在一个关注时间短且需要获得即时满足的时代里；我们不再需要早报，因为我们从网络上得到所需的信息。我们的现代化旅程要能够反映这些变化。因此许多旧资产的现代化项目选择了SOA集成作为***阶段。
旧资产的SOA集成：主机上的集成点
开始之前，我们先来看看SOA利用主机系统的几种方式。我们可以使用各种各样的旧组件。旧组件是指主机上的具体的逻辑、显示和数据，是业务用户需要访问的部分。我们不能只看集成点，还要了解选择旧组件或访问方式的原因：
◆呈现层——即通常所说的“绿屏”。这是一个体积庞大的非智能终端机，是与主机系统进行双向交互的唯一方式。包括主机3270或VT220（DEC）传输设备、iSeries传输设备（5250）等。
为什么应用、数据等上面要有呈现层？因为这些应用源都是无法使用的。也可能是其它原因，比如由于安全或限制性因素造成的无法直接访问，或者应用中没有相应的流程或SQL。SOA只是运行主机应用并将显示、菜单和字段以服务的形式呈现出来。这种做法很简洁，速度也很快，而且最重要的是很方便。
◆应用——应用服务的实现并不是简单地把处理过程封装为Web服务。这包括系统性能的各个方面，也包括CICS/IMS事务、Natural事务、IDMS与ADS/O会话、COBOL程序和批处理程序等。它也包括业务规则、数据验证逻辑和其它事务的一部分的业务处理过程。
为什么要集成以应用为基础的旧系统？应用是大部分系统的核心。它包括显示、业务逻辑、业务规则、工作流、安全和旧系统的整体性能。主机系统上的事务是IT用户与系统交互的方式。因此，当你想重复利用旧系统上的既有功能，使用应用层就是最合理的一种方式。这种方式使你可以利用当前应用所有的行为（规则、事务处理流程、逻辑和安全）而无需在开放的系统上重新创建。
◆数据——旧系统上的数据可以是相关的或无关的。大多数情况下，旧系统上会有一个无关的数据存储，比如关键字文件、网络数据库或分级文件系统。在对旧系统上的数据进行读写操作的时候，SOA集成层将使用SQL这种简单易行的方式来访问所有的数据源。这一点很重要，因为许多企业可能更倾向于使用基于SQL的集成而不是基于SOA的数据集成。IT架构决定了在开放系统数据库中使用SQL语句比引入一套完整的SOA设施要简单得多。
为什么是数据？因为这是准确性的根源。它是你所需要的信息的储存之处。如果你使用了另外三个组件的任何一个，那么它们最终必然导致你需要一个数据存储。因此，让你所有的服务都以数据为基础就是顺理成章的了。有时候，安全和加密等方面的原因可能会使这里无法实现。还有时候，你需要先实现业务逻辑、业务规则、或者转换才能继续数据方面的工作。但是，如果上面这些还无法进行，那么直接开始数据源的工作也是个不错的选择。
◆其它——存储程序和SQL大多分布式应用访问数据存储的方式。存储程序也为应用性能、代码重用、应用逻辑封装、安全和集成提供了很大方便。
为什么要使用存储程序和SQL？因为你在转向分布式、开放的系统和关系数据库，而这些技术在这个环境下的表现相当不错。当然也要受到人力和技能方面的影响。你的开放系统开发人员必须熟悉存储程序，并能熟练地开发它们。
旧资产的SOA集成：四个典型案例
在各种技术期刊上，许多IT分析师都说过SOA并不是一种产品或方案，而是一个旅程。如果SOA是一个旅程，那么旧SOA资产的现代化则是一个"整理备用衣服"的旅程。这是因为旧SOA资产的现代化旅程可能会经历意想不到的曲折和艰辛，你会遇到业务目标、关键人员和技术发生变动的情况。
我们将分析我们所遇到的一系列常见的旧SOA资产现代化的实例来为你提供经验。在每一个实例的***我们还会提供一个实际有效的设计方案。
#p#
案例一：企业信息集成（EII）
也称为数据集成、文件共享、信息共享。
问题
我们当前用于信息集成的主机设备已经很脆弱，并且价格昂贵、难以维护。
典型的问题包括没有统一的工作流程、缺乏数据质量、数据剖析能力低下、各数据专线都使用特定的传输逻辑、没有实时监控的能力、并且无法迅速地添加新数据传送专线。
背景
需要与公司内外部的新系统和其它主机系统上开发的新系统共享数据。
几乎所有的主机系统都有数据传送专线来传入或传出数据。这些数据专线通常都由一个每日进行一次批处理的工作流程管理系统控制。
动力
以前应用和企业是各自独立的。现在应用与企业之间产生了对信息共享的巨大需求。
解决方案
架构概述
旧资产的SOA集成的目标并不是分解当前的业务过程和旧系统。我们之所以保留了数据专线也是出于这个考虑。要想对数据专线做出哪怕很小的改动也是不可能的，因为：
◆ 如果涉及第三方团队，或者甚至是只牵涉到企业内部不受你控制的一个团队，完成这项工作也要花费数月的时间。
◆即使是内部数据专线也影响着源系统、当前的过程和目标系统，以至即使是很小的一个改动也会产生连锁反应，使这项工作花费数月时间。
当前的数据专线将继续保留。图表显示了诸如Legacy Adapters和Oracle Messaging等技术，业务过程发生变化时可以对其进行调整。
◆ Oracle ESB—Oracle ESB将使用文件或FTP适配器读取平面文件，然后将平面文件转换为普通（标准）XML文件格式。消息将根据源或数据专线发送到相应的Orcale BPEL过程。
◆Oracle BPEL—这里是接收我们前面讨论的工作流与处理过程的地方：
Oracle BPEL将调用Java或Web服务过程进行所有的验证处理。验证过程可能会调用Oracle数据库并根据数据库里的数据验证信息。
验证之后即进行特定文件格式的处理，也就是将“业务规则”应用到输入数据文件。这个业务处理过程将调用Oracle业务规则引擎。
常规错误处理--验证和/或业务规则处理错误将被发送到错误处理路由。结果填充到BPEL工作表，然后工作人员便可以更正问题文件或记录。
数据持久性Web服务--数据将储存在Oracle数据库、IMS数据库、和/或Oracle电子商务套件中。
案例二：旧资产的Web使能
亦称为屏幕抓取或接口重连。
问题
我们的售后服务人员、业务代表、顾客和合作伙伴希望能通过网络访问我们的系统。为什么不能使用一个接口同时更新旧系统和Oracle系统呢？
旧"绿屏"技术有许多限制。其中一个很大的问题是这些技术不是很直观。你必须访问多个屏幕或系统才能得到所需的信息，也不支持点击操作。另外，很多时候用户可能需要使用多个系统来查询或更新同样的或相似的数据。
背景
用户希望能在任何地方任何时间得到他们想要的数据。用户还希望他们的旧系统能和新的Oracle环境融合。
一个需要用户查询多个系统、然后更新多个系统的业务过程会大大地降低工作效率，并且很可能导致数据不一致。
动力
我们看到网络用户的年龄非常年轻化。而且提供更好的应用接口的技术多年以前就已经成熟了。
解决方案
架构概述
这个案例的关键是接口。所以我们选用了Oracle WebCenter和/或JSP/JSF。开始的时候我们可以选择使用JSP和/或JSF保持开发的简洁并迅速部署。在更成熟的阶段可以使用JSF来开发JSR-168 portlet，并用Oracle WebCenter或其它类似技术进行部署。
#p#
案例三：旧系统利用数据迁移制作卸载报告
也称为旧操作数据存储、报告现代化、业务智能整合。
问题
IT说：我们的旧报告设施已经花费了几百万美元，还积压了六个月的报告单。
用户说：我手上已经有100多张条纹报表，但我仍然无法根据这些信息做出决策来。
背景
用户需要不同格式与规格的信息。他们还希望能简单地做一些特定条件和假设条件场景。
许多以主机为中心的企业经常要在每张电子表格上都做一遍销售预测。
动力
在主机上做报告是一笔庞大的支出，而业务用户通常还无法得到他们做决策时所需要的信息。因此企业经常发现他们的用户使用Excel、SQL或其它桌面工具自己生成报告。这样就造成了数据在整个企业的分散复制。
解决方案
架构概述
在Oracle Bam系统中，终端用户和决策制定者都能实时查看传入报告系统的***信息。终端用户决策制定者可以根据***的消息制定实时决策。不管是每分钟读取的数据量减少，或是用户报告的响应时间发生变化，只要资料读取速度变慢，IT管理部门马上就能收到警告信息。
可以使用BPEL编排传入Oracle数据库的信息流。BPEL可以根据传入时间或具体文件的传入或持续寻找可读取的数据来规划数据读取。
Oracle数据集成器（ODI）提供了一个可以快速地批量读取数据到Oracle报告数据库的方式。通过它可以访问数据转换、数据整理和数据管理服务。ODI是完全支持Web服务的，任何ODI组件都可以被Oracle BPEL、Oracle ESB或其它任何Web服务使能工具或产品使用。
案例四：端对端SOA
也称为软件即服务，旧资产的SOA集成。
问题
这个旧系统真是一个“黑盒子”。向内部输入信息是一件相当费力的事情，而要从中获取信息则更让人头痛。而我对其中运行的业务过程也一无所知。
背景
你的主机系统已经无法让你明白业务是如何运转的。旧系统难以维护、改善或者为内外部客户添加新服务（发布产品）。
动力
用户团体要求能够实时对信息进行处理并可以马上得到结果。系统的信息集成接口几乎以周为单位发生变化，而新的贸易伙伴甚至希望能每天与你保持联系而不是一个月才联系一次。系统接口需要根据情况进行定制，这样内部高层用户可以看到所有信息，销售人员只能看到相关的销售数据，顾客只能看到他们自己的数据和订单，这样公司管理人员能够实时地获得业务的***状态报告而不是只能看到几个星期以前的状态报告。
解决方案
架构概述
既然我们要为用户提供定制的视图，那么WebCenter或类似的技术显然就是最简单而且最有效的选择了。
BAM在这里发挥着相当重要的作用，处理量增加时更是如此。BAM可以在单个屏幕上监控所有的业务过程和服务。
就像ESB被用来从其它系统集成数据并提供集成总线一样，在这里ESB也被用来接收两种不同格式的文件并统一进行处理。
总结
阿伯丁（Aberdeen）集团曾经说过：“利用SOA集成旧系统上的旧应用的组织已经超越了那些使用其它方式的组织。他们的旧资产集成项目具有更高的效率、更高的敏捷性和更低的成本。”虽然这只是IT分析公司的一家之言，但是它确确实实地表明了SOA集成在企业旧资产现代化中的重要性。因为更快的（以月为单位而不是年）旧资产的SOA集成不仅能带领一个组织进入21世纪，它还能允许客户自行进行集成并提供统一的业务过程和更敏捷的IT基础设施。
