電子政務中數據整合技術的研究

[摘 要] 電子政務是近幾年來我國著手研究的熱點問題。我國電子政務的發展遇到的主要難點是信息孤島問題和電子政務的一體化問題。針對這種情況，對當前數據整合方法作了分析，提出了一種基于Web Services及分布數據整合相關技術的數據整合方案，并對一些關鍵性問題作了探討。

[關鍵詞] 數據整合；電子政務；分布式事務處理

[中圖分類號] TP311.13[文獻標識碼]A[文章編號]1673-0194(2006)08-0044-03

一、序言

隨著全球政治經濟一體化的日益明顯，以電子政務為代表的政府管理服務職能的無紙化、自動化已在很多國家尤其是發達國家中迅速發展。政府機構運用現代計算機和網絡技術，將其部分管理和服務職能轉移到網絡上去，同時實現政府組織結構和工作流程的重組優化，超越時間、空間和部門分隔的制約，向全社會提供高效、優質、規范、透明和全方位的管理與服務。然而眾多的電子政務系統的涌現也相應地導致了一系列問題，例如：數據管理的封閉、無序、混亂、信息資源數字化共享程度低以及現有OA系統不易整合等。許多部門在信息化建設過程中，都有一套自己的數據庫系統，其他部門根本不知道這一部門有哪些數據信息，即使知道了也無法利用，從而造成了“信息孤島”現象，使得數據格式不統一、管理不規范、重復建設、難以進行信息的匯總，不能對政府的決策分析提供有效幫助。因此，在建設領域電子政務建設過程中，如何消除“信息孤島”，整合政府部門現有的數據資源，管理和保護這些寶貴的信息數據，并保證這些信息數據完整性、準確性、實時性和可訪問性，最終建立決策支持系統，是電子政務建設的核心問題。基于上述的設想，本文利用Web Services技術，對電子政務系統中信息傳輸與整合系統的實現作初步的探討。

二、數據整合方法

信息系統整合技術己經經歷了多年的發展過程，以前的研究者們提出了很多信息整合的體系結構和實現方案。

聯邦數據庫是早期人們采用的一種整合方法。聯邦數據庫中數據源之間共享自己的一部分數據模式，形成一個聯邦模式。聯邦數據庫系統可分為兩類：采用緊密耦合聯邦數據庫系統和采用松散耦合聯邦數據庫系統。緊密耦合聯邦數據庫系統使用統一的全局模式，將各數據源的數據模式映射到全局數據模式上，解決了數據源間的異構性。這種方法集成度較高，用戶參與少；缺點是構建一個全局數據模式的算法復雜，擴展性差。松散耦合聯邦數據庫系統比較特殊，沒有全局模式，采用聯邦模式。該方法提供統一的查詢語言，將很多異構性問題交給用戶自己去解決。松散耦合方法對數據的集成度不高，但其數據源的自治性強、動態性能好，集成系統不需要維護一個全局模式。

基于組件的分布式集成系統用分布式的對象模型，諸如，微軟的分布式組件對象模型(DCOM )、 CORBA或Sun的RMI來構建信息集成系統。這種方法利用網絡計算環境可以有效地實現復雜的大規模的信息集成。但是，DCOM、CORBA或RMI要求服務客戶端與系統提供的服務本身之間必須進行緊密耦合，即要求一個同類基本結構。這樣的系統往往十分脆弱；如果一端的執行機制發生變化，那么另一端便會崩潰。

中間件集成方法是另一種典型的模式集成方法，它同樣使用全局數據模式。與聯邦數據庫不同，中間件系統不僅能夠集成結構化的數據源信息，還可以集成半結構化或非結構化數據源中的信息，基于中間件的數據集成系統主要包括中間件和包裝器，其中每個數據源對應一個包裝器，中間件通過包裝器和各個數據源交互。用戶在全局數據模式的基礎上向中間件發出查詢請求。中間件處理用戶請求，將其轉換成各個數據源能夠處理的子查詢請求，并對此過程進行優化，以提高查詢處理的并發性，減少響應時間。包裝器是對特定數據源進行了封裝，將其數據模型轉換為系統所采用的通用模型，并提供一致的訪問機制。中間件將各個子查詢請求發送給包裝器，由包裝器來和其封裝的數據源交互，執行子查詢請求，并將結果返回給中間件。中間件注重于全局查詢的處理和優化，相對于聯邦數據庫系統的優勢在于：它能夠集成非數據庫形式的數據源，有很好的查詢性能，自治性強；中間件集成的缺點在于它通常是只讀的，而聯邦數據庫對讀寫都支持。

