基于Z39.50的數字圖書館信息檢索的研究

齊俊霞

摘 要： 圖書館的信息檢索是面向讀者服務的重要方式，讀者可以方便地檢索到所需要書刊的詳細信息和借閱情況。基于Z39.50協議的圖書館信息系統能夠實現多個圖書館之間信息的相互訪問，有利于資源共享。Z39.50協議在數字圖書館的應用雖然比較廣泛，但用Java語言實現的卻很少見，而Java語言在網絡中的應用越來越廣泛，且具有優良的跨平臺特性，因此用純Java語言實現Z39.50協議很有必要。在分析Z39.50協議和JZKit2最新版本軟件的基礎上，對JZKit2提出了改進意見，并應用較先進的技術和工具加以實現。

關鍵詞： 信息檢索； Z39.50協議； Maven2； JZKit2項目； JavaI

中圖分類號： TN911?34； TM417 文獻標識碼： A 文章編號： 1004?373X（2016）05?0143?04

基于Z39.50協議的圖書館自動化系統能夠實現多個圖書館之間信息的相互訪問，有利于資源共享[1]。現在絕大多數的圖書館自動化系統、聯合目錄系統與數據發布系統均把Z39.50協議作為主要的檢索協議來實現[2]。

Z39.50協議是分布式虛擬聯合數據庫檢索體系，其目的是實現網上多個數據庫檢索、規范查詢格式、簡化檢索過程、實現異構系統和不同圖書館系統之間的通信[3]。

目前世界上已開發了不少軟件工具包支持Z39.50協議[4]。Z39.50本身的特點及應用范圍很適合用Java語言實現[5]。JZKit項目是Knowledge Integration公司維護的、100%開放源碼的純Java工具包，它不依賴任何有知識產權的工具包（它引入的工具包如a2j，log4j，xalan，xerces等都是開源且免費的）[6]。

1 Z39.50協議

1.1 Z39.50協議的內容

Z39.50協議的目的是使客戶端和服務器端的開放互聯變得便利。由于數據庫完成的方法大不相同、不同的系統描述數據存儲的格式不同，需要采用一種通用的、抽象的模型來描述數據庫，各個系統可以將其具體實現映射到該抽象模型上。這就使得不同的系統在一個標準的、相互理解的基礎上進行通信，使客戶端可以將不同數據庫的信息集成在一起。

Z39.50協議定義了一組服務器端（Target）與客戶端（Origin）通信的規范，它是定義在OSI中應用層上的協議，主要提供查詢與獲取功能。

完整的Z39.50應用系統由Z39.50服務端（簡稱Z Server）、數據資源、Z39.50客戶端（Z Client）組成。Z39.50支持在分布式的、客戶/服務器的環境中進行信息查詢與提取，給另一個扮演服務器的計算機發出查詢請求，由服務器軟件對一個或多個數據庫進行搜索，創造一個滿足查詢條件的結果集，并將結果集中的記錄返回客戶端。客戶端在接收到查詢請求的響應后，針對服務器端所創造的查詢結果集提取所需記錄的信息或要求服務器端對此查詢結果集作進一步的操作，如圖1所示。

圖1 Z39.50系統的操作過程

1.2 Z39.50協議的實現和存在問題

Z39.50協議實際上就是一個中間協議層，通過它的轉換，可以實現異構機型、異種操作平臺之間的交互式通信，實現分布式異構數據源之間的無縫連接。

Z39.50協議是一個較為成熟的網絡檢索標準，但在目前的推廣實踐中也存在一些問題。

（1） Z39.50是一個過于完美復雜的重量級協議。其系統配置復雜，不利于非專業用戶的使用，也不利于其推廣。

（2） Z39.50協議和萬維網之間融合的障礙。主要是Z39.50協議和萬維網所使用的HTTP協議是兩種不同機制的協議。

（3） Z39.50缺少良好的發現機制。Z39.50客戶端軟件一般都必須由人工來收集Z39.50服務器地址（有些軟件預置了一些地址），無規律可循。

Z39.50協議的下一代版本（ZING）將定義一個結合Z39.50的Web服務，開發人員可以在一個已經存在的Z39.50系統上很容易地構建自己的網關系統。并且ZING應用SOAP和URL為基礎的信息獲取機制，減少了網關中Z協議方面的網絡通信瓶頸，并且信息能夠輕易地通過互聯網進行通信，而無需擔心遭到防火墻等網絡安全技術的攔截。

2 項目管理工具Maven

JZKit2項目工程是用Maven管理的，Maven現在的版本是Maven2。Maven是構建、管理任何基于Java的項目，最早始于JarkartaTurbine項目。Maven的目標是讓Java開發者的日常工作更加輕松，并有助于理解基于Java的項目。Maven一個重要特性是定義了項目的標準模板。可以通過命令： mvn archetype：create?DgroupId=com. My company.app?DartifactId=my?app創建一個單一的Maven項目。創建好的項目，具有了特定的項目結構。在項目進程中，cmd使用簡單的Maven命令，就可以完成初始化→開發→測試→發布的全過程。

在校園內，很多情況上國外網站不方便，而Maven的自動下載一般都是訪問國外網站的，這可以通過設置代理來解決。在配置文件settings.xml中，將下面一段去掉注釋，并填入實際代理服務器的信息即可：

