問題的提出
數(shù)據(jù)集成是企業(yè)信息系統(tǒng)的核心部分之一,它作為一個統(tǒng)一的數(shù)據(jù)平臺為系統(tǒng)的其它部分提供數(shù)據(jù)支撐服務。許多企業(yè)擁有或將擁有多種業(yè)務系統(tǒng),而每種業(yè)務系統(tǒng)都有自己的數(shù)據(jù)存儲庫,每個業(yè)務系統(tǒng)的數(shù)據(jù)從整體上來說一般是不完整的、不一致的。傳統(tǒng)的解決方案為整合數(shù)據(jù),它往往需要形成集中庫,難以靈活適應底層數(shù)據(jù)源的變化。傳統(tǒng)的解決方案要求直接從數(shù)據(jù)存儲庫中獲取數(shù)據(jù),并且只能從數(shù)據(jù)存儲庫中獲取數(shù)據(jù),但數(shù)據(jù)存儲庫往往不被允許直接訪問,而且數(shù)據(jù)存儲庫中的數(shù)據(jù)常常是原生數(shù)據(jù),它需要經過業(yè)務邏輯的處理才能成為有價值的數(shù)據(jù),直接使用數(shù)據(jù)存儲庫中的原生數(shù)據(jù)是無意義的。因此,數(shù)據(jù)集成問題的關鍵是如何方便地得到需要的數(shù)據(jù),如何進行正確的數(shù)據(jù)整合。
本文提出一種實時動態(tài)數(shù)據(jù)集成的服務框架,這個框架的數(shù)據(jù)集成是動態(tài)的,不需要建立集中庫,數(shù)據(jù)集成是實時進行的;數(shù)據(jù)集成的數(shù)據(jù)源不局限于數(shù)據(jù)存儲庫,可以是一個應用、一個組件、一個服務,甚至可以將數(shù)據(jù)集成后的結果作為新的數(shù)據(jù)源。
SOA技術介紹
SOA即面向服務架構,可以看作是一種軟件系統(tǒng)架構。它主要是為了解決在Internet環(huán)境下業(yè)務集成的需要,以松耦合和統(tǒng)一接口定義的方式將具有特定功能的組件作為服務提供者連接在一起完成特定的業(yè)務處理。SOA具有三大基本特征:
■ SOA架構中提供服務的功能實體具有完全獨立自主的能力,這樣不需要關心功能實體的實現(xiàn)方式和運行機制;
■ SOA架構中以低頻率對大量數(shù)據(jù)進行訪問,也就是在信息交換時希望一次性盡可能多地交換大量的數(shù)據(jù);
■ SOA架構采用基于文本而非二進制的消息傳遞方式,消息本身是不包含任何處理邏輯和數(shù)據(jù)類型的,同樣不需要關心消息接受者的細節(jié)。
XML和Web Services標準的成熟和應用的普及為廣泛的實現(xiàn)SOA架構提供了基礎。XML是針對包含結構化信息的文檔而設計的一種標記語言。采用這種描述方法,可以在保持原有數(shù)據(jù)的意義和結構的同時在應用之間進行數(shù)據(jù)交換,進而可以保持不同系統(tǒng)之間數(shù)據(jù)交換的靈活性。Web Services是基于最廣為接受的、開放的技術標準(如Http、SMTP、XML、SOAP、WSDL和UDDI等),支持服務接口描述和服務處理的分離、服務描述的集中化存儲和發(fā)布、服務的自動查找和動態(tài)綁定以及服務的組合,成為新一代面向服務的應用系統(tǒng)的構建和應用系統(tǒng)集成的基礎設施。
Web Services可以定義為通過SOAP協(xié)議,在網絡上提供服務,使用WSDL來描述這種服務,并通過UDDI注冊服務以便使用者能找到服務。
SOAP:這是Web Services的通訊協(xié)議,用XML格式來定義消息,即SOAP消息,包含在一對SOAP中的、結構正確的XML段。目前常基于HTTP協(xié)議來傳輸XML數(shù)據(jù)。
WSDL:Web服務說明語言。WSDL文件也是一個XML文檔,Web Service的細節(jié)描述都包含在其中。如參數(shù)類型、函數(shù)名稱、返回類型、綁定協(xié)議等。調用者可以通過查看WSDL文件來確定Web Service的接口函數(shù)。
UDDI:這是Web服務的注冊中心。Web Service提供者將其提供的服務注冊到UDDI注冊中心,調用者就可以到這個已知的UDDI注冊中心查詢到所需要的Web服務。
Web Services提供者實現(xiàn)服務的接口函數(shù)和服務的描述,并將其發(fā)布給調用者或注冊到服務注冊中心。服務調用者通過查詢本地或服務注冊中心的服務描述,選擇所需要的服務進行綁定以調用Web Service的接口函數(shù)。服務的提供者以XML文檔的形式將服務結果返還給服務調用者,完成了信息的交互。圖1 是Web Services的體系結構。
[align=center]