早期的數據整合方法也存在一些缺點，制約了其應用。最為突出的兩個缺點是：一是沒有實現真正意義上的跨平臺，還要受到操作系統、編程語言等限制；二是這些分布式計算技術動態可擴展性差。利用CORBA、DCOM等技術開發出來的集成系統，與應用環境緊密綁定。開發好的系統很難變動，用戶無法根據變化動態地調整集成系統，因此整個集成系統的可擴展性差。不能夠適應集成系統在物理結構上或邏輯上發生的變化。

三、基于Web Services的數據整合方案

Web Services作為一種分布式的計算技術，通過使用標準的XML協議和信息格式用于在Internet/Intranet上展現各種應用服務。其主要目標就是使用標準的XML協議在現有的各種異構平臺的基礎上構筑一個通用的與平臺無關、語言無關的技術層，各種不同平臺上之上的應用依靠這個技術層來實施彼此的連接和集成。這些應用通過包裝成Web Services，使用XML-SOAP， WSDL和UDDI等技術把它們的函數或方法作為Web Services接口來顯示，對于調用它們的其他應用來說，這些應用無論其開發語言、平臺如何，都成了同樣的東西，都是一些可調用的Web服務。Web Services以一種松散的Web服務捆綁集合形式能夠快速、低代價地開發、部署、發現和動態綁定應用，其優越性主要表現在：簡單性、基于開放平臺、靈活性、代價低。

1. 總體框架

電子政務數據整合系統是一個較為復雜的系統，各個電子政務系統本身就是一個包含了諸多功能模塊的功能集合體，系統之間存在著很大的異構性，系統需要實現多種類型的數據訪問。為了簡化數據整合系統的結構，抽象出如圖1所示的數據交換模型：

圖1數據交換系統結構框

數據整合系統體系結構組成包括：各電子政務系統、代理和數據交換中心。系統存在多個電子政務系統和一個數據交換中心。每個電子政務系統上有一個相應的代理，負責與數據交換中心及其他代理通信。整個結構是一個星型結構，處于中心位置的是數據交換中心，它通過標準化的Web Services接口為每個電子政務系統提供服務。每個電子政務系統通過代理將本地數據模式和數據訪問接口封裝成為數據訪問服務，并將服務注冊發布到數據交換中心。與此同時，代理實現該數據訪問服務的本地Web Services接口，為其他節點提供數據訪問服務。代理起到集成系統中適配器的作用，它通過Web Services有效地屏蔽了各電子政務系統之間操作系統、應用軟件和數據庫的異構性。

2. 整合過程中數據模式的管理

各個電子政務系統數據庫要向數據交換系統提供數據訪問服務，必須先將自己的數據模式發布出去，數據整合系統的其他代理才能根據發布的數據模式訪問該電子政務系統的數據。一個電子政務系統在發布和共享自己的數據模式的同時，還要針對該數據模式為數據集成系統提供數據訪問接口。因此，發布出去的數據模式與某個數據訪問接口是相互綁定的。為了便于對數據模式和數據訪問接口的統一管理，系統采用注冊中心的方式管理已發布共享的數據模式和數據訪問接口。注冊中心收集各節點發布的共享數據模式，并按照提供者和類型進行存儲，形成一個松散的全局數據模式。注冊中心可以配置數據模式的訪問權限，為參與集成的各個系統提供數據模式和數據訪問接口查詢和修改等服務。

在數據的整合過程中，由于各系統數據源的異構性以及各數據庫的自治性，數據沖突是必然存在的，主要的沖突有：

