文/耿騫 王韜略

盤點數(shù)字資源整合協(xié)議

文/耿騫 王韜略

網(wǎng)絡環(huán)境下的數(shù)字資源整合協(xié)議，為實現(xiàn)數(shù)字資源的有序組織、快速定位和有效揭示提供了工具和條件，為最大限度實現(xiàn)數(shù)據(jù)共享、制定資源整合和數(shù)據(jù)傳輸?shù)囊徽滓?guī)范提供保證。

數(shù)字資源整合是指依據(jù)一定的需要，通過數(shù)字資源無縫鏈接系統(tǒng)，將不同來源和不同通信協(xié)議的數(shù)據(jù)融合，使不同類型、不同格式的數(shù)字資源實現(xiàn)無縫鏈接，將眾多相對獨立的數(shù)字資源按照它們之間的內在聯(lián)系進行重組，形成統(tǒng)一的、高效利用的數(shù)字資源環(huán)境。通過整合的數(shù)字資源系統(tǒng)，具有集成檢索功能，是一種跨平臺、跨數(shù)據(jù)庫的資源體系。數(shù)字資源整合目的是在于提升網(wǎng)絡環(huán)境下不同結點的數(shù)據(jù)之間的關聯(lián)度，解決信息孤島問題，向終端用戶提供一站式服務，用戶在統(tǒng)一的集成界面中檢索、瀏覽和使用所有數(shù)字化資源，從而提高系統(tǒng)資源的利用效率。

基于邏輯視圖的虛擬化整合策略的特點是對各個分散的數(shù)據(jù)源進行邏輯視圖上的虛擬集成，不要求對數(shù)據(jù)進行集中存儲。為了滿足適用于不同場景的數(shù)字資源整合的需求，人們制定了多種協(xié)議對資源進行鏈接。數(shù)字資源整合的效率和優(yōu)度，在很大程度上依賴于各應用協(xié)議對資源的組合聯(lián)系程度，相關協(xié)議也成為數(shù)字資源整合過程中一個值得關注的重要問題。

數(shù)字資源整合的前提不要求資源實體存儲的一致性，在其研究發(fā)展過程中，人們制定的諸多相關整合協(xié)議從資源整合的邏輯視圖上著手，對資源從數(shù)據(jù)層、中間層和功能層等層面進行組織和關聯(lián)。

數(shù)據(jù)層整合協(xié)議

數(shù)據(jù)整合是對各異構的、自治的外部數(shù)據(jù)源進行收集、組織、處理與集成，通過面向各類數(shù)據(jù)源的有針對性的抽取、轉換，消除不同數(shù)據(jù)源之間的主鍵、命名、語義等沖突問題，屏蔽數(shù)據(jù)源的差異性。數(shù)據(jù)整合的結果令用戶可透明地訪問多個數(shù)據(jù)源，使用戶以為是在操作單一的數(shù)據(jù)源。

典型的協(xié)議是STARTS協(xié)議。STARTS協(xié)議是1996年由斯坦福大學數(shù)字圖書館組聯(lián)合幾家搜索引擎制造商共同在“分布式異構資源的檢索”中設計的。此后，哥倫比亞大學于DL2項目中在STARTS協(xié)議的基礎上提出SDARTS協(xié)議，1999年，美國的康奈爾大學數(shù)字圖書館研究組利用CORBA為底層傳輸層實現(xiàn)了該協(xié)議。

STARTS為高層信息搜索建立了統(tǒng)一的查詢接口，便于對分布的文本信息進行查詢。協(xié)議描述了如何查詢源以及這些源給出哪些元信息。該協(xié)議的體系結構中包含許多資源，而每個資源又可由一個或多個資源組成，同時簡單地給出關于這些源的聯(lián)系信息。一個源即一些簡單文檔的集合，源與搜索引擎連接，由搜索引擎接受來自客戶端的查詢請求，并產生查詢結果。一個源可以很小也可以很大。