圖1 Web Services體系結構[/align]
基于SOA的數(shù)據(jù)集成
數(shù)據(jù)集成的本質是把不同來源、格式、特點性質的數(shù)據(jù)在邏輯上或物理上有機地集中,從而為用戶提供全面的數(shù)據(jù)共享。在數(shù)據(jù)集成領域已經有了很多成熟的框架。目前,通常采用數(shù)據(jù)倉庫和基于中間層的方法來構造數(shù)據(jù)集成服務。
中間層模式通過統(tǒng)一的全局數(shù)據(jù)模型來訪問異構的數(shù)據(jù)庫、遺留系統(tǒng)、Web資源等。中間層位于各種數(shù)據(jù)源和應用程序之間,向下對各數(shù)據(jù)源起協(xié)調作用,向上為訪問集成數(shù)據(jù)的應用提供統(tǒng)一數(shù)據(jù)模式和數(shù)據(jù)訪問的通用接口。各數(shù)據(jù)源的應用仍然完成他們的任務,中間層則主要集中為各種數(shù)據(jù)源提供一個高層次檢索服務。中間層提供一個統(tǒng)一的數(shù)據(jù)邏輯視圖來隱藏底層的數(shù)據(jù)細節(jié),使得用戶可以把集成數(shù)據(jù)源看為一個單一的整體。本文提出的基于SOA的動態(tài)數(shù)據(jù)集成服務框架就屬于中間層模式。
在基于SOA的數(shù)據(jù)集成中,XML提供一種規(guī)范化的數(shù)據(jù)結構以協(xié)助整合系統(tǒng)之間不同的數(shù)據(jù)結構,并以關聯(lián)視圖的方式展現(xiàn)被集成的數(shù)據(jù)。以“同一種語言交流”不再是必須的,Web Services將作為一種規(guī)范的通訊方式允許某一部分動態(tài)地發(fā)現(xiàn)其它部分的能力和需求。因此集成是動態(tài)的,可以隨時根據(jù)需要組織數(shù)據(jù)的集成方式,得到不同的集成視圖;集成也是實時的,可以方便地獲取最新的數(shù)據(jù)。
基于SOA的數(shù)據(jù)集成將傳統(tǒng)數(shù)據(jù)集成解決方案中,考慮不同系統(tǒng)中數(shù)據(jù)是如何交換的轉變?yōu)樵鯓诱宫F(xiàn)系統(tǒng)的功能,這樣數(shù)據(jù)將不再是以點對點的方式獲取,而是可以自由的在網絡上得到的一種服務。系統(tǒng)不是在底層協(xié)議的基礎上進行交互,而是在一個抽象的接口層面上進行數(shù)據(jù)交換。系統(tǒng)僅僅將它們的功能以服務的形式展現(xiàn)出來,其它的系統(tǒng)能容易地發(fā)現(xiàn)這個服務并在運行時或設計時綁定它。被集成的服務可以是任意的應用、系統(tǒng)和數(shù)據(jù)源,而不用考慮它們的特殊要求。
動態(tài)數(shù)據(jù)集成服務框架的研究
框架技術體系
圖2是基于SOA的動態(tài)數(shù)據(jù)集成服務框架的技術體系結構。從圖中可以看出,框架的技術體系由5個層次組成。分別是數(shù)據(jù)源適配器、服務包裝器、SOA運行引擎、XML視圖引擎、XML視圖。
[align=center]

