??? 網絡技術的發展使人類社會進入“信息爆炸”的時代，而人們卻常常被淹沒在浩瀚的數據海洋之中，難以有效地檢索、訪問和使用數據。由于受到當時計算機技術和應用水平的制約，早期的信息系統都是根據行業或部門的特殊需求而建立的，沒有充分考慮與其它相關信息系統的數據共享" title="數據共享">數據共享問題，所以形成了所謂的“數據煙囪”或“數據孤島”，這已經成為制約信息系統進一步發展的“瓶頸”之一。
??? 到了二十一世紀，異構" title="異構">異構數據環境帶來的互操作" title="互操作">互操作問題變的越來越突出。即便是針對同一領域的應用問題，并且采用相同的技術體制，也無法保證所有應用系統" title="應用系統">應用系統都有相同的數據模式。為了在這些系統之間交換數據，必須將信源模式中的數據轉換為信宿模式的格式。
??? 本文所說的異構數據環境是指網上相互獨立且需要進行數據交換的各種不同數據庫系統構成的集合，其中的每個數據庫系統都具有自治性。這里包含兩層意思：
??? （1）數據庫管理系統（DBMS）的異構性，即分別采用不同供應商的DBMS產品；
??? （2）數據模型（Data Model）的異構性，即采用的數據庫邏輯模型或物理模型不同，或者對數據元素的語法描述不同，或者同一語法描述在不同的數據庫系統中有不同的語義解釋。
??? 要解決DBMS的異構性，可以采用DBMS網關技術，它主要解決不同DBMS之間的語法轉換問題，目前已經有許多成熟的商用軟件可以選擇，如Sybase提供的OmniSQL網關。要解決數據模型的異構性，不僅涉及到語法轉換（Transform），還涉及到語義仲裁（Mediation）問題，這是異構數據集成的關鍵。
??? 早期的方法是為每一對交換數據的系統寫一個特殊的接口程序。歷史的經驗告訴我們，開發和維護這些接口程序的時間和經費開銷都很大。而且，隨著需要交換數據的系統不斷增加，為此而付出的代價也將不斷增大。
??? 如何實現分布式數據的交換與共享是人們普遍關注的研究領域。因為目前大量的數據是通過分布式、異構數據庫系統進行管理的，所以要實現數據共享與透明訪問，就必須集成各種異構數據庫系統，并最終達到數據互操作的目的。
??? 本文回顧數據共享技術的發展歷程，討論數據標準化對數據互操作的作用及其局限性，在此基礎上，提出一種基于EJB的異構數據互操作解決方案，最后介紹其中的部分實現問題。
2 數據共享技術發展
??? 從數據共享的角度來看，信息系統的發展大致經歷了的四個階段：數據與應用捆綁階段、數據與應用相對獨立階段、基于標準的數據集成階段、異構數據互操作階段。
2.1 應用與數據捆綁
??? 早期的應用程序都有自己的數據，而且應用程序很少訪問其它部門或系統的數據，數據與程序緊緊捆綁在一起，數據的定義、格式以及操作規則都完全由使用它們的應用程序來解釋，共享數據幾乎是不可能的。
??? 客觀地說，直到20世紀90年代，各企業、各部門在建立應用系統時，往往的只考慮自己對數據的需求，而很少關心是否能夠滿足其它機構的需求。系統間進行數據交換時，需要很多專用的、點對點的接口程序，而且多數是通過格式化消息或文件傳遞來實現的。
2.2 數據與應用相對獨立
??? 隨著計算機應用范圍的不斷擴大，系統之間的互操作和數據共享需求日益迫切。隨著數據庫管理系統的不斷成熟，應用系統的程序和數據已經分離。應用系統不僅能夠訪問自己的數據，還能夠通過查詢和操縱其它系統的數據，但是，不同的數據庫/數據文件之間仍是彼此孤立的“數據孤島”，無法形成統一的數據視圖。
2.3 基于標準的數據集成
??? 為了給所有用戶提供訪問共享數據的統一邏輯視圖，人們從20世紀90年代開始大力推進數據標準化工作，并取得了明顯成效。
??? 通過制訂企業標準數據模型以及標準數據交換格式，可以將分散在不同宿主機上的數據庫集成為一個物理上分布、邏輯上統一的數據庫系統，應用系統可以通過統一的數據訪問服務透明地查詢和更新分布式數據庫中的數據，而分布式數據庫管理系統本身具有維護全局數據一致性的功能。
??? 數據標準化工作大大提高了信息系統之間的數據共享與互操作能力。但是，數據標準化不是萬能的，它不能一勞永逸地解決數據共享問題。
2.4 異構數據互操作
??? 由于各部門都掌握并維護著與自己的業務相關的數據，其中有一部分是專用數據，還有很多數據是需要并且可以與其它部門共享的，所以必須建立相應的軟件基礎設施，以滿足各種可能的數據共享需求。
??? （1）為了制定正確的生產計劃，往往需要銷售部門和財務部門及時提供客戶訂單和財務方面的數據。
??? （2）為了應對市場的變化，往往需要臨時改變營銷計劃和增減業務部門，這里存在大量現有系統無法預見的新關系，以及新增業務部門對信息共享的需求。
??? （3）當企業經營模式發生改變時，可能會導致應用系統數據采集和共享模式的改變，而管理員很難事先了解這些改變的后果。
??? （4）為了適應企業新的數據共享需求，必須能夠通過簡單的軟件配置或組裝方法（而不是開發新的代碼）來實現新的功能。
??? （5）由于數據源存儲在不同的宿主機上，所以必須提供便捷的方式，使之快速找到所要數據源，從而避免開發人員通過建立私有、冗余的數據源，達到降低數據集成與轉換代價的目的。
??? （6）為了滿足數據安全需求，應提供統一的訪問控制、用戶識別和授權服務，如果每個應用都采用特有的授權和訪問控制方式，將給系統間的互操作和數據共享帶來了很大的障礙。
??? 上述一系列問題需要一種嶄新的數據管理和數據共享機制。
??? 美國國防部最早在其DII COE中提出數據共享工程（SHAred Data Engineering，SHADE）計劃。SHADE首先將各應用系統的需求匯總，通過分析去掉冗余數據集，以提高公共數據的一致性，然后再將這些數據以所有應用程序都認可的形式存入數據庫，實現數據與應用程序的獨立性。SHADE還提供公共數據的一致性表示，軟件開發者可以容易地使用這些數據，并與其專用數據結合。
??? SHADE實際上是DII COE提供的一種數據共享策略，它的作用不僅僅局限于軍事領域，它在數據標準化的基礎上，通過提供多種可重用軟件和數據組件，特別是引入數據仲裁機制，為遺留系統、現有系統和新研系統之間的數據共享與互操作提供了三種用法不同而基礎一致的解決方案：共享數據服務器、虛擬數據倉庫和XML門戶，使數據共享技術的發展進入了新的歷史階段。
3 數據標準化及其局限性
3.1 數據標準化是基礎
??? 數據共享工程的目標是保護現有數據庫、數據結構和數據記錄的投資；通過數據重用提高互操作性；提供數據融合的基礎。達到這一目標的前提是數據的公共表示（Common Representation），而公共表示依賴于數據標準化工作。
公共表示為數據提供者和使用者提供公共的語法描述和語義解釋，以及有效的取值范圍。公共表示通過一個邏輯模型來維護，但它可以有多種物理表現形式（如Informix、Sybase 或Oracle數據庫，面向對象數據庫，XML文檔，UML模型或普通文件等）。
??? 由此可見，為了滿足數據共享需求，每個行業、企業和部門都應當建立統一的數據標準。
3.2 數據標準化只能提供部分解決方案
??? 數據標準化固然重要，假如每一個應用系統都采用相同的數據表示，即數據的名稱、類型、結構、表示方法和語義解釋都完全相同，那么數據互操作問題便不存在了。為了實現公共的數據表示，減少因數據異構性問題而引發的數據互操作問題，各行業都非常重視數據標準化工作，甚至人們曾經希望通過標準化工作一勞永逸地解決數據共享與互操作問題。
??? 但是，人們很快就發現，要建立和維護單一的、完整的、標準的數據模型是相當困難的，有時甚至是不切實際的。為了使每一個應用系統都采用同樣的數據表示，我們需要一個統一的、完整的、覆蓋所有應用領域的數據模型。然而，由于人類認知的局限性，很難成功地為大型企業（或行業）建立這樣一個覆蓋所有細節的模型。事實上，每個大型企業（或行業）都有許多不同的數據模型，其中每個數據模型只覆蓋一個功能域（如采購、生產、銷售、財務等）。在開發應用系統時，應根據不同的功能域選擇不同的數據模型或數據定義。當基于不同模型的應用系統之間需要進行數據交換時，將會引發數據互操作問題。
??? 其次，世界在變化，標準也將會隨之改變，而系統不可能同步適應這種變化。例如，一個相當穩定的數據庫每三年需要修改一個數據模式，如果一個標準模型覆蓋100個這樣的數據庫，那么每兩周就要應付一次這種改變。
??? 此外，系統可能需要與采用不同標準的信息系統交換數據，這必然引起數據模型的異構問題。例如在天氣模型化過程中，可能要與氣象學、海洋學等其它學科有交叉。
??? 再有，特定數據表示方法的選擇與標準化相抵觸。在某些情況下不同系統采用不同的數據表示方法可能有一定的合理原因。例如采用精密電子傳感器和人工觀測兩種不同方式觀測某個對象的時間特定時，即使采用同一種數據模型來表示記錄結果，但也由于數據的精確度和可信度的不同，記錄的數據有著不同的意義。
??? 由此可見，數據標準化并不是完整的解決問題的方案。更好的方法是放松完整描述元數據的需求，允許系統開發者在自己的數據模式中描述元數據，并且提供自動解決元數據差別的工具。
4 基于EJB的數據仲裁
??? 在很多情況下，用戶都不愿意放棄自己的數據模式，以適應其它系統所支持的標準模式。但為了在系統之間進行數據交換，又必須能夠按照其它系統所需要的格式提供信息。數據仲裁（Data Mediation）方法在保持用戶原有數據模式的前提下，較好地解決了互操作問題。
??? 本節重點介紹我們設計的一種基于Enterprise JavaBeans和CORBA技術的數據仲裁服務器（簡稱EJB仲裁器），它在公共數據表示（數據標準化）的基礎上，解決異構數據模型之間的仲裁、轉換、集成與互操作問題。
??? 如圖1所示，EJB仲裁器是一個中間件（應用服務器），用來完成兩個系統不同數據模式之間的數據轉換，它通過APIs接口為應用系統提供數據仲裁服務。
??? EJB仲裁器按照下列步驟來處理信源（Source）和信宿（Target）之間的數據交換：
??? （1）接收來自信宿（接收方）的SQL語句；
??? （2）將接收到的SQL語句轉換為適合信源模式的等價的SQL語句；
??? （3）執行對信源數據庫的查詢，并且將查詢結果轉換為信宿的格式；
??? （4）將轉換后的查詢結果返回信宿。
??? EJB仲裁器的作用實際上是系統之間的語義網關，它使得接收方不僅可以查詢自身的數據庫，還可以查詢信源數據庫，就象自身的數據庫得到擴充一樣，根本無需關心數據名稱和表示方法的差異。
??? EJB仲裁器與早期的專用（點對點）轉換器的主要區別在于它能夠通過信源模式和信宿模式的數據描述自動完成數據轉換，而無需人工編寫轉換代碼。
圖1 數據仲裁機制示意圖
?? EJB仲裁器運行在Java虛擬機（JVM）上，它主要包含公共數據字典（Common Data Dictionary）和公共數據模式（Common Data Schema）和轉換函數庫（library）。其中，公共數據字典使所有系統都采用標準術語，并且對標準術語的解釋都是唯一的；公共數據模式由覆蓋特定功能域的E-R數據模型表示；EJB仲裁器通過轉換函數庫為客戶端" title="客戶端">客戶端應用提供SQL語句轉換和數據轉換服務。
??? 信源模式和信宿模式采用數據庫視圖來表示，在數據庫視圖中隱含了信源/信宿與公共實體之間的關聯，并且包含每個數據元素的語義信息。EJB仲裁器可以根據不同情況選擇適當的轉換函數。除了模式關聯以外，在信源/信宿模式中的每個屬性都有相應的元數據，用來描述其含義和特征（如精度、單位等）。數據元素的含義由公共數據字典定義。每當需要在信源模式和信宿模式之間建立數據元素的關聯時，EJB仲裁器通過搜索轉換函數庫來組織過程調用序列。
??? 下面解釋客戶端應用怎樣通過API調用來訪問EJB仲裁器。
??? 最簡單的情況是客戶端應用和EJB仲裁器位于同一JVM上，此時客戶端應用可以直接調用EJB仲裁器提供的API接口。但在通常情況下，客戶端應用與EJB仲裁器分布在不同的服務器上，這時需要借助CORBA、.NET、RMI等分布式計算技術來提供仲裁服務。
??? 我們采用CORBA技術，即將EJB仲裁器與CORBA服務器綁定，并以CORBA服務的形式提供API接口。
??? 下面具體介紹客戶端程序怎樣利用CORBA訪問不同Java虛擬機上的EJB仲裁服務。
??? （1）啟動EJB仲裁服務器
??? 通過位于
??? 如果利用缺省的配置文件啟動EJB仲裁器，可以啟動它提供的所有服務，但不能在CORBA注冊表中綁定仲裁服務API接口。
??? （2）配置參數
??? 為了將EJB仲裁服務與CORBA服務綁定，需要編輯位于
??? 在將路徑設置為
??? 下面用一個實例程序來說明客戶端程序訪問EJB仲裁器的過程。
import org.omg.CORBA.ORB;
import org.omg.CosNaming.NameComponent;
import org.omg.CosNaming.NamingContext;
import org.omg.CosNaming.NamingContextHelper;
import com.adventnet.mediation.service.poll.corba.PollAPI_CI;
import
com.adventnet.mediation.service.poll.corba.PollAPI_CIHelper;
public class Sample
{
public Sample()
{
}
public static void main(String[] args)
{
try
{
// 創建并初始化ORB
ORB orb = ORB.init(args, null);
// 獲得命名服務
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
// 對象引用
NameComponent nc = new NameComponent("PollAPI", "");
NameComponent path[] = {nc};
// 為PollAPI_CI取句柄
PollAPI_CI api = PollAPI_CIHelper.narrow(ncRef.resolve(path));
System.out.println(" 被初始化為 " + api.isInitialized());
}
catch (Exception e)
{
System.out.println(“在通過CORBA訪問PollAPI時出現異常” + e);
}
}
}
5 結束語
??? 數據互操作性是當前信息系統面臨的重要問題，將來也仍然會有這種問題。數據標準化方法有助于解決這一問題，但它不是完整的解決方案。我們開發了一種基于EJB的數據仲裁服務器，用來彌補數據標準化方法丟失的部分解決方案。
數據標準化方法是數據共享的基礎，數據仲裁方法是對數據標準化方法的必要補充。數據標準化與數據仲裁相結合是今后數據互操作技術的發展方向，與之相關的一些數據互操作關鍵技術：公共表示與元數據、數據仲裁和語義仲裁、中間件、數據倉庫、XML門戶等也將成為研究熱點。
參考文獻
[1] Sciore, E., Siegel, M., Rosenthal, A. Using semantic values to facility interoperability among heterogeneous information systems. ACM Transactions on Database Systems, 1994.
[2] Jerry Smith (DISA Interoperability Directorate), “The Data Is Key”, CALS/EC International Symposium, 2001.
[3] John S. Erickson, Information Objects and Rights Management: A Mediation-based Approach to DRM Interoperability, D-Lib Magazine April 2001.
[4] Sun Microsystems White Paper, Interoperability Across the Technical Enterprise, Technical Computing in the Network Economy, 1999.
[5] OMG, The Common Object Request Broker: Architecture and Specification (Version 2.4.2), Febuary 2001.
?