通常一個元搜索器或任何一個終端客戶端會向多個源提交查詢請求。因此一個元搜索引擎會執(zhí)行以下2個任務：1.定期從各個源提取源列表，以找出哪些源可用于查詢；2.定期提取各個源的元數(shù)據(jù)與內容概要，以判斷哪些源對于某個指定查詢是潛在有用的。在資源檢索的過程中，用戶向元搜索器發(fā)出一個請求，元搜索器再將此請求傳遞給各種資源，并將返回結果進行整合。STARTS便于對分布的文本信息進行查詢，整個協(xié)議簡單并易于實現(xiàn)，具有很強的可擴展性和靈活性。但為了設計簡單等原因，STARTS忽略了很多重要的問題，例如STARTS只支持對文本信息的查詢，并沒有包含進行錯誤處理的機制，同時也沒有考慮數(shù)據(jù)傳輸?shù)陌踩珯C制。

中間層整合協(xié)議

中間層對應用邏輯進行單獨處理，從而使用戶界面和應用邏輯處于不同的平臺上，二者之間的傳輸協(xié)議由系統(tǒng)自行定義，應用邏輯為所有用戶共享。

Z39.50

Z39.50 是關于信息檢索的ANSI/NISO標準，是基于ISO的OSI參考模型的應用層協(xié)議。它定義了兩個機器之間信息檢索的標準路徑和方法，讓用戶、信息需求者在多個大型數(shù)據(jù)庫之間信息檢索變得更加容易。Z39.50的實現(xiàn)主要有：客戶機、服務器和支持該協(xié)議的一個或多個數(shù)據(jù)庫。

Z39.50的特點在于將用戶接口與信息源分離開來，用戶不需要在各種不同操作平臺使用不同數(shù)據(jù)庫管理系統(tǒng)，在不同檢索引擎的數(shù)據(jù)庫中更改檢索手段和自己的對外接口。用戶可以忽略各種不同數(shù)據(jù)源的不同點，不必學習各種不同的檢索命令，只需要用自己最熟悉的方式，而把轉換的工作都交給Z39.50協(xié)議的一整套軟件服務去解決。因此，Z39.50是跨平臺的協(xié)議。

Z39.50協(xié)議自推出以來，主要面向圖書館、博物館、信息服務領域、零售領域、咨詢等領域的信息檢索系統(tǒng)；支持的數(shù)據(jù)類型有：各種用ISO2709傳輸?shù)臄?shù)據(jù)，如UNIMARC、USMARC、CCFC、SURTS、XML數(shù)據(jù)，結構化數(shù)據(jù)，文本化數(shù)據(jù)和非結構化數(shù)據(jù)等。如圖1所示。

圖1 Z39.50 應用結構

OpenURL/SFX

OpenURL是一種開放鏈接的框架。SFX是OpenURL的一個具體的應用，它通過鏈接服務器來提供鏈接服務。這種服務是信息源外部的且獨立于信息源。在互聯(lián)網(wǎng)上，用戶要使用不同的數(shù)據(jù)庫，需要分別登錄不同的數(shù)據(jù)庫系統(tǒng)進行操作，即每次使用一種數(shù)據(jù)庫時，都要熟悉一種新的界面和使用方法，這樣非常繁瑣。提供統(tǒng)一的數(shù)據(jù)界面是OpenURL產生的一個主要原因。

OpenURL是持有元數(shù)據(jù)的資源提供商和提供合適服務的服務提供商之間的連接要件，只要數(shù)據(jù)提供商能支持OpenURL語法，就可以通過OpenURL使上述機制的開放鏈接系統(tǒng)得以廣泛應用。

OpenURL的兩個核心特征是開放和上下文敏感。 針對一般的URL網(wǎng)絡服務中的靜態(tài)連接和死連接的情況，OpenURL提出了一種開放鏈接的框架，在該框架中通過建立鏈接服務器提供鏈接服務，并提出一套公共的OpenURL語法，允許信息源公開自己的鏈接接口，實現(xiàn)鏈接信息源和鏈接服務器之間的信息傳輸，從而實現(xiàn)異質數(shù)據(jù)庫之間的互操作。

OpenURL的服務流程如圖2所示。

圖2 OpenURL服務流程

SDLIP

