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

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