圖2:框架技術體系結構[/align]
數(shù)據(jù)源適配器是同各種數(shù)據(jù)源進行交互的橋梁,它是一些可插拔的組件,并動態(tài)地進行加載。數(shù)據(jù)源適配器以遵從標準接口的方式進行編寫,可以獨立地為新的數(shù)據(jù)源編寫適配器,并很方便地接入到系統(tǒng)中。數(shù)據(jù)源的類型基本上是沒有限制的,即可以是數(shù)據(jù)庫也可以是位于Internet上的文本文件,甚至是一個應用系統(tǒng)。數(shù)據(jù)源適配器將存儲在各種數(shù)據(jù)源的原生數(shù)據(jù)轉換為標準的XML文檔。
服務包裝器是將數(shù)據(jù)源適配器包裝成標準的Web Services服務,這樣就將對數(shù)據(jù)源的API訪問模式轉變?yōu)閷Ψ盏奶峁7瞻b器可以同時包裝多個數(shù)據(jù)源適配器,這樣它的另一個重要作用就是可以對來自一個或多個數(shù)據(jù)源的原生數(shù)據(jù)進行進一步的邏輯處理以將其轉變?yōu)楦幸饬x的信息,并可以在本地緩存處理后的數(shù)據(jù)。這樣通過緩存提高了整個系統(tǒng)地效率和可靠性——即使數(shù)據(jù)源出現(xiàn)故障系統(tǒng)也有能力繼續(xù)工作,同時將業(yè)務邏輯進行預先處理,降低了XML視圖的復雜性,使得XML視圖更易于被理解。服務包裝器隔離了對數(shù)據(jù)的訪問細節(jié)和對數(shù)據(jù)的邏輯處理細節(jié),這兩個部分可以獨立地變化,極大地提高了系統(tǒng)的靈活性。
SOA運行引擎是框架的核心部分,通過它調度服務的執(zhí)行,驅動數(shù)據(jù)集成的處理。SOA運行引擎包括了規(guī)則處理器、流程處理器、消息處理器等。SOA運行引擎將XML視圖引擎解析的數(shù)據(jù)集成請求轉變?yōu)閷Ψ盏恼{用請求,并由運行引擎去查找適合的服務、綁定服務并調用服務。
XML視圖引擎提供三種機制:其一,它將多個異構的數(shù)據(jù)源表示為單一的即時虛擬數(shù)據(jù)庫,這個即時虛擬數(shù)據(jù)庫由一系列實時獲取的XML文檔構成。其二,解析用戶來自XML視圖的請求,將該請求向下層傳達,并將最后結果以XML文檔的形式返還給用戶;最后,它將自己的元信息用XML Schema表達,這些XML Schema就是XML視圖的基礎,基于XML Schema進行XML視圖的定義。XML Schema就如同關系數(shù)據(jù)庫中的表一樣,而XML視圖就像關系數(shù)據(jù)庫中同表相關的表視圖(VIEW)一樣。XML視圖引擎本身也是以Web服務的形式提供,用戶可以很方便地以一種標準的方式訪問它,它也可同時成為另外的XML視圖引擎的數(shù)據(jù)源。
XML視圖是對數(shù)據(jù)集成的元信息描述,由它表達集成后的效果。它并不是集成的結果,而僅僅是集成結果的元數(shù)據(jù)表示,就像關系數(shù)據(jù)庫中的表視圖一樣表示實際數(shù)據(jù)應具有的組成關系:數(shù)據(jù)來自于哪個表,對表數(shù)據(jù)需要作什么樣的處理,不同表的數(shù)據(jù)是如何結合的等。用戶查看XML視圖就能了解該視圖表達的數(shù)據(jù)集成的模式。可以根據(jù)不同的數(shù)據(jù)集成需要定義不同的XML視圖,這就是動態(tài)的數(shù)據(jù)集成——在需要時才定義集成的方式,在運行時才能獲得真正的數(shù)據(jù)。
從圖2可以看出,這5個層次可以分為三個部分各自獨立的進行開發(fā)和分布式部署。其中,XML視圖和XML視圖引擎是一個部分,SOA運行引擎是一個部分,服務包裝器和數(shù)據(jù)源適配器是另一個部分。這樣的分布式數(shù)據(jù)集成具有極高的靈活性,三個部分互不影響;同服務包裝器一樣,可以同時部署多個XML視圖引擎,而XML視圖引擎又可以被服務包裝器封裝成為一個新的數(shù)據(jù)源。這種機制可以比較容易的滿足現(xiàn)代企業(yè)數(shù)據(jù)集成中復雜的環(huán)境,通過較小的代價達到靈活的數(shù)據(jù)集成要求。圖3是一個典型的部署方案。圖3中,XML視圖引擎B使用服務包裝器c,而服務包裝器b將XML視圖引擎B包裝成新的數(shù)據(jù)服務,XML視圖引擎A使用了服務包裝器a和服務包裝器b,也就是使用了服務包裝器a和視圖引擎B的某個XML視圖。
[align=center]

圖3:框架典型的部署方案[/align]
框架的運行機制是首先由用戶查看XML視圖,獲得該視圖上數(shù)據(jù)集成的元結構,基于該元結構發(fā)起合適的處理請求;XML視圖引擎根據(jù)處理請求中相應的XML視圖描述解析該請求,并將其轉遞給SOA運行引擎;SOA運行引擎這些請求轉變?yōu)閷Ψ瞻b器的調用;服務包裝器再將其轉變?yōu)閷?shù)據(jù)源適配器的調用,由數(shù)據(jù)適配器執(zhí)行實際的數(shù)據(jù)源訪問;從數(shù)據(jù)源取回的數(shù)據(jù)經服務包裝器處理后轉變?yōu)闃藴实腦ML文檔送回到XML視圖引擎中;在XML視圖引擎中再根據(jù)XML視圖的集成方式描述完成實際的數(shù)據(jù)整合并將整合結果返還給客戶。從框架的運行機制可以看出,這時數(shù)據(jù)集成是實時的,每次的請求都需要即時到數(shù)據(jù)源中獲取數(shù)據(jù)。框架的基本運行機制如圖4所示。
[align=center]