1999年由美國斯坦福大學、伯克利大學等合作開發(fā)了SDLIP協(xié)議（Simple Digital Library Interoperability Protocol），該協(xié)議從底層傳輸層設計，通過定義公共接口來方便各個資源之間的交互，該協(xié)議注重網(wǎng)絡之間的數(shù)據(jù)傳送，采用CORBA或HTTP/DASL來實現(xiàn)。

SDLIP作為一個代理封裝外部資源，屬于分布式檢索系統(tǒng)。系統(tǒng)中各個子數(shù)據(jù)庫系統(tǒng)分別提供符合統(tǒng)一標準的信息檢索接口，執(zhí)行信息檢索時由核心系統(tǒng)負責協(xié)調各個子數(shù)據(jù)源完成檢索請求。

SDLIP是一個基于XML的查詢/響應協(xié)議，工作于客戶機/服務器模式，既能支持服務器的有狀態(tài)操作，又能支持服務器的無狀態(tài)操作；既可以同步響應查詢，又可以異步響應查詢；不僅具有檢索元數(shù)據(jù)的功能，而且具有服務器過載時委托查詢的功能。

SDLIP協(xié)議的功能通過定義3個接口，即搜索接口、數(shù)據(jù)源元數(shù)據(jù)接口和結果訪問接口實現(xiàn)。

客戶機程序通過搜索接口請求對數(shù)據(jù)源執(zhí)行搜索服務，并且允許為搜索操作指定參數(shù)，包括：選擇要搜索的館藏、希望立即返回的文檔個數(shù)、文檔的特性(標題/作者/摘要等)以及與這些結果交互的時間。

數(shù)據(jù)源元數(shù)據(jù)接口允許客戶機程序查詢館藏對外服務的能力，如館藏的名稱、可供使用的查詢語言、文檔的特性以及可供搜索和檢索的文檔的特性等。

結果訪問接口允許客戶機程序訪問結果集，包括：檢索到的文檔總數(shù)、結果集可保持的時間以及對該接口所能發(fā)出的請求(如請求附加文檔) 。結果訪問接口僅適用于能夠維持狀態(tài)的服務器，對無狀態(tài)的服務器不起作用。

SDLIP協(xié)議使用LSP（Library Service Proxy，圖書館服務代理）實現(xiàn)這三種公共接口，對一個或多個數(shù)據(jù)源進行低層封裝。LSP隱藏圖書館網(wǎng)絡信息系統(tǒng)中信息資源之間訪問的差異性，將這些資源通過統(tǒng)一界面提供給用戶，用戶端通過與LSP交互來達到訪問各個數(shù)據(jù)源的目的。

功能層整合協(xié)議

功能層整合是指對信息系統(tǒng)的功能進行重組，以實現(xiàn)新的功能或者是對現(xiàn)有功能的擴充。功能整合的結果使分布式事務、過程在功能層面上實現(xiàn)整合。

WebService

它通過已發(fā)布的和可發(fā)現(xiàn)的接口為終端應用程序或其他服務提供服務。服務為封裝離散的業(yè)務功能提供更好的方法。

該協(xié)議體系由以下成員構成：

1.服務提供者為處理特定任務的軟件資源提供服務接口，它能代表業(yè)務實體的服務或者代表可重用子系統(tǒng)的服務接口。

2.服務請求者發(fā)現(xiàn)并調用其他服務來解決問題。

3.服務定位器是一類充當注冊表的特定服務提供者，允許查找服務提供者接口和服務位置。

4.服務中介者是一個網(wǎng)絡節(jié)點，產生由服務提供者發(fā)布的軟件接口。業(yè)務實體或者獨立的運營商都能代表服務中介者。

服務提供者、服務中介者和服務請求者通過發(fā)布、查找、綁定3個基本操作相互作用。服務提供者向服務中介者發(fā)布服務，服務請求者通過服務中介者查找所需的服務，并綁定到這些服務上。

實現(xiàn)的技術和服務標準包括：

SOAP（Simple Object Access Protocol）是分布式環(huán)境下基于XML的輕量級信息交換協(xié)議，它在請求者和提供者之間定義了一個通訊協(xié)議，這樣，在面向對象編程流行的環(huán)境中，該請求對象可以在提供的對象上執(zhí)行遠程方法調用。