主鍵沖突。常見的主鍵沖突有兩種情況，一是由模式定義引起的，如兩個關系表中，studentl .id#和sturdent2.name#分別是兩個關系表的主鍵，在集成時產生主鍵沖突；另一種情況，是由數據值引起的，往一個關系表中插入兩個具有相同主鍵的記錄，也會產生主鍵沖突。

名稱沖突。包括兩種情況，一是兩個語義相同但名字不同的稱同義異名沖突，二是兩個名字相同但語義不同的稱同名異義沖突。

類型沖突。兩個語義相同但數據類型不同的屬性沖突稱數據類型沖突。

以上各種沖突的解決可以通過建立一個全局的數據模式來實現，Web services的接口在全局數據模式的基礎上實現，各電子政務系統完成本地數據模式到全局模式的轉換。

3. 安全設計

Web Services數據傳輸安全性是通過使用SOAP 擴展性模型和WS-Security的安全性構架實現的。WS-Security為多安全性令牌、多信任域、多簽名格式和多加密技術提供支持。WS-Security規范提供了3種主要的機制：安全性令牌傳播、消息完整性和消息機密性。實現端對端消息級安全性而非僅僅傳輸級安全性。安全服務還為數據訪問的服務調用加上時間戳，并記入日志以支持不可抵賴性。

在數據交換和轉儲過程中，某些機密性數據需要在存儲到中心數據倉庫前加密。這樣即使是數據交換中心的系統管理員也無法直接從中心數據庫中讀取機密數據。整個數據加密存儲服務由3部分組成：數據加密、數據解密、機密數據配置。由于數據庫是無法直接操作加密數據的，因此加密適用于數據量不大，且沒有針對該數據作選擇運算的數據，否則數據庫在做選擇運算時必須先解密所有數據到臨時表，然后才能做選擇運算，這在數據量大的時候是不可行的。

4. Web Services事務管理

Web Services事務是跨平臺的、跨邊界的，事務的參與者通常是分布于網絡中不同的自主節點。Web Services事務執行有時需要很長的時間，事務的提交是通過協調的方式完成，同時事務的原子性也有所放松。因此事務的管理不同于一般的分布式數據庫的事務管理，采用以下模型實現：

模型由一個事務發起者、一個事務協調器和多個事務參與者構成。事務由發起者啟動，由參與者執行，由協調器管理。事務發起者在調用一個事務性 Web Services 服務時，首先要向事務協調器發一個事務管理請求，請求時要提供事務類型信息。協調器若接受代管事務請求，會生成一個事務管理單元，并向事務發起者返回事務上下文。事務上下文描述了事務發起者地址、事務管理單元地址、事務 ID 等信息。這一過程完成后在事務協調器上注冊一個管理該事務的事務管理單元。接下來，事務發起者將應用調用和事務上下文一并發送給各事務參與者。事務參與者利用事務上下文得知事務管理單元的地址，向事務管理單元注冊自己，此后事務管理單元直接與各參與者傳遞消息。與此同時，事務本身在各個參與者上得到執行。此后，事務發起者在需要確認提交事務時，向事務管理單元發送確認消息。事務管理單元隨后啟動兩階段提交協議，與各事務參與者交互，決定事務最終被提交或被撤銷。兩階段提交協議采用何種方式表決要視事務的具體類型，原子事務和內聚事務采用不同的表決方式。

四、結束語

采用以上方案可以很好地完成多個電子政務系統的數據整合，從而解決信息孤島問題和數據一體化問題。該方案已在河北省建設工程招投標監管系統中得到了良好的應用。隨著Web Services技術的進一步成熟，該方案將會得到更好的應用和發展。

主要參考文獻

[1] Halevy A Y. Theory of answering queries using views. SIGMOD Record， 2000，29(4):40-47.

[2] Wiederhold G. Mediators in the architecture of future information systems. IEEE Computer， 1992， 25(1): 38~49.

[3] 岳昆， 王曉玲， 周傲英. Web 服務核心支撐技術:研究綜述[J]. 軟件學報， 2004， 15(3):428-442.

[4] 柴曉路，梁宇路.Web Services 技術架構和應用[M].北京：電子工業出版社，2002.