圖4:框架運行機制[/align]
框架的結構
在基于SOA的數(shù)據(jù)集成框架中,其面向服務的體系決定了框架內部各模塊之間的的關系:這些模塊按照SOA的觀點都可以視為服務,所有這些服務以松耦合的方式連接在一起。框架的核心部分SOA運行引擎的主要功能就是管理這些各種各樣的服務,協(xié)調服務之間的交互,同時使用戶能方便地存取這些服務。圖5是框架的總體結構。
[align=center]

圖5:框架總體結構[/align]
圖5中,內置服務是框架正常運行而必須具備的服務功能。這些服務是框架底層使用的,對用戶來說是不可見的。內置服務主要有:流程引擎,為框架提供流程定制和流程運行的功能;規(guī)則引擎,由它數(shù)據(jù)集成的規(guī)則,企業(yè)根據(jù)自己的業(yè)務規(guī)則通過規(guī)則引擎定義集成和處理的方式;服務注冊和發(fā)現(xiàn)服務,提供 Web Services的注冊中心和服務發(fā)現(xiàn)功能;消息處理器,提供消息處理機制,以便服務能以消息的方式交互。
插件服務是框架具有高擴展性和靈活適應各種需求的主要機制。它將提供數(shù)據(jù)的各種數(shù)據(jù)源包裝成服務,并以可拔插的方式植入框架中。插件服務并不直接訪問數(shù)據(jù)源,而是通過數(shù)據(jù)源適配器訪問數(shù)據(jù)源,這樣將對數(shù)據(jù)源的訪問同服務的提供解耦,數(shù)據(jù)源適配器可以在運行時根據(jù)需要動態(tài)裝配。同時,插件服務還可以根據(jù)需要對其數(shù)據(jù)源適配器獲得的數(shù)據(jù)進行預先處理,以降低最終集成的復雜度,提高系統(tǒng)的整體運行效率。插件服務通過最小化的編程或僅僅進行配置就能擴展整個系統(tǒng),具有極大的靈活性。
代理服務是一種擴展的插件服務,由它提供對諸如第三方應用,如ERP、CRM等數(shù)據(jù)源的包裝以及對XML視圖引擎的包裝。代理服務和插件服務在對數(shù)據(jù)源的包裝上的主要差別在插件服務包裝的是具有明確API接口的數(shù)據(jù)源,如數(shù)據(jù)庫、EJB、COM、MOM、SOAP等,而代理服務包裝的數(shù)據(jù)源沒有明確的API接口,需要對這些數(shù)據(jù)源進行更多的處理。同時代理服務也是數(shù)據(jù)遞歸集成的機制,即將集成后的數(shù)據(jù)作為其他數(shù)據(jù)集成的數(shù)據(jù)源。
服務管理器管理框架中所有的服務,是存取服務的入口,由它去查找正確的服務,管理服務的生命周期,檢察服務的運行情況,調度服務的運行、注冊服務等。服務工廠主要是用來生成各種服務。當服務管理器查找服務時,發(fā)現(xiàn)該服務還沒有運行,服務管理器將請求服務工廠動態(tài)生成并運行這個服務。服務工廠將根據(jù)服務注冊信息啟動該服務,如果服務包裝的底層數(shù)據(jù)源不可得,則該服務將企圖裝載在本地的緩存數(shù)據(jù)。
存取控制模塊為安全使用服務和訪問數(shù)據(jù)提供了基礎。它的主要作用除了提供一個基于角色的存取控制外,還具有兩個重要功能。其一,它采用一種基于標記的用戶認證模型使得單一登陸就可以訪問多個數(shù)據(jù)源,極大簡化了用戶的訪問模式。其二,存取控制模塊還將處理用戶訪問會話的生命期,使得用戶只在一段特定的時間內訪問系統(tǒng),這將進一步提高系統(tǒng)的安全性。
服務存取信道是用戶訪問包裝了XML視圖引擎的服務的通道,并解析用戶請求成為一系列能直接訪問底層服務的查詢計劃。查詢計劃將被緩存,以便能盡可能地重用這些查詢計劃。當有新的請求時,服務存取信道將比較該請求以決定是否已經有可用的查詢計劃,如果有的話,就直接使用它,這樣極大地提高了系統(tǒng)的運行效率。一個服務存取信道可同時提供多個用戶使用。
存取信道管理模塊提供了對服務存取信道的運行時管理,它將根據(jù)不同用戶的訪問請求,將可能返回相同數(shù)據(jù)的訪問請求合并成一個請求;或者對多個用戶訪問請求進行優(yōu)先級排隊處理,以保障優(yōu)先級高的請求能盡快被處理;或者將多個用戶小數(shù)據(jù)量的請求多路復用到一個服務存取信道,保證大數(shù)據(jù)量的請求有足夠的服務存取信道可用。通過這些機制,降低了系統(tǒng)的資源消耗,提高了系統(tǒng)的運行效率。
服務發(fā)布/訂閱接口提供了同框架異步通訊的機制。各種服務可以在服務發(fā)布/訂閱接口訂閱需要的消息,當有適合的消息發(fā)布時,所有訂閱了該消息的服務都將得到通知,這是一種多對多的通訊機制。服務發(fā)布/訂閱接口也能同各種消息中間件相連,以便提供基于消息的服務互連功能。同時,通過服務發(fā)布/訂閱接口,框架將具有一定的事務處理能力。
基于SOA的動態(tài)數(shù)據(jù)集成服務框架為異構異型數(shù)據(jù)的集成和共享提供了一個面向服務體系結構的框架,它以XML技術為基礎,動態(tài)集成為手段,實現(xiàn)各種應用系統(tǒng)之間的數(shù)據(jù)集成,實現(xiàn)跨平臺數(shù)據(jù)的共享,達到跨平臺數(shù)據(jù)資源整合的目的,實現(xiàn)了信息的互通互聯(lián)。基于SOA的動態(tài)數(shù)據(jù)集成服務框架可以為解決跨平臺數(shù)據(jù)共享和集成所面臨的異型異構接口、實時數(shù)據(jù)交換和隨需應變等技術問題,提供有效的解決方法和途徑。