常 璐,夏祖奇
(1.中共江蘇省委黨校,江蘇 南京 210013;2.南京思酷信息科技有限公司,江蘇 南京 210012)
網絡時代的信息資源正呈指數級增長,對傳統的信息機構——圖書館來說,無論是傳統的書目數據資源,還是專業數據庫,都以迅猛的速度增加著,這種改變給圖書館帶來了極大的挑戰。在數字資源激增的同時,圖書館工作人員沒有增加,如果不利用網絡平臺進行資源的共建共享活動,則要么會淹沒在信息海洋中,無所適從;要么需要增加資源的采集經費支出,重復建設。
一般來說,信息資源共建共享可以有3種方式:第一種方式就是集中式,也可以看作是星形拓撲,大家都將數據建到一個數據庫中。好處就是減少各處保存,節約硬件設備;壞處是一處出問題,則全部出問題,依賴性強,而且一種方式減少了異樣性和靈活性,比如OCLC等[1]。第二種方式則是分散式,也可以看作網絡型拓撲結構,各圖書館有自己的數據庫,需要別人的數字資源才能共享。這種方式的好處是較為靈活,可以量身定做。第三種方式是分散集中相結合,也就是各信息機構分散建設,集中保存,統一共享[2]。這種方式要求各信息機構聯系緊密,有相應的組織機構,比如Calis、Jalis等行業內系統[3]。
可以看到,在當前環境下,采用第一種方式的較少,而且這種依賴性太大。而第三種方式雖然一直在提,但更多側重于圖書館資源采集的管理上,比如集團采購、聯合目錄等,并沒有真正達到共建共享的目的。因此,在我國國情下,還是以第二種方式為主。本文將討論在單機環境和網絡環境下實現數字資源共建共享的集中模型。
圖書館數字資源共建共享的發展離不開計算機技術與通信技術的發展。數字圖書館資源按照其來源可以分為三大類:第一類是圖書館館藏書目數據資源;第二類是各類通過購買獲得的專業數據庫資源;第三類是自建特色數據庫資源。筆者認為,與計算機資源的共享相同,圖書館數字資源的共建共享可以分為以下幾個階段。
在單機版年代,基于文件的共建共享是比較通用的一種共享方式,圖書館數字資源最初的共享也是基于這種方式實現的。一家編目中心完成資源的著錄標引工作以后,可以將標引數據存為文檔。如其他單位需要該單位已經完成的標引數據,則必須將該文件(或文件的某一部分)利用物理存儲介質進行復制,再導入自己的編目文件系統或數據庫中即可。為了使共享資源具有通用性,美國國會圖書館在1970年提出了機讀編目格式標準——MARC[4],在此基礎上,ANSI組織提出了MARC21格式[5]。這種格式的確定,不僅提供了標引數據的標準化,同時也為不同國家和地區圖書館之間的共享書目數據提供了標準格式。因此,在20世紀,大部分數字資源的共享都以MARC文件作為交換單元,在多個圖書館之間利用第三方軟件進行數據的導入導出,從而實現數據的共享,其共享方式如圖1所示。

圖1 文件型共享模型注:C代表計算機終端(computer)。
這種以MARC文件作為交換介質,在不同的數據庫之間進行共享的方式存在了很長時間,并且在現在作為各個圖書館與書目提供商之間數據交換的主要方式。其優點在于MARC數據結構已經成為標準,因此共建共享十分方便,只要能夠解析MARC數據即可。而且,目前MARC文件在經過50多年的發展后,已經成為圖書館界的標準,只要能夠對MARC文件進行解析,就可以實現數字資源的共享。而缺點是MARC數據可讀性較差,因此很難用于查詢、展現。
隨著計算機技術和通信技術的發展,C/S模式架構開始出現,人們開始使用網絡資源進行資源的共享。正是基于這種背景,圖書館界開始研究自己的應用協議——Z39.50,這是一種以TCP協議作為資源共建共享的通道協議,各個編目中心之間利用Z39.50進行數字資源的共建共享。目前在常用的圖書館集成系統中都內嵌了Z39.50模塊,用來進行MARC數據的交換共享,其共享方式如圖2所示。

