問題的提出 　　 數據集成是企業信息系統的核心部分之一，它作為一個統一的數據平臺為系統的其它部分提供數據支撐服務。許多企業擁有或將擁有多種業務系統，而每種業務系統都有自己的數據存儲庫，每個業務系統的數據從整體上來說一般是不完整的、不一致的。傳統的解決方案為整合數據，它往往需要形成集中庫，難以靈活適應底層數據源的變化。傳統的解決方案要求直接從數據存儲庫中獲取數據，并且只能從數據存儲庫中獲取數據，但數據存儲庫往往不被允許直接訪問，而且數據存儲庫中的數據常常是原生數據，它需要經過業務邏輯的處理才能成為有價值的數據，直接使用數據存儲庫中的原生數據是無意義的。因此，數據集成問題的關鍵是如何方便地得到需要的數據，如何進行正確的數據整合。 　　 本文提出一種實時動態數據集成的服務框架，這個框架的數據集成是動態的，不需要建立集中庫，數據集成是實時進行的；數據集成的數據源不局限于數據存儲庫，可以是一個應用、一個組件、一個服務，甚至可以將數據集成后的結果作為新的數據源。 SOA技術介紹 　　 SOA即面向服務架構，可以看作是一種軟件系統架構。它主要是為了解決在Internet環境下業務集成的需要，以松耦合和統一接口定義的方式將具有特定功能的組件作為服務提供者連接在一起完成特定的業務處理。SOA具有三大基本特征： 　　■ SOA架構中提供服務的功能實體具有完全獨立自主的能力，這樣不需要關心功能實體的實現方式和運行機制； 　　■ SOA架構中以低頻率對大量數據進行訪問，也就是在信息交換時希望一次性盡可能多地交換大量的數據； 　　■ SOA架構采用基于文本而非二進制的消息傳遞方式，消息本身是不包含任何處理邏輯和數據類型的，同樣不需要關心消息接受者的細節。 　　 XML和Web Services標準的成熟和應用的普及為廣泛的實現SOA架構提供了基礎。XML是針對包含結構化信息的文檔而設計的一種標記語言。采用這種描述方法，可以在保持原有數據的意義和結構的同時在應用之間進行數據交換，進而可以保持不同系統之間數據交換的靈活性。Web Services是基于最廣為接受的、開放的技術標準（如Http、SMTP、XML、SOAP、WSDL和UDDI等），支持服務接口描述和服務處理的分離、服務描述的集中化存儲和發布、服務的自動查找和動態綁定以及服務的組合，成為新一代面向服務的應用系統的構建和應用系統集成的基礎設施。 　　 Web Services可以定義為通過SOAP協議，在網絡上提供服務，使用WSDL來描述這種服務，并通過UDDI注冊服務以便使用者能找到服務。 　　 SOAP：這是Web Services的通訊協議，用XML格式來定義消息，即SOAP消息，包含在一對SOAP中的、結構正確的XML段。目前常基于HTTP協議來傳輸XML數據。 　　 WSDL：Web服務說明語言。WSDL文件也是一個XML文檔，Web Service的細節描述都包含在其中。如參數類型、函數名稱、返回類型、綁定協議等。調用者可以通過查看WSDL文件來確定Web Service的接口函數。 　　 UDDI：這是Web服務的注冊中心。Web Service提供者將其提供的服務注冊到UDDI注冊中心，調用者就可以到這個已知的UDDI注冊中心查詢到所需要的Web服務。 　　 Web Services提供者實現服務的接口函數和服務的描述，并將其發布給調用者或注冊到服務注冊中心。服務調用者通過查詢本地或服務注冊中心的服務描述，選擇所需要的服務進行綁定以調用Web Service的接口函數。服務的提供者以XML文檔的形式將服務結果返還給服務調用者，完成了信息的交互。圖1 是Web Services的體系結構。 [align=center] 圖1　Web Services體系結構[/align] 基于SOA的數據集成 　　 數據集成的本質是把不同來源、格式、特點性質的數據在邏輯上或物理上有機地集中，從而為用戶提供全面的數據共享。在數據集成領域已經有了很多成熟的框架。目前，通常采用數據倉庫和基于中間層的方法來構造數據集成服務。 　　 中間層模式通過統一的全局數據模型來訪問異構的數據庫、遺留系統、Web資源等。中間層位于各種數據源和應用程序之間，向下對各數據源起協調作用，向上為訪問集成數據的應用提供統一數據模式和數據訪問的通用接口。各數據源的應用仍然完成他們的任務，中間層則主要集中為各種數據源提供一個高層次檢索服務。中間層提供一個統一的數據邏輯視圖來隱藏底層的數據細節，使得用戶可以把集成數據源看為一個單一的整體。本文提出的基于SOA的動態數據集成服務框架就屬于中間層模式。 　　 在基于SOA的數據集成中，XML提供一種規范化的數據結構以協助整合系統之間不同的數據結構，并以關聯視圖的方式展現被集成的數據。以“同一種語言交流”不再是必須的，Web Services將作為一種規范的通訊方式允許某一部分動態地發現其它部分的能力和需求。因此集成是動態的，可以隨時根據需要組織數據的集成方式，得到不同的集成視圖；集成也是實時的，可以方便地獲取最新的數據。 　　 基于SOA的數據集成將傳統數據集成解決方案中，考慮不同系統中數據是如何交換的轉變為怎樣展現系統的功能，這樣數據將不再是以點對點的方式獲取，而是可以自由的在網絡上得到的一種服務。系統不是在底層協議的基礎上進行交互，而是在一個抽象的接口層面上進行數據交換。系統僅僅將它們的功能以服務的形式展現出來，其它的系統能容易地發現這個服務并在運行時或設計時綁定它。被集成的服務可以是任意的應用、系統和數據源，而不用考慮它們的特殊要求。 動態數據集成服務框架的研究 　　 框架技術體系 　　 圖2是基于SOA的動態數據集成服務框架的技術體系結構。從圖中可以看出，框架的技術體系由5個層次組成。分別是數據源適配器、服務包裝器、SOA運行引擎、XML視圖引擎、XML視圖。 [align=center] 圖2：框架技術體系結構[/align] 數據源適配器是同各種數據源進行交互的橋梁，它是一些可插拔的組件，并動態地進行加載。數據源適配器以遵從標準接口的方式進行編寫，可以獨立地為新的數據源編寫適配器，并很方便地接入到系統中。數據源的類型基本上是沒有限制的，即可以是數據庫也可以是位于Internet上的文本文件，甚至是一個應用系統。數據源適配器將存儲在各種數據源的原生數據轉換為標準的XML文檔。 　　 服務包裝器是將數據源適配器包裝成標準的Web Services服務，這樣就將對數據源的API訪問模式轉變為對服務的提供。服務包裝器可以同時包裝多個數據源適配器，這樣它的另一個重要作用就是可以對來自一個或多個數據源的原生數據進行進一步的邏輯處理以將其轉變為更有意義的信息，并可以在本地緩存處理后的數據。這樣通過緩存提高了整個系統地效率和可靠性——即使數據源出現故障系統也有能力繼續工作，同時將業務邏輯進行預先處理，降低了XML視圖的復雜性，使得XML視圖更易于被理解。服務包裝器隔離了對數據的訪問細節和對數據的邏輯處理細節，這兩個部分可以獨立地變化，極大地提高了系統的靈活性。 　　 SOA運行引擎是框架的核心部分，通過它調度服務的執行，驅動數據集成的處理。SOA運行引擎包括了規則處理器、流程處理器、消息處理器等。SOA運行引擎將XML視圖引擎解析的數據集成請求轉變為對服務的調用請求，并由運行引擎去查找適合的服務、綁定服務并調用服務。 　　 XML視圖引擎提供三種機制：其一，它將多個異構的數據源表示為單一的即時虛擬數據庫，這個即時虛擬數據庫由一系列實時獲取的XML文檔構成。其二，解析用戶來自XML視圖的請求，將該請求向下層傳達，并將最后結果以XML文檔的形式返還給用戶；最后，它將自己的元信息用XML Schema表達，這些XML Schema就是XML視圖的基礎，基于XML Schema進行XML視圖的定義。XML Schema就如同關系數據庫中的表一樣，而XML視圖就像關系數據庫中同表相關的表視圖（VIEW）一樣。XML視圖引擎本身也是以Web服務的形式提供，用戶可以很方便地以一種標準的方式訪問它，它也可同時成為另外的XML視圖引擎的數據源。 　　 XML視圖是對數據集成的元信息描述，由它表達集成后的效果。它并不是集成的結果，而僅僅是集成結果的元數據表示，就像關系數據庫中的表視圖一樣表示實際數據應具有的組成關系：數據來自于哪個表，對表數據需要作什么樣的處理，不同表的數據是如何結合的等。用戶查看XML視圖就能了解該視圖表達的數據集成的模式。可以根據不同的數據集成需要定義不同的XML視圖，這就是動態的數據集成——在需要時才定義集成的方式，在運行時才能獲得真正的數據。 　　 從圖2可以看出，這5個層次可以分為三個部分各自獨立的進行開發和分布式部署。其中，XML視圖和XML視圖引擎是一個部分，SOA運行引擎是一個部分，服務包裝器和數據源適配器是另一個部分。這樣的分布式數據集成具有極高的靈活性，三個部分互不影響；同服務包裝器一樣，可以同時部署多個XML視圖引擎，而XML視圖引擎又可以被服務包裝器封裝成為一個新的數據源。這種機制可以比較容易的滿足現代企業數據集成中復雜的環境，通過較小的代價達到靈活的數據集成要求。圖3是一個典型的部署方案。圖3中，XML視圖引擎B使用服務包裝器c，而服務包裝器b將XML視圖引擎B包裝成新的數據服務，XML視圖引擎A使用了服務包裝器a和服務包裝器b，也就是使用了服務包裝器a和視圖引擎B的某個XML視圖。 [align=center] 圖3：框架典型的部署方案[/align] 框架的運行機制是首先由用戶查看XML視圖，獲得該視圖上數據集成的元結構，基于該元結構發起合適的處理請求；XML視圖引擎根據處理請求中相應的XML視圖描述解析該請求，并將其轉遞給SOA運行引擎；SOA運行引擎這些請求轉變為對服務包裝器的調用；服務包裝器再將其轉變為對數據源適配器的調用，由數據適配器執行實際的數據源訪問；從數據源取回的數據經服務包裝器處理后轉變為標準的XML文檔送回到XML視圖引擎中；在XML視圖引擎中再根據XML視圖的集成方式描述完成實際的數據整合并將整合結果返還給客戶。從框架的運行機制可以看出，這時數據集成是實時的，每次的請求都需要即時到數據源中獲取數據。框架的基本運行機制如圖4所示。 [align=center] 圖4：框架運行機制[/align] 框架的結構 　　 在基于SOA的數據集成框架中，其面向服務的體系決定了框架內部各模塊之間的的關系：這些模塊按照SOA的觀點都可以視為服務，所有這些服務以松耦合的方式連接在一起。框架的核心部分SOA運行引擎的主要功能就是管理這些各種各樣的服務，協調服務之間的交互，同時使用戶能方便地存取這些服務。圖5是框架的總體結構。 [align=center] 圖5：框架總體結構[/align] 圖5中，內置服務是框架正常運行而必須具備的服務功能。這些服務是框架底層使用的，對用戶來說是不可見的。內置服務主要有：流程引擎，為框架提供流程定制和流程運行的功能；規則引擎，由它數據集成的規則，企業根據自己的業務規則通過規則引擎定義集成和處理的方式；服務注冊和發現服務，提供 Web Services的注冊中心和服務發現功能；消息處理器，提供消息處理機制，以便服務能以消息的方式交互。 　　 插件服務是框架具有高擴展性和靈活適應各種需求的主要機制。它將提供數據的各種數據源包裝成服務，并以可拔插的方式植入框架中。插件服務并不直接訪問數據源，而是通過數據源適配器訪問數據源，這樣將對數據源的訪問同服務的提供解耦，數據源適配器可以在運行時根據需要動態裝配。同時，插件服務還可以根據需要對其數據源適配器獲得的數據進行預先處理，以降低最終集成的復雜度，提高系統的整體運行效率。插件服務通過最小化的編程或僅僅進行配置就能擴展整個系統，具有極大的靈活性。 　　 代理服務是一種擴展的插件服務，由它提供對諸如第三方應用，如ERP、CRM等數據源的包裝以及對XML視圖引擎的包裝。代理服務和插件服務在對數據源的包裝上的主要差別在插件服務包裝的是具有明確API接口的數據源，如數據庫、EJB、COM、MOM、SOAP等，而代理服務包裝的數據源沒有明確的API接口，需要對這些數據源進行更多的處理。同時代理服務也是數據遞歸集成的機制，即將集成后的數據作為其他數據集成的數據源。 　　 服務管理器管理框架中所有的服務，是存取服務的入口，由它去查找正確的服務，管理服務的生命周期，檢察服務的運行情況，調度服務的運行、注冊服務等。服務工廠主要是用來生成各種服務。當服務管理器查找服務時，發現該服務還沒有運行，服務管理器將請求服務工廠動態生成并運行這個服務。服務工廠將根據服務注冊信息啟動該服務，如果服務包裝的底層數據源不可得，則該服務將企圖裝載在本地的緩存數據。 　　 存取控制模塊為安全使用服務和訪問數據提供了基礎。它的主要作用除了提供一個基于角色的存取控制外，還具有兩個重要功能。其一，它采用一種基于標記的用戶認證模型使得單一登陸就可以訪問多個數據源，極大簡化了用戶的訪問模式。其二，存取控制模塊還將處理用戶訪問會話的生命期，使得用戶只在一段特定的時間內訪問系統，這將進一步提高系統的安全性。 　　 服務存取信道是用戶訪問包裝了XML視圖引擎的服務的通道，并解析用戶請求成為一系列能直接訪問底層服務的查詢計劃。查詢計劃將被緩存，以便能盡可能地重用這些查詢計劃。當有新的請求時，服務存取信道將比較該請求以決定是否已經有可用的查詢計劃，如果有的話，就直接使用它，這樣極大地提高了系統的運行效率。一個服務存取信道可同時提供多個用戶使用。 　　 存取信道管理模塊提供了對服務存取信道的運行時管理，它將根據不同用戶的訪問請求，將可能返回相同數據的訪問請求合并成一個請求；或者對多個用戶訪問請求進行優先級排隊處理，以保障優先級高的請求能盡快被處理；或者將多個用戶小數據量的請求多路復用到一個服務存取信道，保證大數據量的請求有足夠的服務存取信道可用。通過這些機制，降低了系統的資源消耗，提高了系統的運行效率。 　　 服務發布/訂閱接口提供了同框架異步通訊的機制。各種服務可以在服務發布/訂閱接口訂閱需要的消息，當有適合的消息發布時，所有訂閱了該消息的服務都將得到通知，這是一種多對多的通訊機制。服務發布/訂閱接口也能同各種消息中間件相連，以便提供基于消息的服務互連功能。同時，通過服務發布/訂閱接口，框架將具有一定的事務處理能力。 　　 基于SOA的動態數據集成服務框架為異構異型數據的集成和共享提供了一個面向服務體系結構的框架，它以XML技術為基礎，動態集成為手段，實現各種應用系統之間的數據集成，實現跨平臺數據的共享，達到跨平臺數據資源整合的目的，實現了信息的互通互聯。基于SOA的動態數據集成服務框架可以為解決跨平臺數據共享和集成所面臨的異型異構接口、實時數據交換和隨需應變等技術問題，提供有效的解決方法和途徑。