[摘要]從系統(tǒng)實現(xiàn)的角度，將信息集成中的關(guān)鍵技術(shù)――異構(gòu)數(shù)據(jù)源的訪問機制分為4類：基于HTTP協(xié)議、基于標準接口協(xié)議、基于API以及基于本地數(shù)據(jù)庫接口的訪問機制，對其基本原理、特點和使用原則加以詳細介紹，并對這些信息獲取機制的優(yōu)勢和劣勢進行深入分析和對比，提供多種協(xié)議的選擇原則，簡單描述其實現(xiàn)策略，以便對其進行封裝后加以集成。
　　[關(guān)鍵詞]異構(gòu)數(shù)據(jù)源　信息集成　訪問機制
　　[分類號]G250.76
　　
　　1　引言
　　
　　隨著計算機技術(shù)特別是Web的迅猛發(fā)展，越來越多的數(shù)據(jù)在Web上發(fā)布，并具備比較便利的訪問接口，使用戶可以方便快捷地獲取各類信息。但是，由于數(shù)據(jù)提供方及專業(yè)領(lǐng)域的不同，每個數(shù)據(jù)源幾乎都是異構(gòu)的，因而它們之間的信息、組織和接口都不一樣，這就構(gòu)成了一個巨大而復(fù)雜的異構(gòu)數(shù)據(jù)環(huán)境。只有將這些孤立的數(shù)據(jù)都集成起來，提供給用戶一個統(tǒng)一的視圖，才有可能從巨大的數(shù)據(jù)資源中獲取所需的東西。為了集成這些數(shù)據(jù)，關(guān)鍵環(huán)節(jié)之一是將異構(gòu)的訪問接口進行封裝，屏蔽各種數(shù)據(jù)源的差異，使這些異構(gòu)系統(tǒng)“互聯(lián)互通”。本文主要分析和探討各類數(shù)據(jù)源的數(shù)據(jù)訪問機制，為進一步的接口封裝奠定基礎(chǔ)。
　　
　　2　異構(gòu)數(shù)據(jù)源的訪問機制分析
　　
　　目前數(shù)據(jù)資源的結(jié)構(gòu)及接口形式各異，所支持的接口協(xié)議主要包括：HTTP、Z39，50、JDBC、ODBC、SOAP(Simple Ob―ject Access Protoc01)、Web Service、LADP(Lightweight DirectoryAccess Protocol)等。
　　針對目前異構(gòu)數(shù)據(jù)源所支持的協(xié)議集，可將訪問機制大致劃分為4類：①基于HTTP的訪問機制；②基于標準接口協(xié)議的訪問機制；③基于API的訪問機制；④基于本地數(shù)據(jù)庫接口的訪問機制。每種訪問機制均有其自身的特點及其適用范圍，面對紛繁復(fù)雜的網(wǎng)絡(luò)資源，集成時需要針對各類資源的具體情況進行區(qū)別對待。有些資源只支持一種訪問機制，而還有一部分資源則允許多種協(xié)議對其進行訪問。每種連接技術(shù)或協(xié)議都有其優(yōu)點及缺點，因此，如果一種資源可以通過多種連接方式獲取，那么在數(shù)據(jù)訪問模塊中應(yīng)確定優(yōu)選的連接方案。具體地說，通過HTTP協(xié)議可以檢索許多網(wǎng)絡(luò)資源，但是檢索結(jié)果的集成需要對網(wǎng)頁進行解析，因此它的結(jié)構(gòu)性最差，應(yīng)盡量采取其他標準接口的協(xié)議，以保持系統(tǒng)的穩(wěn)定性和標準化。通過數(shù)據(jù)庫接口軟件與不同的數(shù)據(jù)庫直接連接，在同時檢索的數(shù)據(jù)庫數(shù)量較少時，使用此技術(shù)可在一定程度上解決異構(gòu)檢索問題，但數(shù)據(jù)庫達到一定數(shù)量時，處理速度很難保證。這種方式僅適用于對屬于本單位的少量異構(gòu)數(shù)據(jù)庫進行統(tǒng)一檢索。某些數(shù)據(jù)源本身提供的檢索接口API，很容易識別和使用資源本身的元數(shù)據(jù)。信息集成中應(yīng)該在選擇訪問機制時綜合考慮穩(wěn)定性、標準化、開放性等多種因素。為了封裝各種協(xié)議，必須對每種協(xié)議進行分析研究，以下筆者結(jié)合實際開發(fā)經(jīng)驗，分析上述4類訪問機制的實現(xiàn)技術(shù)。
　　
　　2.1　基于HTFP的訪問機制
　　現(xiàn)有各種數(shù)據(jù)源都提供相應(yīng)的客戶端接口，因此可利用HTTp訪問機制向其發(fā)送檢索請求加以集成。HTTP(HyperText Transfer Protoc01)協(xié)議，即超文本傳輸協(xié)議，是WWW服務(wù)器使用的主要協(xié)議。它是一個屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議，由于其簡捷、快速的方式，適用于分布式超媒體信息系統(tǒng)。HTrP協(xié)議基于請求／響應(yīng)方式，客戶／服務(wù)器模式中信息交換的實現(xiàn)過程主要包括建立連接、發(fā)送請求、發(fā)送響應(yīng)和關(guān)閉連接4個步驟。HTTP協(xié)議是支持信息集成的最基本協(xié)議，通過它實現(xiàn)與分布式網(wǎng)絡(luò)數(shù)據(jù)庫、電子期刊等信息資源的連接，執(zhí)行檢索與瀏覽操作。
　　在實際應(yīng)用中，不同數(shù)據(jù)源的Web處理接口存在很多細節(jié)上的差別，筆者對所掌握的各種情況進行總結(jié)，歸納出以下差別：
　　2.1.1　檢索請求的發(fā)送方式大部分數(shù)據(jù)源都可以同時支持GET請求和POST請求，但也有一些數(shù)據(jù)源只接受POST請求，應(yīng)進行區(qū)別對待。
　　2.1.2　檢索請求URL的分析成本大部分數(shù)據(jù)源的集成都需要經(jīng)過一定的人工分析，對它的檢索機制要有一定的了解，但有一小部分數(shù)據(jù)源的集成幾乎是“零成本”，即幾乎不用進行分析就可以輕松集成。具體來說，在數(shù)據(jù)源的檢索頁面中輸入檢索詞，執(zhí)行檢索后進入檢索結(jié)果頁面，包含各種參數(shù)的檢索請求URL在瀏覽器的地址窗口中完全呈現(xiàn)，檢索引擎只需根據(jù)具體情況改變檢索參數(shù)值，以POST或GET方式向數(shù)據(jù)源發(fā)送檢索請求，即可返回檢索結(jié)果。這種數(shù)據(jù)源可以很容易地加以集成，但這種情況非常少見。
　　大部分數(shù)據(jù)源在執(zhí)行檢索后，向用戶呈現(xiàn)的檢索結(jié)果頁面并不會直接將檢索請求的所有參數(shù)顯示在地址欄中，而只是顯示結(jié)果頁面的基本URL，如果檢索引擎直接利用這個URL作為檢索請求，由于參數(shù)不足，不能正確返回檢索結(jié)果。因此在將這類資源添加到集成檢索系統(tǒng)中時，開發(fā)人員還必須對數(shù)據(jù)源的檢索頁面進行細致分析，查找各種隱藏或顯式的檢索參數(shù)，將其進行組配，才能得到有效的檢索請求。
　　因此，根據(jù)這一點可以將數(shù)據(jù)源分為兩類：①檢索請求直接呈現(xiàn)；②檢索請求間接轉(zhuǎn)換。
　　2.1.3　檢索請求的動態(tài)參數(shù)值向每個數(shù)據(jù)源發(fā)送的檢索請求中除了基本的服務(wù)器地址，還包括多種參數(shù)，只有這些參數(shù)互相配合才能真正從數(shù)據(jù)源得到檢索結(jié)果，訪問信息源的參數(shù)可以存放到請求URL或?qū)嶓w當中。每個參數(shù)的形式一般都是“參數(shù)名=參數(shù)值”，參數(shù)之間用“&”連接。參數(shù)分成兩種：一種是固定值的，另一種是動態(tài)值的。動態(tài)值的參數(shù)可以與信息源訪問算子中捆綁約束謂詞內(nèi)出現(xiàn)的屬性作對應(yīng)，其中參數(shù)名對應(yīng)屬性名，參數(shù)值對應(yīng)捆綁約束謂詞內(nèi)的具體屬性值。因此，只要建立捆綁約束謂詞內(nèi)屬性名到訪問參數(shù)名的固定映射以及捆綁約束謂詞內(nèi)屬性值到訪問參數(shù)值的映射函數(shù)，就能實現(xiàn)信息源的訪問。
　　動態(tài)變化的參數(shù)一般是數(shù)據(jù)源的檢索系統(tǒng)為用戶的每次會話建立的標識SessionID。根據(jù)這一點可以將數(shù)據(jù)源分為以下三類。
　　?檢索請求中不包含會話標識。向這一類數(shù)據(jù)源發(fā)送的檢索請求中不包含SessionID，這就意味著同一個檢索請求無論什么時候發(fā)送都可以從遠端的服務(wù)器得到響應(yīng)，不會有會話過期的問題。
　　?檢索請求中顯式包含會話標識。某些數(shù)據(jù)源在用戶進入檢索頁面時，會給用戶分配一個隨機生成的會話標識，只要用戶沒有退出或會話沒有超過時效，用戶的相關(guān)信息就會保存在Session中，數(shù)據(jù)源的檢索系統(tǒng)將根據(jù)該標識識別用戶的相關(guān)操作，因此在將這類數(shù)據(jù)源集成到系統(tǒng)中時，集成系統(tǒng)應(yīng)在多次發(fā)送的檢索請求中包含會話標識，才能得到最終的檢索結(jié)果，對于不同的數(shù)據(jù)源有時需要獲取多個會話標識。
　　?檢索請求中隱式包含會話標識。用戶在使用某些數(shù)據(jù)源的檢索系統(tǒng)時，需要賬號登錄后才能進行檢索。將這類數(shù)據(jù)源集成到系統(tǒng)中時，檢索引擎應(yīng)模擬人工手動向數(shù)據(jù)源 提交用戶名和密碼。這種類型與上述的第二類比較相似，都需要檢索引擎向數(shù)據(jù)源發(fā)送的多次請求保持連貫性，但不同的是后者可以得到一個保證操作連續(xù)性的會話標識，而前者卻是在瀏覽器中隱含著為用戶分配的標識，用戶需帶著這個標識才能保持登入的狀態(tài)。
　　2.1.4　完成一次檢索需要發(fā)送請求的次數(shù)　對不同的數(shù)據(jù)源來說，要完成一次檢索，檢索引擎需要發(fā)送的檢索請求次數(shù)是不同的。某些數(shù)據(jù)源只要經(jīng)過一次連接就可以得到檢索結(jié)果。對于一些需要建立Session的數(shù)據(jù)源(2.1.3中的第二、三類數(shù)據(jù)源)，則要經(jīng)過多次檢索請求的發(fā)送才能得到最終的檢索結(jié)果。另外還存在一部分數(shù)據(jù)源在多次發(fā)送檢索請求后，只能得到帶有檢索結(jié)果頁面URL的網(wǎng)頁，檢索引擎在處理這些數(shù)據(jù)源時，需要利用人工分析的結(jié)果進行重新定位，才能得到最終檢索結(jié)果。
　　對于任何采用HTTP訪問機制進行集成的數(shù)據(jù)源，我們都可以用上述4個指標進行衡量，只要把數(shù)據(jù)源的這些方面進行充分了解，就可以“對癥下藥”采取相應(yīng)的策略，從而將其進行整合。
　　HTTP連接是目前在檢索引擎中最常用的信息獲取機制，其主要原因有以下幾點：首先，采用HTTP訪問機制可以進行無障礙通信，由于采用端口80，從而可以避開防火墻的阻擋，取得檢索結(jié)果；其次，通信過程簡單快速，檢索引擎向服務(wù)器請求服務(wù)時，只需傳送請求方法和路徑，請求方法常用的有GET、POST、HEAD等，每種方法規(guī)定了客戶端與服務(wù)器聯(lián)系的類型不同；再次，HTTP允許傳輸任意類型的數(shù)據(jù)對象，較其他協(xié)議更靈活；最后，HTT P的通信過程屬于無連接狀態(tài)，無連接的含義是限制每次連接只處理一個請求，服務(wù)器處理完檢索引擎的請求，并收到應(yīng)答后，即斷開連接，采用這種方式可以節(jié)省傳輸時間。
　　不過HTTP訪問機制也存在一定的缺點，主要是在集成數(shù)據(jù)源時，需要對它們的Web處理接口一一進行詳盡分析，比較繁瑣；另一方面，由于網(wǎng)絡(luò)資源更新頻率越來越快，各個數(shù)據(jù)庫的Web處理接口也經(jīng)常發(fā)生變化，一旦發(fā)生細微的改變，就需要重新進行分析設(shè)計，接口的穩(wěn)定性較差。如果從結(jié)果處理的角度出發(fā)，HTTP連接所獲得的檢索結(jié)果是不甚規(guī)范的HTML網(wǎng)頁，為結(jié)果整合提供了一定的難度。因此，如果數(shù)據(jù)源同時支持HTTP協(xié)議及其他標準接口協(xié)議，建議還是采取標準接口協(xié)議進行連接。
　　
　　2.2　基于標準接口協(xié)議的訪問機制
　　除了常見的HTTP訪問機制外，還有很多數(shù)據(jù)源是支持標準接口協(xié)議訪問機制的，采用標準接口協(xié)議的檢索引擎一般比較穩(wěn)定，獲得的檢索結(jié)果格式統(tǒng)一、結(jié)構(gòu)標準，對于這些數(shù)據(jù)源的集成需要對這些協(xié)議有一定的了解。目前檢索引擎中采用的標準接口協(xié)議主要包括Z39.50t、OAI(Open Ar－chives Initiative)、OpenURL和SOAP，它們的主要目的都是提供整合性的信息查尋與連接服務(wù)。
　　采用Z39.50協(xié)議的檢索引擎主要應(yīng)用于對書目數(shù)據(jù)庫的檢索。這種開放網(wǎng)絡(luò)平臺上的應(yīng)用層協(xié)議，支持不同數(shù)據(jù)結(jié)構(gòu)、內(nèi)容、格式的系統(tǒng)之間的數(shù)據(jù)傳輸，可以實現(xiàn)異構(gòu)平臺、異構(gòu)系統(tǒng)之間的互聯(lián)與查詢。OAI屬于基于元數(shù)據(jù)搜尋和檢索的分布式系統(tǒng)，通過OAI，可以實現(xiàn)對“深層網(wǎng)絡(luò)(deep Web)”資源的訪問。OAI具有很好的開放性和適用性，使得不論各個數(shù)據(jù)庫內(nèi)部結(jié)構(gòu)如何，都可以將它們靈活地無縫連接起來。OpenURL是在基于Web的學(xué)術(shù)信息環(huán)境下實現(xiàn)開放互連的機制。作為需要與外界建立鏈接的資源，只要遵循OpenURL，原則上就可以與任何資源(或者服務(wù))建立鏈接，而無需關(guān)注鏈接對象的平臺和規(guī)則。SOAP是在分散或分布式的環(huán)境中交換信息的簡單協(xié)議，通過采用標準化的動作，調(diào)用遠程過程來檢索特定的信息對象系統(tǒng)，從而解決跨平臺的程序溝通問題。
　　同HTFP訪問機制一樣，標準接口協(xié)議在資源集成方面同樣存在各種優(yōu)勢和劣勢。筆者將從以下幾個方面對這4種標準接口協(xié)議進行比較說明。
　　2.2.1　訪問機制的跨平臺性及可擴展性這4種協(xié)議都是將成熟的基于HTTP的Web技術(shù)與XML的靈活性和可擴展性組合在了一起，其最大優(yōu)點是不受特定的平臺或語言的局限，因此采用這些標準接口協(xié)議作為訪問機制可以擴大集成數(shù)據(jù)源的范圍。
　　2.2.2　訪問機制的可靠性相對于HTTP協(xié)議的無狀態(tài)性，有狀態(tài)、確認性的網(wǎng)絡(luò)連接方式可以保證數(shù)據(jù)傳輸?shù)目煽啃耘c安全性，但這種有狀態(tài)的連接方式可能引起系統(tǒng)并發(fā)數(shù)的限制。Z39.50協(xié)議即屬于后者，一旦建立SOCKET連接，在整個過程中將一直保持，客戶端很長時間不與服務(wù)端交互，也要占用連接資源。其他三種標準接口協(xié)議則是屬于無確認性的訪問機制。
　　2.2.3　整合檢索模式主要分為兩種：①采用標準接口協(xié)議，自動批次獲取各個數(shù)據(jù)源的元數(shù)據(jù)，如OAI；②通過標準接口協(xié)議實時檢索數(shù)據(jù)源，如Z39.50、SOAP、OpenURL。對于使用者而言，前者查詢速度較快。
　　2.2.4　實現(xiàn)復(fù)雜度這4種標準接口協(xié)議都是經(jīng)過認證的國際標準，具備了穩(wěn)定性、開放性等多種優(yōu)勢，相較于其他非標準接口協(xié)議，實現(xiàn)方式也很簡單。但這4種協(xié)議的復(fù)雜度有所不同：Z39.50的應(yīng)用實現(xiàn)最為復(fù)雜，主要原因在于抽象的記錄語法、RPN的檢索表達式、ASN.1的傳輸方式，復(fù)雜的屬性集支持等；OpenURL、OAI、SOAP均是相當簡單的協(xié)議。
　　2.2.5　字符支持檢索引擎從各個異構(gòu)數(shù)據(jù)源獲得檢索結(jié)果后，結(jié)果處理模塊要對它們進行整合，整合工作的一部分就是將字符編碼進行轉(zhuǎn)換、規(guī)范，其中需要特別關(guān)注的是中文問題。Z39，50的返回信息中字符編碼種類繁多，如GBK、GB2312、EACC、CCCII等，檢索引擎需要對每種情況進行特殊處理，相對比較復(fù)雜。OpenURL主要是以強化超級鏈接為目的，沒有中文化問題。
　　總之，盡管還存在種種不足，但標準接口協(xié)議是信息集成的推薦使用訪問機制，不僅接口穩(wěn)定，而且格式統(tǒng)一的結(jié)果有利于進行結(jié)果整合。
　　
　　2，3　基于API的訪問機制
　　
　　除了以上通用的、常見的協(xié)議，某些數(shù)據(jù)源本身提供公開的接口API，在集成這些資源時可以利用這些API來構(gòu)建檢索引擎，從而可以在接口比較明確的情況下，以靈活的方式將數(shù)據(jù)源有效集成。采用這種機制的檢索引擎相對穩(wěn)定，結(jié)果整合比較容易。
　　例如搜索引擎Coogle提供對外開放的查詢接口API，可以讓全世界各地的Java以及NET程序員，通過Web服務(wù)接口訪問其索引。這就是說，開發(fā)人員可以采用編程的方法將請求發(fā)送到Google服務(wù)器，然后取回結(jié)果。雖然這些請求的參數(shù)與用戶通過Web界面進行正常的COogle搜索使用的所有參數(shù)完全一樣，但是程序員可以在程序內(nèi)部控制這些參數(shù)。程序員還可以利用其他一些信息，如拼寫建議服務(wù)器。這就是說，可以寫一個能利用Google引擎來檢查用戶的拼 寫并提出建議的應(yīng)用程序。檢索得到的輸出結(jié)果規(guī)范統(tǒng)一，API中提供了各種查找設(shè)定方法，例如從第幾筆開始查找、設(shè)定傳回筆數(shù)、偏好查找(避免查找“java”時傳回“咖啡”的結(jié)果)等。
　　目前，Google的API還沒有提出正式的運營模式和收費方式，處于測試階段，因此，在API的使用上還有一些限制。例如，使用這些API需要申請一個賬號，取得一個32位長度的license key，每次呼叫查詢時，必須發(fā)送這個license key才能使用。對于免費申請的賬號，為了防止開發(fā)人員不正當?shù)氖褂�，限制每個賬號、每天最多只能查詢1 000次，每次最多返回10條搜索結(jié)果，通過這個服務(wù)只能找到前1 000條結(jié)果。另外，由于這是一個試驗性的服務(wù)，Google可能為維護而關(guān)掉服務(wù)，可能修改了API而導(dǎo)致與開發(fā)人員的程序不兼容，或干脆不再提供這項服務(wù)，因此，信息集成過程中還應(yīng)密切關(guān)注各種API的動態(tài)。
　　
　　2.4　基于本地數(shù)據(jù)庫接口的訪問機制
　　在異構(gòu)資源中，各單位的自建數(shù)據(jù)庫也是相當重要的一部分數(shù)據(jù)源，這些數(shù)據(jù)源與其他網(wǎng)絡(luò)數(shù)據(jù)源的相同點是通過互聯(lián)網(wǎng)提供服務(wù)，其對外服務(wù)接口可能屬于本文前面介紹的種種類型，不同的是集成系統(tǒng)的開發(fā)人員可以直接獲得數(shù)據(jù)源的詳細底層接口、數(shù)據(jù)結(jié)構(gòu)、裸數(shù)據(jù)等。
　　由于目前比較成熟的數(shù)據(jù)庫都存在相應(yīng)的數(shù)據(jù)庫接口軟件，因此集成系統(tǒng)的檢索引擎可以利用這些接口軟件(如JDBC、ODBC等)，將用戶的查詢請求轉(zhuǎn)換為數(shù)據(jù)庫查詢語句執(zhí)行檢索，進而將其集成到系統(tǒng)中。采用這種訪問機制集成的數(shù)據(jù)源結(jié)構(gòu)性較好，也比較穩(wěn)定、簡單，得到的檢索結(jié)果是沒有經(jīng)過任何包裝的數(shù)據(jù)，可以借助數(shù)據(jù)庫提供的功能或其他技術(shù)直接轉(zhuǎn)換成利于整合的XML文檔，因此這是一種優(yōu)先采用的機制。
　　可以采用這種機制的數(shù)據(jù)源只是占到全部資源的很小比例，因此在擴充集成資源數(shù)目及類型上作用甚微。在對數(shù)據(jù)源進行集成時，采用本地數(shù)據(jù)庫接口軟件這種訪問機制將涉及到多種數(shù)據(jù)庫驅(qū)動程序，以采用JDBC為例，SQL Server、Oracle、MySQL等數(shù)據(jù)庫所加載的驅(qū)動程序各不相同，甚至有時同一種數(shù)據(jù)庫的不同版本所采用的驅(qū)動程序也有差別，如SQL Server2000和SQL Server 7.0。因此，需要針對不同類型的數(shù)據(jù)庫采用不同的連接器，并了解每種驅(qū)動程序的機制。另外，使用JDBC訪問數(shù)據(jù)記錄的速度會受到一定程度的影響，從而影響系統(tǒng)整體的檢索速度。
　　
　　3　結(jié)論
　　
　　目前而言，數(shù)據(jù)類型及來源的不同導(dǎo)致各個數(shù)據(jù)源不可能提供統(tǒng)一的訪問接口，尚無完美的解決方案可以集成所有的電子和網(wǎng)絡(luò)資源，但是針對不同的需求、平臺或是系統(tǒng)、資源，都有不同的、適合的集成技術(shù)和協(xié)議。因此應(yīng)針對不同的需求和方式，結(jié)合適合的資源集成技術(shù)和協(xié)議，發(fā)揮最大的整合效益，通過保證用戶可以獲得大量多樣的相關(guān)資源，而基于Wrapper的封裝技術(shù)可以實現(xiàn)這個目標，內(nèi)部封裝的各個組件能夠連接支持不同協(xié)議集的目標數(shù)據(jù)源，實現(xiàn)對用戶的透明化，并可以通過新增組件方便地進行擴充，從而實現(xiàn)對任何協(xié)議資源的連接功能。

相關(guān)熱詞搜索：數(shù)據(jù)源 機制 集成 信息集成中的數(shù)據(jù)源訪問機制分析 輿情信息匯集分析機制研究 什么是機制分析