圖2 C/S網絡型共享模型
這種共享方式的優點是能夠在網絡上進行資源共建共享,缺點是Z39.50協議實現復雜,而且需要開一個TCP端口,安全性較差。
網絡的發展使得數字資源共建共享成為可能,但同時也帶來了很多問題,在使用Z39.50協議的過程中,要另開端口,這就給計算機帶來了安全問題;而WWW協議的盛行,使得HTTP協議的應用越來越廣泛,甚至一些私有的應用協議也可以采用HTTP來實現。因此,筆者認為,可采用Web Service技術,使用通用的基于HTTP的SOAP協議(一種運行于HTTP之上的協議)來實現圖書館資源的共建與共享。
Web Service是一種以SOAP協議作為通信協議,以XML文件作為傳輸介質的高層協議,其出現本身就是希望能夠解決異構數據的交互問題。Web服務被看作是第三代分布式計算模式,基于Web服務技術,人們能在任何時間、任何地點獲得所需要的信息資源。Web服務具有互操作性、通用性、易用性,開發人員可以利用常見的技術工具構造出各類綜合信息管理平臺等,是目前實現信息共享行之有效的技術手段[6]。Web Service是Web 2.0的技術之一,Microsoft、Google、IBM等主流軟件公司都在推廣這種技術,其共享方式如圖3所示。
可以看出,該共享方式大大縮短了數字資源之間進行轉換的流程,依托Web服務,直接通過網絡發布,可獲得性大大增強,并且解決了異構數據庫兼容共享的問題。
無論是傳統的基于文件格式的共享系統,還是基于Z39.50協議的網絡式共享系統,其共享的傳輸對象都是MARC文件或MARC數據。而MARC格式的定義是在1970年,距今已50多年,其字段定義復雜,可讀性差,掌握難度大。因此,本系統不采用MARC的實例化對象作為傳輸對象。
另一方面,DC元數據作為描述資源的元數據,自20世紀末以來,經過20多年的發展,已經較為成熟。另外,其17個字段通過實踐證明可以作為描述對象資源很好的例子。因此,本系統將DC元數據作為傳輸對象在共建共享系統中使用。
DC元數據在數字圖書館中應用較為成熟與穩定,作為通信格式較為穩妥。因此,可以將DC元數據的17個字段作為傳輸對象,將設計的對象序列化,可以成為傳輸對象。
以下為Java版本元數據對象偽碼:
public DCMetaData implements Serieable{
public String author;
pubic String titile;
public String abstract;
……
}
在上面的偽碼中,本文只列出了題目、作者等字段,其他15個字段也可以此類推。可以看出,以DC元數據定義的對象可讀性強,而且17個字段基本可以包括數字資源的特征,采用以DC元數據實例化作為傳輸對象,比MARC文件或MARC數據具有更大的優勢。
在定義傳輸對象后,本文將討論共建共享的一些基本方法。對于一個共建共享系統來說,其核心接口無非是對資源的查詢、增加、刪除和修改。下面給出了一個Java版本的核心接口偽碼:
public interface WSDigitalLibInf
{
public DCMetaData [] queryResources(DCMetaData condition);
pubic void insertResource(DCMetaData [] arrayNewResource);
public void deleteResource(DCMetaData condition);
public void modifyResource(DCMetaData src, DCMetaData des);
}
對于queryResources接口來說,只要根據用戶屬于的元數據的condition來進行查詢,比如,如果condition的author字段為A,則可以將所有作者為A的元數據返回給查詢客戶端;當然,對于高級查詢,也可以根據構造不同的condition對象實現,這里不再一一敘述。
對于insertResource接口來說,其作用就是將用戶屬于的元數據數組進行轉換插入自己的數據庫。對于deleteResource接口來說,其結果就是將滿足condition條件的元數據刪除掉。對于modify Resource來說,可以先調用deleteResource(src),再調用insertResource(des)來實現。
作為數字圖書館軟件提供商,只要實現以上接口,再以Web Service的方式進行發布,即可以在不同的系統間進行數字資源的共建共享。
這部分可以說是數字圖書館共建共享系統的核心,但目前各數字圖書館采用不同的數字存儲方式。在圖書館集成系統方面有匯文、ILAS等軟件,其對應的數據格式是MARC;在自建特色數據庫方面有TRS、TPI等軟件,其內核有ACCESS、ORACLE、SQLSERVER等,往往有自己定義的數據格式,有基于純文本的,有基于圖片的;而在購買的商業數據庫方面就更多了,其內核涉及商業機密,往往不提供接口。這種差異性就必須要求采用不同的方式來訪問數字資源存儲文件或數據庫服務器。本文無法一一展開敘述取數據的過程,可以說明的是,實現取數據的業務邏輯無非是把存貯的數字資源使用DC元數據的方式進行表示,實現一些簡單的增加、刪除、修改以及查詢操作。這些步驟應該與Z39.50協議取數據或插入數據的步驟是一致的。
因此,不管數字圖書館采用的是ORACLE,或是MARC文件,還是SQLSERVER,只要將數字資源轉化為DC元數據描述的對象,并且都實現了2.2中定義接口的核心方法,即可以通過Web Service發布,實現共享。
不同的Web服務器對于Web Service采用的方法是不同的。比如對于基于.NET架構的IIS來說,其不需要進行任何配置,只要用戶在開發中指定其是Web Service即可。而對于基于Java架構的Web Server來說,支持Web Service需要一些第三方庫。以Tomcat為例,通常將Axis作為Tomcat支持Web Service的第三方庫,只要修改一些配置文件即可。
檢查一個Web Service是否發布成功,可以直接使用瀏覽器輸入其WSDL,如果Web服務器可以返回該接口的WSDL,則表明發布成功。
一般來說,只要客戶端能夠獲取某個Web Service的WSDL文件,一些高級編程工具,比如VC.NET、JBuilder + Axis,即可以自動生成調用Web Service的客戶端代碼。因為接口定義的標準化,其調用相當簡單且標準化。
對于調用的流程來說,客戶端可以先利用查詢的Web Service確認某編目中心是否有自己需要的數字資源,若返回的元數據數組個數大于0,則將數組轉換為自己數據庫的格式,再插入數據庫即可。
3種數字資源共享模型之間的比較如表1所示。

表1 幾種共享模式的比較
本文提出了一種以XML作為傳輸單元,以DC元數據的數據抽象作為接口之間的介質,以Web Service作為系統架構的一種數字圖書館資源共建共享系統。這種系統的好處就是只要實現了本文提出的WSDigitalLibInf的4種方法,并將這4種方法以Web Service的方式進行Web發布,則可以在Internet上以SOPA/HTTP協議進行訪問,只要有一個Web Service的client端即可實現資源的共建共享。該基于Web Service的共建共享系統實現簡單,是Web 2.0的典型應用。但是,如何對這些接口進行權限限制也是亟待解決的問題。今后的研究方向是采用SOA架構,結合區塊鏈技術建立一個分布式的去中心化數據庫[7],并采取訂閱-發布式將數字資源以異步方式進行共享。