傳統的分布對象技術分別有OMG的CORBA、 Microsoft的DCOM 以及SUN的RMI。然而CORBA缺少方便的開發工具和強有力的廠商支持,門檻稍高,入門較困難;DCOM 跨平臺性較差;RMI對多語言融合的支持卻很弱。同時,這幾種技術都有相似的缺陷:①CORBA、DCOM和RMI雖然能調用實現的系統,但均要求服務器和客戶端必須緊密耦合,并且體系結構相同;②CORBA、DCOM和RMI依賴于特定的對象模型協議,目前只在企業內部使用廣泛,都不太適合在Internet環境下進行多源異構數據庫融合的設計開發。
Web服務的出現滿足了信息化服務所要求的基本功能,它是微軟.NET 框架下多源異構應用的典型方案,并在中間件基礎上,采用XML和Web服務技術實現了各異構數據庫的融合,提供了一種全新的以松耦合的方式在Internet環境下部署分布式應用的解決方案。任何操作系統、任何語言編寫的客戶端都能夠訪問服務器提供的Web服務,其客戶端與服務器端之間以XML消息作為聯系,解決異構數據庫集成的難題,彌補了CORBA、DCOM和RMI方法的不足。本文提出的基于Web服務分布式異構數據庫B/S三層架構的智能集成方法優化了傳統的集成方法和數據模式映射,同時還利用Spring 框架的Quartz定時任務調度實現集成系統的智能更新,整個系統具有實時性、可擴展性、高響應性等特點。
本文的第二部分介紹Web服務和異構數據庫系統,第三部分提出基于Web服務的分布式異構數據庫集成系統總體架構和各功能模塊,第四部分對描述系統設計與實現,第五部分進行測試驗證,第六部分對本文進行總結。
1 相關理論與技術概述
1.1 Web服務體系結構
Web服務是一種面向服務的分布式計算體系結構,相比傳統的分布對象技術和集成技術,能夠提供面向Internet的標準程序接口,具有跨防火墻、軟件和數據重用、良好的封裝性、松散耦合性和高度可集成性等優點[4]。
Web服務作為一個新型的分布式計算模型,具有自包容和自描述的優點。由三個角色和三個操作組成。三個角色分別為服務提供者、服務請求者和服務代理,三個操作為發布、查找和綁定。Web服務的關鍵技術包括SOAP(Simple Object Access Protoco1)、WSDL(Web Service Description Language)、UDDI(Web Service Description Language)、XML。XML是Web服務的技術基礎,Web服務中各種信息的描述都是基于XML。SOAP提供了一種通信機制,它是分布式環境中交換信息的通用協議,保證了Web服務和其它應用程序之間可靠通信;WSDL是以XML的格式來描述Web服務。UDDL用來創建Web服務注冊中心,它是Web服務注冊和發現的技術規范[6]。Web服務體系結構如圖1。
1.2 異構數據庫
圖1 Web服務結構
異構數據庫實現數據共享的同時,每個數據庫系統保持著自己的完整性、自治性和安全性。異構數據庫系統中的異構性主要表現為數據異構、系統異構和語義異構[5]。
(1)數據異構。異構數據庫系統中數據異構表現在不同數據源對同一數據有不同的定義,例如格式、數據類型或精度等等。比如在SQL Server中用int、float、double等類型,而在Oracle中用Number統一表示數值型的屬性。因此在異構數據庫之間共享數據時,需要對數據異構加以考慮。
(2)系統異構: 異構數據庫系統中系統異構主要指數據所依賴的應用系統存在的差異,比如硬件平臺(大型機、PC機)、數據庫管理系統(MySQL、SQL Server) 和操作系統(Unix、Windows)等的不同。
(3)語義異構: 語義異構是指屬性含義相同,但是屬性名的接口模式不同。從簡單的命名沖突(如同名異義,同義異名)到復雜的結構語義沖突,語義異構在數據庫中主要表現在屬性異構。比如屬性“姓名”,有的用“Name”,也有的用“XingMing”,屬性名“type”,有的表示車型,也有的表示食物類型等。數據庫的語義異構是數據集成過程中需要解決的關鍵問題。
1.3 異構數據庫集成的常用技術
異構數據集成的常用技術為:聯邦數據庫、數據倉庫和中間件方式。
(1)聯邦數據庫采用模式集成的方法,其基本思想是在數據庫系統集成時,從各異構數據庫中獲取數據源的數據視圖,并將其集成為全局模式。用戶就可以直接通過全局模式透明地訪問各數據源中的數據。各數據源間互相獨立,通過數據轉換接口實現相互訪問。聯邦數據庫優點是容易操作實現,缺點是當異構數據源變化時,種類復雜,工作量大,擴展性差,僅適合數據源較少的情況下使用[8]。
(2)數據倉庫概念始于上世紀 80 年代中期,其基本思想是將各個數據源的數據復制到同一數據倉庫中,用戶可以直接訪問數據倉庫進行集中查詢獲取數據。數據倉庫優點是便于控制,容易處理,缺點是當數據信息重復存儲時,無法將數據源的更新信息及時準確地反映到數據倉庫中。數據倉庫僅適合數據源比較穩定,并且數據訪問較頻繁的情況,不適合于用戶實時查詢。
(3)基于中間件的數據集成模式是目前最典型的數據集成方法。中間件由中介器(Mediator)和包裝器(Wrapper)組成。中間件方式并不改變數據原來的存儲方式和位置,它為異構數據源提供一個統一的虛擬視圖[7]。中間件模型適用于變化頻繁、結構多樣且數據源較多的情況。本文的系統結構就是采用中間件的方式。
2 基于Web服務的分布式異構數據庫數據集成系統
2.1 用戶需求分析
在該異構數據查詢系統中,共有三種用戶參與,分別是各異構數據庫管理員、集成系統管理員和普通用戶。其中集成系統管理員享有最高權限,可以創建和管理用戶、審查和批準需要加入的異構數據源、獲取異構數據源的元數據、合成并管理全局數據庫模式等;各異構數據庫管理員能夠登陸數據源注冊系統,根據需要填寫注冊信息,選擇需要共享的表和字段并注冊;普通用戶只能登陸查詢系統,根據相關的查詢權限對數據進行查詢。系統用戶如圖 3所示。
圖 2 系統用戶
2.2 體系結構
Web服務集成中間件系統體系自下而上包括數據庫層、數據集成層和統一應用層。其中,底層的各個異構數據源構成了系統的數據庫層;數據集成層采用中間件技術,封裝了異構數據庫集成系統的業務邏輯;各種應用程序和對應的訪問接口構成了系統的統一應用層。數據庫智能集成系統框架圖如圖2所示。
圖3 基于Web服務的分布式異構數據庫智能集成系統框架圖
該系統采用 B/S模式,構成了客戶/服務器三層架構。采用這種設計有以下幾種優勢:
(1)安裝升級簡便。通過瀏覽器訪問數據庫簡化了客戶端。在升級軟件的時候,不需要對客戶端升級。
(2)易擴展維護。所有應用程序均在服務器端,開發維護過程可集中在服務器端,不需要考慮數據庫端和客戶端。
(3)可移植性強。本文采用JavaBean技術,可以在不同Web服務器、不同操作系統上運行,而且可以在不同的平臺間移植,不需要重新編譯。
(4)可靠性強。多層體系結構可以有效地優化系統總體性能,提高系統的可靠性和伸縮性。
(5)數據智能更新快。綜合包裝器中的智能更新模塊采用Spring框架,該方法中Quartz任務定時掃描更新各異構數據庫上傳的XML描述文檔,充分保證了抽象數據表的實時性、智能性和有效性。
2.3 功能模塊設計
(1)客戶端功能模塊
統一應用層也就是用戶界面,即異構數據庫集成系統的使用者。用戶可以通過數據集成層來訪問異構數據庫的共享數據資源。本系統不需安裝客戶端軟件,直接利用瀏覽器作為客戶端用戶的界面,可以把XML表示的數據轉換成為Html格式,直觀方便,非常適合異構數據集成系統[8]。
(2)服務器端功能模塊
本文采用Tomcat作為Web服務器。Tomcat作為一個優秀的開源Web應用服務器,是Apache Jakarta的子項目之一。其性能穩定、技術先進,而且免費開源,因而深受軟件開發商和Java愛好者的認可,Web應用服務器目前使用廣泛。
數據庫服務器主要是提供實際的數據管理功能,為數據站點存儲數據集。該系統主要支持的數據庫服務器有Oracle、SQL Server、MySql、Access 等。
(3)數據模式轉換功能模塊
數據集成層是實現異構數據庫中數據轉換的核心,目的是訪問各個數據源,集成數據源信息,協調各數據源間信息。數據集成層在各局部數據提供的共享數據的基礎之上建立一個全局的虛擬視圖,并不存儲實際的數據。具體包括:元數據DB、元數據管理器、綜合包裝器、中介器、應用層訪問統一接口、異構數據庫統一接口,下面分別對各模塊加以介紹。
元數據DB負責儲存各異構數據庫的元數據庫信息。元數據庫信息包括注冊信息、連接信息URL、各元數據庫用戶與全局用戶的匹配關系、模式映射信息、訪問策略信息等。元數據DB支撐整個系統的運行[9]。
元數據管理器負責制定集成系統的全局模式與局部數據庫的模式之間的轉換規則。
中介器負責異構數據庫的注冊、公共模型的生成和全局查詢請求的接收。中介器由三個組件構成,包括:異構數據注冊模塊、查詢規劃模塊和結果合并過濾模塊。其中,異構數據注冊模塊的主要功能是:在共享數據注冊階段,負責公共模型的建立以及異構數據庫的共享注冊;查詢規劃模塊的主要功能是:在數據集成階段,將客戶端提交的基于全局數據庫的標準查詢分解成針對各個異構數據庫的子查詢,并提交到相應的包裝器;結果合并過濾模塊的主要功能是:將各異構數據庫查詢返回的 XML文檔進行合并,形成完整統一的查詢結果,反饋至客戶端瀏覽器。
綜合包裝器的功能是實現數據位置和訪問的透明,對異構的數據進行包裝。綜合包裝器由智能更新模塊、查詢結果轉換模塊和數據庫操作模塊三個組件構成。智能更新模塊采用spring框架的quartz任務定時的掃描由不同的異構數據庫上傳的XML描述文檔,通過解析這些XML文檔,實現數據自動更新,從而保證抽象數據表的有效性、實時性、智能性。查詢結果轉換模塊負責將SQL查詢的結果轉換為XML文檔。數據庫操作模塊負責連接后臺各個異構數據庫,包括初始化數據庫連接、分配連接、封裝數據庫基本操作、關閉連接等功能。
數據集成層對外提供了兩個統一接口,即應用層訪問統一接口和底層異構數據庫訪問接口。其功能是屏蔽各數據庫的差異,提供數據的透明訪問,使得使用者無需知道數據的數據源模式及具體的物理位置等信息,只需通過系統定義的與具體數據源無關的SQL語句進行訪問。
3 關鍵技術分析
3.1 數據映射
數據轉換是中間件層的首要任務,數據轉換的目的是將不同數據源轉換成統一格式,為各異構數據源的局部模式提供統一的全局模式。關系數據庫是目前市場上的主導,XML文檔的結構和關系數據庫的數據結構的差異較大。關系數據庫用二維表存儲數據,用主鍵和外鍵的方式體現數據之間的關系;而XML文檔采用層次嵌套結構,數據類型、數據長度都不規則,通過子元素與父元素嵌套的形式體現數據間的關系。為了采用SQL工具操作XML數據,在關系數據庫和XML之間架起橋梁,或將XML轉換成表格式的表單,必須解決XML與關系數據庫間的映射[6]。
(1)關系模式到XML 模式映射
轉換的算法可如下描述:
Input:關系數據庫
Output:XML 模式
Step 1:將關系模式從關系數據庫中提取出來。
Step 2:用 SQL 語句來重構數據庫中的約束。
Step 3:由關系模式重構映射結構。
Step 4:由映射結構和重構的結果生成 XML Schema 模式。
Step 5:將從在XML文檔中嵌入從數據庫提取出的數據。
Step 6:對XMLSchema 格式文檔及所表示的數據 XML 文檔進行輸出。
整個流程如圖3所示。
圖 4 關系模式到XML模式的映射
(2)XML 模式到關系模式的映射
轉換算法如下:
Input:XML Schema文檔
Output:關系模式
Step 1:形式化描述XML Schema文檔。
Step 2:從 描述的XML Schema 文檔中,提取元素組成元素樹。
Step 3:映射轉化元素樹,輸出關系數據數。
Step 4:將得到的關系數據樹動態合成為SQL語句。
Step 5:使用 SQL 語句將 XML 文檔中的數據嵌入到關系數據庫.
關系模式在轉化前后必須保持一致,其轉換流程如圖5所示。
圖 5 XML模式到關系模式的映射
3.2 Quartz定時調度法
Spring框架的Quartz作為流行的企業級任務調度技術,任務調度為應用系統請求的特定任務執行操作安排,Spring為Quartz的重要組件提供Bean風格的擴展類。Spring容器生命周期和其環境下創建的組件對象,爭對具體任務可以執行停止或啟動。在Spring的開發應用中可以充分利用不同形式的任務定時調度功能。
包裝器的智能更新模塊,就是采用Spring的任務定時調度方法,掃描各異構數據庫上傳的 xml 描述文檔,實時更新抽象數據表。更新抽象數據表可直接通過調用JDK Timer中schedule來執行,執行過程中的重要參數有間隔時間、啟動時間延遲、任務對象[3]。
Spring引入了TaskScheduler,不同形式的任務定時調度。按某個時間間隔重復執行任務,也可以在給定時間點執行一次任務,該方法中的Cron觸發器可以靈活定義執行時間[3]。
例如:scheduler.schedule(task, new CronTrigger(″* 206-15 * * MON-FRI″));在每周星期一到星期五的6點20分至15點20分執行設定的任務。
假設定義一個服務,根據各異構數據庫上傳的XML文檔,配置定義服務的執行時間點。服務定義如下:
Importorg.springframework.stereotype.Service;
@Service
public class TaskOne {
public void OnePrint() {
System.out.println(″One測試打印″); } }
XML配置規定抽象數據表主要表達如下,即1秒后開始更新,每隔3秒執行一次。
cron=″1 / 3 * * * *?″ />
4 系統的部署
由于集成系統中各異構的數據源是自治的,這些資源分屬于不同的部門,有些數據需要一定的權限才能訪問,有些數據甚至不能共享,所以需對可共享的內容進行設定。系統的具體部署包括以下兩個階段:
4.1 數據注冊階段
由中介器中的注冊管理器來完成,主要任務是完成對各異構數據源在數據集成層中的注冊,選擇集成的內容(共享的表和字段)和訪問的權限,并建立數據庫集成的模型。在這個階段,主要有各異構數據庫管理員和集成系統管理員兩類角色參與,他們的主要任務如下:
各異構數據庫管理員:主要完成登錄數據集成系統,選擇數據庫中共享的內容,對共享的數據的訪問權限進行設定。選擇自己欲注冊的數據庫類型,向集成系統管理員注冊信息,如數據庫主機名、IP地址、用戶名、密碼。
數據集成系統管理員:主要審核各注冊的異構數據源,確定訪問權限和集成內容。由數據集成層建立共享的公共模型,并收集各注冊的數據庫信息。
4.2 系統運行階段
此階段的主要任務是接受用戶提出的查詢請求并對請求做出相應的解答。圖5為系統的數據查詢流程圖,包括以下四個步驟:
步驟1:用戶從瀏覽器利用HTTP協議,向應用層統一接口發出查詢請求,接口收到用戶查詢請求后進行分析執行,轉化為查詢參數;
步驟2:中介器得到查詢參數后,到元數據中查找目標數據庫及數據表,并通過查詢規劃模塊進行SQL分解,生成異構數據庫相對應的SQL子查詢語句SQL1 ,SQL2,…,并放入隊列之中準備執行;
步驟3:綜合包裝器通過數據庫操作模塊,從查詢隊列中將SQL子查詢語句SQL1,SQL2,…發送到相應的異構數據庫中執行;
步驟4:異構數據庫將數據查詢響應后數據發送給綜合包裝器,通過查詢結果轉化模塊,把各異構數據庫的查詢結果DATA1 ,DATA2…轉化成XML1,XML2…文檔;
步驟5:中介器再對各個數據庫提供的查詢結果XML1,XML2…文檔作集成處理,即將XML1,XML2…經由結果合并過濾模塊的處理,合并不完整的數據和過濾重復的數據。將完整統一的查詢結果XML發送給客戶端瀏覽器,經由瀏覽器呈現在用戶面前。
圖5 系統數據查詢流程圖
5 系統測試
5.1 系統測試環境的搭建
數據庫訪問中間件技術采用Visual Studio2010作為開發工具,對多數據庫在異構環境下的訪問,采用數據庫為SQL Server2005、Oracle、MySql和Access, Web服務器使用Tomcat,操作系統采用Windows XP Professional SP2。整個系統的實驗環境如圖6所示。
5.2 測試內容與結果
本文對異構數據的智能集成系統及其關鍵技術點做了詳細的分析和設計,并且給出了整個系統實現的詳細流程方案,現通過實現一個簡單的數據源注冊功能來驗證上述的系統[10]。
由圖7知,實驗環境部署包含一臺數據集成中心服務器、一臺客戶機端和四臺數據庫服務器。數據集成中心Server是本系統的核心Server,實現了對異構數據源的訪問和注冊,各異構數(下轉第90頁)(上接第70頁)據庫的元數據和中間件都位于該服務器上;客戶機端是通過瀏覽器訪問數據集成層統一接口,以實現對異構數據的透明訪問;數據庫Server存儲了具體的查詢數據,用來實現對異構數據庫數據源的管理和存儲。
圖 6 系統實驗環境部署圖
每臺機器上都部署著自己的運行環境,從系統部署流程可知,從各異構數據庫Server登陸數據集成中心的數據源注冊系統,數據集成中心根據所填的信息,與相應的數據庫進行連接,獲得元數據。異構數據集成中數據源注冊系統界面如圖7所示。
圖 7 數據源注冊系統界面
6 結束語
本系統在現有的異構數據庫集成解決方案的基礎之上,對原有的模式集成方法的進行了多方面的擴展,使用XML、Web服務等技術實現了基于中間件的B/S模式下異構數據庫的集成,本文重點分析了XML與關系數據庫之間的映射,提出了通過spring框架的quarzt定時任務,實時的對集成系統全局數據表進行更新,以達到系統的智能集成。該系統成功解決了異構數據庫集成時操作復雜、需要人工干預等問題。由實驗結果可以看出,該設計方案較為合理且簡單實用,可以被復用,效果良好,具有高實時性、可擴展性、高響應性能等特點。
- 上一篇:地鐵綜合自動化集成系統方案解析
- 下一篇:基于深度學習的智能車輛輔助駕駛系統設計
推薦資訊