WSDL（Web Services Description Language）為服務提供者提供簡單的方法，描述遠程方法調用的請求消息和響應消息的格式。WSDL不依賴于底層的協(xié)議和編碼要求，它提供一種抽象的語言，利用各自的參數(shù)和數(shù)據(jù)類型來定義被發(fā)布的操作。

UDDI（Universal Description Discovery and Integration）規(guī)范提供一組公用的SOAP API，實現(xiàn)服務中介。UDDI用于基于Web的服務創(chuàng)建、描述、發(fā)現(xiàn)和集成。

Dienst

該協(xié)議是在數(shù)字圖書館中應用最早的協(xié)議之一。它作為計算機科學技術報告計劃的一部分，是由施樂公司Jim Davis和康奈爾大學CarlLagoze開發(fā)的分布式數(shù)字圖書館協(xié)議和體系結構。它是一個面向文檔檢索服務的大型復雜協(xié)議，支持對自治館藏的分布式搜索。

總之，Dienst就是把運行在分布式服務器上的單獨服務整合起來，使其共同提供數(shù)字圖書館的服務系統(tǒng)。Dienst系統(tǒng)的開放式結構是通過一個詳細定義的協(xié)議來揭示的。在實際應用中，Dienst的各種服務可靈活組合，也可以在現(xiàn)有服務功能的基礎上，用其他中介服務來擴展已有系統(tǒng)。其互操作性通過采用相同的協(xié)議或軟件結構實現(xiàn)，如圖3所示。

圖3 Dienst 交互服務

LDAP

LDAP（Lightweight Directory Access Protocol）基于C/S模式，支持TCP/IP，這對訪問互聯(lián)網(wǎng)是必要的。LDAP的核心規(guī)范在RFC中有定義，所有與LDAP相關的RFC都可以在LDAPman RFC網(wǎng)頁中找到。

LDAP是用來訪問存儲在信息目錄中的信息的協(xié)議。通過使用LDAP，可以在信息目錄的正確位置讀取（或存儲）數(shù)據(jù)，LDAP目錄也是一種特殊的數(shù)據(jù)庫，但不是關系型數(shù)據(jù)庫。大多數(shù)的LDAP服務器都為讀取密集型的操作進行專門的優(yōu)化。因此，從LDAP服務器中讀取數(shù)據(jù)會比從專門為OLTP優(yōu)化的關系型數(shù)據(jù)庫中讀取數(shù)據(jù)快一個數(shù)量級。正因為專門優(yōu)化讀取的性能，所以大多數(shù)的LDAP目錄服務器并不適合存儲需要經常改變的數(shù)據(jù)。例如，用LDAP服務器來存儲電話號碼是一個很好的選擇，但是它不能作為電子商務站點的數(shù)據(jù)庫服務器。如果需要跨平臺讀取數(shù)據(jù)，數(shù)據(jù)的格式固定，并且只要滿足數(shù)據(jù)庫第一式（如果可以把數(shù)據(jù)保存在一張張卡片里，就可以很容易地把它存進LDAP目錄里），那么考慮選用LDAP協(xié)議進行數(shù)據(jù)的管理和訪問將是一個不錯的選擇。

對LDAP設計者來說，服務器與客戶機之間發(fā)送與接收信息的具體結構已由TCP/ IP協(xié)議解決，其真正關注的是所傳輸信息所定義的邏輯結構、目錄組織形式、操作方式以及對其的安全保護。LDAP的客戶機與服務器端的通用交互采取下面的形式：

用戶請求建立連接<->（采用一定的安全驗證方法）<->服務器接受并建立session <->用戶操作<->發(fā)出檢索請求<->布爾條件查詢過濾器返回匹配數(shù)據(jù)<->用戶關閉session，結束對話。

通常來講，LDAP由以下模型組成：

1.信息模型:描述信息存取模式。

2. 命名模型:描述信息的組織和標識方式。

3.功能模型:描述對信息進行的操作。

4.安全模型:描述如何保護LDAP目錄中的信息，防止沒有授權的訪問。

（作者單位為北京師范大學管理學院）