可惜的是，許多公司已經著手搭建一個可稱為“偶然架構”的架構，而這些公司的系統都已經擁有超過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）

    也稱為數據集成、文件共享、信息共享。

    問題

    我們當前用于信息集成的主機設備已經很脆弱，并且價格昂貴、難以維護。

    典型的問題包括沒有統一的工作流程、缺乏數據質量、數據剖析能力低下、各數據專線都使用特定的傳輸邏輯、沒有實時監控的能力、并且無法迅速地添加新數據傳送專線。

    背景

    需要與公司內外部的新系統和其它主機系統上開發的新系統共享數據。

    幾乎所有的主機系統都有數據傳送專線來傳入或傳出數據。這些數據專線通常都由一個每日進行一次批處理的工作流程管理系統控制。

    動力

    以前應用和企業是各自獨立的?，F在應用與企業之間產生了對信息共享的巨大需求。

    解決方案

 

    架構概述

    舊資產的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基礎設施。