optional

truehttp

proxyuserproxypass

proxy.host.net80local.net，some.host.com

在處理客戶請求的程序中，轉發之前先判斷是否請求本地數據源，若是直接處理，不要再轉發，如下（在jzkit2_z3950_plugin子模塊的Z3950Origin.java文件中）：

ArrayList v = new ArrayList（q.collections）；

LocalResourceDBO r = （LocalResourceDBO） user_info；

if （r ！= null）

{ log.info（"LocalResourceDBO： " + r.getName（））；

if （v.contains（r.getName（）））

{ st.setStatus（IRResultSetStatus.COMPLETE）；

st.setFragmentCount（10）； return st； } }

4.4 測試方法

分別先后啟動服務端和客戶端。在客戶端輸入任意字符（不合法的命令）就會提示正確的請求格式，按照提示輸入要查詢的數據庫和查詢請求，觀察服務端輸出。為測試需要，目前采用MySQL數據庫，在其中的各個表格中暫時插入以下數據：

LOCK TABLES；

jz_search_service_props；

WRITE； INSERT INTO；

jz_search_service_props；

（search_service_id， prop_value， prop_name）

VALUES （1， ′usmarc′， ′defaultRecordSyntax′），

（1， ′f′， ′defaultElementSetName′），

（1， ′10.1.0.203′， ′host′）， （1， ′9999′， ′port′）， （1， ′F′， ′smallSetElementSetName′），

（1， ′UTF?8′， ′charsetEncoding′），

（2， ′usmarc′， ′defaultRecordSyntax′），

（2， ′f′， ′defaultElementSetName′），

（2， ′10.1.0.236′， ′host′），

（2， ′9999′， ′port′），

（2， ′F′， ′smallSetElementSetName′），

（2， ′UTF?8′， ′charsetEncoding′）；

UNLOCK TABLES；

設置了兩個數據源：Default和gqj，這也是客戶端可以指定的數據庫名。在表格jz_search_service_props中存放了兩個數據源的信息，這里重點關注它們的主機IP信息（即列Host）。其中Default對應的數據源在本機（腳本中把主機信息設為了實際IP：10.1.0.203，沒有用回送地址127.0.0.1，這樣用該腳本可以無需修改地插入到其他機器的數據庫），gqj對應另一臺機器的數據源（這臺機器也要啟動JZKit2的服務端）。在表jz_collection_instance中每一個可以查詢的數據庫名都有一個局部名稱local_id與之對應。

在客戶端指定要查詢的數據庫是Default（即本機），服務端處理該請求，按照前面修改的方案，要先檢查請求的數據庫是否在本地，這就要求服務端“知道”本地數據庫的局部名稱，這一點是通過在前面增加的表格local_resource來實現的。在本地數據庫中插入以下數據：

LOCK TABLES ′local_resource′ WRITE；

INSERT INTO ′local_resource′ （id， name） VALUES（1， ′lmx′）； UNLOCK TABLES；

這樣服務端查詢表就知道，請求的數據庫Default就是本地的lmx，于是就直接查詢本地數據，并返回結果給客戶端。如果在客戶端指定要查詢的數據庫是gqj，服務端也要進行上面查詢local_resource的過程，通過比較知道這不是本地數據庫，就把請求轉發到表jz_collection_instance中描述的該數據庫所對應的主機10.1.0.236。在此主機的數據庫的數據也是根據前面的腳本插入的，因此描述數據資源的信息數據都相同，惟有表格local_resource的內容不同，它的數據庫有不同的本地名稱qgj，如下：

LOCK TABLES ′local_resource′；

WRITE； INSERT INTO ′local_resource′ （id， name） VALUES （1， ′gqj′）；

UNLOCK TABLES；

該主機啟動的JZKit2服務端收到請求后進行同樣的步驟，發現請求的是本地數據庫，于是根據請求查詢數據，并將數據結果返回給10.1.0.203的服務端，服務端再返回給客戶端。

5 結 論

本文在分析、研究Z39.50協議和JZKit2程序包的基礎上，對JZKit2的服務端還沒有實現的功能提出了一種實現思路，并用該包所涉及的工具和技術加以實現。 現在JZKit2客戶端的功能比較完善，可以用來測試其他Z39.50產品服務端的功能。由于JZKit2的開源特性及支持多平臺，相信它的實現不僅能吸引大量客戶廣泛采用，對Z39.50協議的推廣和普及也會做出不小的貢獻。

參考文獻

[1] 牛振東，師雪霖，葉成林.數字圖書館支撐技術領域標準規范的現狀和發展[J].我國數字圖書館標準規范建設，2003（7）：11?12.

[2] 牟有靜，候麗梅.淺談數字圖書館與全文檢索技術[J].情報科學，2012（5）：535?537.

[3] 閔峰，張福炎，黃偉紅，等.基于Z39.50的分布式聯機書目檢索[J].情報學報，2012（5）：538?543.

[4] 黃如花.數字圖書館原理與技術[M].武漢：武漢大學出版社，2011：123?124.

[5] 師雪霖.Web集成信息檢索及其在數字圖書館中的應用研究[D].北京：北京理工大學，2012：21?22.

[6] 楊萌.圖書館防盜系統漏洞的研究[J].現代電子技術，2014，37（5）：94?96.