王躍虎　李松輝　穆祥昆

〔摘 要〕本文利用一個(gè)Web代理服務(wù)器，對Symphony的基于Web的OPAC系統(tǒng)進(jìn)行了擴(kuò)展設(shè)計(jì)，以彌補(bǔ)原OPAC系統(tǒng)的不足，并在現(xiàn)有門戶網(wǎng)站基礎(chǔ)上，給出了該擴(kuò)展系統(tǒng)的一種實(shí)現(xiàn)。測試表明，該擴(kuò)展設(shè)計(jì)是可行的，擴(kuò)展系統(tǒng)能夠滿足讀者通過移動(dòng)終端檢索圖書、續(xù)借圖書等的需求。

〔關(guān)鍵詞〕代理服務(wù)；OPAC；圖書館；XML；Web接口

DOI：10.3969/j.issn.1008-0821.2015.09.015

〔中圖分類號(hào)〕G2507 〔文獻(xiàn)標(biāo)識(shí)碼〕A 〔文章編號(hào)〕1008-0821（2015）09-0079-05

〔Abstract〕In this paper，an expanded system based on the Web OPAC system which provided by the Symphony ILS was designed by using a Web proxy server to remedy the disadvantages of the original Web OPAC system，and then the expanded system is developed with the help of an existing portal website.The practical tests showed that the design is feasible，and the developed system can meet the readers needs of book retrieval，book renew，etc.on the mobile terminal.

〔Key words〕proxy service；OPAC；library；XML；Web API

SirsiDynix公司的Unicorn、Symphony系統(tǒng)是兩款較為成熟的圖書館集成管理系統(tǒng)[1-3]。從2002年起，天津多家高校圖書館統(tǒng)一采購并使用了Unicorn圖書館集成管理系統(tǒng)[4-5]。經(jīng)過多年使用，各館館員熟練掌握了該系統(tǒng)上的業(yè)務(wù)操作，系統(tǒng)中也積累了大量的寶貴的采編數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)和讀者數(shù)據(jù)。自2012年起，各圖書館從Unicorn系統(tǒng)逐步升級(jí)到Symphony集成圖書管理系統(tǒng)，同時(shí)使用該系統(tǒng)提供的新的OPAC服務(wù)。然而，從采用Unicorn系統(tǒng)開始，由于系統(tǒng)自身以及部署等多方面的原因，該系統(tǒng)在使用上存在諸多不便和難以滿足各館實(shí)際需要的情況，尤其在與其它信息系統(tǒng)的對接和集成，以及系統(tǒng)二次開發(fā)上，則顯得更加復(fù)雜和困難[6-7]。升級(jí)到Symphony系統(tǒng)后，這些問題在實(shí)際運(yùn)行中依然存在。當(dāng)前，云計(jì)算趨勢已逐步形成，無線網(wǎng)絡(luò)也已經(jīng)普及，以智能手機(jī)為代表的移動(dòng)終端迅速成為主流，移動(dòng)圖書館和圖書館中移動(dòng)應(yīng)用呈爆發(fā)式增長，如移動(dòng)網(wǎng)站、微博，微信及其它相關(guān)移動(dòng)APP等[8-12]。從而，使得Symphony系統(tǒng)在移動(dòng)應(yīng)用方面的劣勢越發(fā)明顯，制約了圖書館對自身傳統(tǒng)業(yè)務(wù)的革新。本文通過編程實(shí)現(xiàn)一個(gè)Web代理服務(wù)，對Symphony系統(tǒng)的OPAC服務(wù)進(jìn)行包裝，對原有系統(tǒng)進(jìn)行適當(dāng)擴(kuò)展，使之能夠更好地為圖書館移動(dòng)網(wǎng)站，以及其它移動(dòng)應(yīng)用和新業(yè)務(wù)提供支撐，從而提升圖書館的總體服務(wù)水平。

1 OPAC系統(tǒng)分析

SirsiDynix公司的Unicorn系統(tǒng)是典型的C/S架構(gòu)，而升級(jí)后的Symphony系統(tǒng)是基于Unicorn系統(tǒng)的，因而其仍然延續(xù)了C/S結(jié)構(gòu)。（如圖1所示）

在互聯(lián)網(wǎng)環(huán)境下，由于網(wǎng)絡(luò)狀況難以控制，部署、運(yùn)行和維護(hù)Symphony這樣的C/S結(jié)構(gòu)的系統(tǒng)存在較大困難，而在內(nèi)聯(lián)網(wǎng)環(huán)境中，由于種種原因，這樣的系統(tǒng)在系統(tǒng)擴(kuò)展以及與其它信息系統(tǒng)集成上，則表現(xiàn)出太過封閉，接口復(fù)雜，開放性和靈活性稍顯不足。因而，容易在圖書館館內(nèi)信息化過程中形成信息孤島，同時(shí)造成圖書館集成管理系統(tǒng)遷移、轉(zhuǎn)換困難，往往使圖書館綁定在特定公司的特定產(chǎn)品上[13]。

對于實(shí)體圖書館的流通業(yè)務(wù)，由于牽扯到紙本圖書這一物理實(shí)體上的操作，因此，在沒有線下相關(guān)輔助業(yè)務(wù)支撐的條件下，借還業(yè)務(wù)還不適合通過移動(dòng)終端在圖書館之外來實(shí)現(xiàn)。目前，能完全通過網(wǎng)上辦理的業(yè)務(wù)，主要還是檢索、續(xù)借和讀者信息管理等，而這些業(yè)務(wù)，通過Symphony系統(tǒng)中的OPAC服務(wù)器就能夠?qū)崿F(xiàn)。Symphony系統(tǒng)提供了基于Web的OPAC服務(wù)，支持桌面瀏覽器通過Web頁面檢索圖書、續(xù)借圖書、編輯個(gè)人相關(guān)信息等，但是，由于沒有專門針對移動(dòng)終端進(jìn)行網(wǎng)頁設(shè)計(jì)，其在移動(dòng)終端上的讀者體驗(yàn)欠佳，同時(shí)，對移動(dòng)APP的支持也不理想，不能對移動(dòng)APP和其它應(yīng)用提供有效支持，難以直接集成到其它應(yīng)用系統(tǒng)中。

借助fiddler2等Web調(diào)試工具，對瀏覽器與Symphony系統(tǒng)中的OPAC服務(wù)器之間的HTTP通訊數(shù)據(jù)和交互過程進(jìn)行分析，則可以發(fā)現(xiàn)，通過關(guān)鍵詞檢索館藏時(shí)，瀏覽器中相關(guān)Web頁面與OPAC服務(wù)器之間交互過程的細(xì)節(jié)如圖2所示。

顯然，完整的交互由3個(gè)獨(dú)立過程組成，而交互過程的特別之處在于，每次刷新頁面或者頁面向OPAC服務(wù)器GET/POST請求之后，OPAC服務(wù)器返回的結(jié)果頁面中，用于提交后續(xù)POST請求的URL地址總是變化的，該地址中包含了新的隨機(jī)生成的Token字符串。這種機(jī)制利于OPAC系統(tǒng)的安全和穩(wěn)定，但是對于通過OPAC服務(wù)器來獲取所需的數(shù)據(jù)造成一定困難，必須從返回的頁面代碼中提取并保存新的處理URL地址，以便隨后使用。另外，對于檢索結(jié)果頁面上的翻頁操作或者查看圖書詳情操作，二者之間的差異僅在于向OPAC服務(wù)器上的相同處理URL地址提交的POST數(shù)據(jù)有所不同。

其它頁面，如圖書續(xù)借頁面、讀者信息管理頁面等，在與OPAC服務(wù)器的交互過程中，處理后續(xù)請求的URL地址也總是變化的，與圖書檢索頁面的情況類似。endprint

2 OPAC系統(tǒng)擴(kuò)展設(shè)計(jì)

21 基本思路

在不能改變原有Symphony系統(tǒng)結(jié)構(gòu)以及OPAC服務(wù)器的條件下，從OPAC服務(wù)器獲取所需數(shù)據(jù)來實(shí)現(xiàn)新服務(wù)，需要在原OPAC服務(wù)與新服務(wù)之間添加一個(gè)轉(zhuǎn)換層。比如，實(shí)現(xiàn)一個(gè)簡單的Web代理服務(wù)器：通過模擬HTTP請求來向OPAC服務(wù)器轉(zhuǎn)發(fā)請求，得到返回的頁面代碼，對該頁面代碼進(jìn)行解析，從其中提取所需的數(shù)據(jù)，并以一定的格式構(gòu)造格式化的字符串作為請求結(jié)果，返回給發(fā)出請求的一方。其中，檢索服務(wù)代理的原理如圖3所示：

22 系統(tǒng)集成

通過對原有OPAC服務(wù)包裝和擴(kuò)展形成的Web代理服務(wù)器，與其它系統(tǒng)集成時(shí)，可有兩種典型的應(yīng)用模式：一種是作為Web服務(wù)器的數(shù)據(jù)來源，作用類似于數(shù)據(jù)庫；另一種則是作為Web服務(wù)，通過Web應(yīng)用接口直接向客戶端提供數(shù)據(jù)。兩種應(yīng)用模式，分別如圖4、圖5所示：

在應(yīng)用模式一中，Web服務(wù)器實(shí)際上作為客戶端，利用服務(wù)端代碼訪問代理服務(wù)器，而在應(yīng)用模式二中，瀏覽器作為客戶端，需要用客戶端代碼訪問代理服務(wù)器，因而涉及客戶端代碼跨域請求和提交問題，受瀏覽器同源策略限制，需采用諸如JSONP等跨域技術(shù)和方法[14]。具體選擇哪一種應(yīng)用模式，應(yīng)根據(jù)實(shí)際需要綜合考慮。

23 代理的實(shí)現(xiàn)

從技術(shù)的角度考慮代理服務(wù)器的實(shí)現(xiàn)，其中，向OPAC服務(wù)器發(fā)送模擬HTTP請求，可以利用HttpWebRequest對象，或者利用HttpClient對象等實(shí)現(xiàn)。接收從OPAC服務(wù)器返回的HTML頁面代碼，可以利用HttpWebResponse對象，從頁面代碼中提取后續(xù)處理URL，則可以利用HtmlAgilityPack、HtmlParser等HTML文本解析器，或者利用正則表達(dá)式進(jìn)行解析，或者通過特征字符串定位所需內(nèi)容的位置，直接截取檢索結(jié)果字符串[15]。返回給發(fā)出請求一方的數(shù)據(jù)，可以采用XML字符串，或者JSON格式字符串。對XML、JSON字符串的讀寫處理，均有很多成熟的組件、包或者開源代碼可供選擇，比如DataSet組件、XMLDOM組件、JDOM包等。

從實(shí)現(xiàn)形式角度考慮，這樣的Web代理服務(wù)器在實(shí)現(xiàn)形式上非常靈活，既能夠以單獨(dú)的服務(wù)器形式實(shí)現(xiàn)，如利用WCF技術(shù)、Web Services技術(shù)、Restful Web API技術(shù)等實(shí)現(xiàn)Web代理服務(wù)功能，也能夠以已有網(wǎng)站的功能擴(kuò)展形式實(shí)現(xiàn)，如利用HttpHandler、Servlet等技術(shù)來實(shí)現(xiàn)[16-17]。考慮到Web代理服務(wù)器的穩(wěn)定性、安全性、負(fù)載和效率等問題，應(yīng)優(yōu)先采用諸如IIS、tomcat等成熟的軟件作為Web代理服務(wù)器，僅編程實(shí)現(xiàn)相應(yīng)的代理服務(wù)功能模塊，而不是編程實(shí)現(xiàn)一個(gè)完整的專用的Web代理服務(wù)器。

依據(jù)本館實(shí)際情況，Web代理服務(wù)器的實(shí)現(xiàn)形式，選擇IIS作為代理服務(wù)器，并選擇在已有門戶網(wǎng)站基礎(chǔ)上，添加實(shí)現(xiàn)相應(yīng)代理功能的HttpHandler一般處理程序進(jìn)行功能擴(kuò)展這種形式。在以IIS為基礎(chǔ)的門戶網(wǎng)站中，借助ASPNET技術(shù)，添加相應(yīng)的ashx文件，建立相應(yīng)的代理功能模塊，來簡單實(shí)現(xiàn)上述Web代理服務(wù)器的代理服務(wù)功能，并以URL形式對外公開相應(yīng)的應(yīng)用接口，供其它應(yīng)用訪問。其中，檢索代理模塊的實(shí)現(xiàn)如圖6所示：

其中，OPACSearchProxy組件由OPACSearchProxy.ashx文件實(shí)現(xiàn)，在該組件的HttpHandler處理過程ProcessRequest中，利用包裝了HttpWebRequest、HttpWebResponse等對象的HttpRequestWarp組件，分別實(shí)現(xiàn)向OPAC服務(wù)器模擬發(fā)送HTTP請求和接收響應(yīng)，同時(shí)利用項(xiàng)目中開發(fā)的MyHTMLParser組件來解析HTML頁面代碼，并從中提取檢索結(jié)果中的圖書信息。

考慮到提取檢索結(jié)果的速度需要盡可能地快，MyHTMLParser組件直接使用字符串處理函數(shù)，通過匹配特征字符串來在HTML代碼中定位并截取檢索結(jié)果。匹配過程中用到的特征字符串，則使用AppConfigRW組件從網(wǎng)站的配置文件中讀取，以便在OPAC服務(wù)器上的檢索頁面發(fā)生變化時(shí)，只需要通過修改配置文件，就能保證檢索代理服務(wù)總能截取到所需的檢索結(jié)果。截取到的檢索結(jié)果，臨時(shí)存放在DataSet對象中，并將該數(shù)據(jù)集中的數(shù)據(jù)，轉(zhuǎn)換為XML字符串。

3 相應(yīng)的客戶端

31 客戶端的原理

與上述Web代理服務(wù)器相配的客戶端，需要實(shí)現(xiàn)三項(xiàng)基本功能：向Web代理服務(wù)器發(fā)送HTTP請求；接收并解析Web代理服務(wù)器返回的格式化字符串；對解析出來的數(shù)據(jù)進(jìn)行處理并呈現(xiàn)。處理和呈現(xiàn)解析出來的數(shù)據(jù)，是客戶端最主要的功能，而這取決于用戶的具體需求。客戶端的原理如圖7所示：

APP客戶端，也可以是PC桌面客戶端和其它客戶端。

從技術(shù)角度來看，向Web代理服務(wù)器發(fā)送HTTP請求，可由Web客戶端，比如瀏覽器，使用Ajax技術(shù)中的XMLHttpRequest對象，或者其它客戶端使用HttpWebRequest對象、HttpClient對象等完成。接收返回的格式化字符串，相應(yīng)地可采用Ajax技術(shù)中的XMLHttpRequest對象，或者在其它客戶端中采用HttpWebResponse對象等，而在客戶端解析返回的XML或者JSON字符串，可利用的組件、包以及開源代碼更多，如DataSet組件、XMLDOM組件、JDOM包、fastJSON包、json2.js等。使用和呈現(xiàn)解析出來的數(shù)據(jù)，在瀏覽器中可以采用CSS結(jié)合HTML，對于移動(dòng)APP客戶端、桌面客戶端等，則可以采用其它應(yīng)用環(huán)境下的相應(yīng)的UI界面技術(shù)。

由于要利用Web代理服務(wù)功能為本館的移動(dòng)網(wǎng)站提供服務(wù)，同時(shí)為避免跨域訪問帶來的不便，因此，這里選擇圖4所示的代理服務(wù)器應(yīng)用模式，利用移動(dòng)網(wǎng)站服務(wù)器端向上述Web代理服務(wù)器發(fā)送HTTP請求，對返回的XML格式字符串，利用DataSet組件加載并解析為查詢結(jié)果數(shù)據(jù)集。endprint

然后，使用該數(shù)據(jù)集生成相應(yīng)的Web頁面，返回給移動(dòng)終端上的瀏覽器呈現(xiàn)。

移動(dòng)網(wǎng)站中圖書檢索功能的實(shí)際效果如圖8、圖9所示：

該網(wǎng)站中的這些頁面，更符合移動(dòng)終端的呈現(xiàn)特點(diǎn)和用戶操作習(xí)慣，單次檢索所用時(shí)長，較不使用檢索代理時(shí)增加約3秒，大約為5～7秒，網(wǎng)頁響應(yīng)速度也較快，因而讀者體驗(yàn)較好。

圖書續(xù)借、讀者信息管理等代理功能的實(shí)現(xiàn)與上述圖書檢索代理功能的實(shí)現(xiàn)類似，由于涉及讀者賬戶登錄及登錄后的操作，因此需要額外利用CookieContainer對象等處理Cookie，以便進(jìn)行后續(xù)操作時(shí)能夠保持登錄狀態(tài)。

4 結(jié) 語

由于Web在互聯(lián)網(wǎng)上的重要地位，以及云計(jì)算的逐步成熟和移動(dòng)終端等的興起，新的趨勢下，基于Web的應(yīng)用程序接口越來越重要，比如Restful Web API等，其能夠?qū)?shù)據(jù)本身與數(shù)據(jù)的呈現(xiàn)完全分離，使得Web應(yīng)用能夠作為數(shù)據(jù)層向外提供數(shù)據(jù)，成為既能保持各系統(tǒng)相互獨(dú)立，又能為各系統(tǒng)提供互相訪問和集成的新的便捷途徑?；谶@一考慮，以上通過Web代理方式，利用Web接口和XML、JSON等通用的格式化字符串，完成了對Symphony系統(tǒng)中原有OPAC系統(tǒng)的擴(kuò)展設(shè)計(jì)，實(shí)現(xiàn)了對原OPAC服務(wù)功能的包裝、轉(zhuǎn)換，使其可以方便地為其它應(yīng)用系統(tǒng)所使用和集成，較好地解決了Symphony系統(tǒng)中OPAC服務(wù)所存在的實(shí)際問題，也簡化了其它相關(guān)應(yīng)用系統(tǒng)的開發(fā)過程，降低了開發(fā)難度，避免了重復(fù)開發(fā)OPAC接口模塊所帶來的，不必要的人力、物力浪費(fèi)。針對Symphony的OPAC系統(tǒng)的擴(kuò)展設(shè)計(jì)是可行的，盡管新增的Web代理服務(wù)層，會(huì)在一定程度上延遲系統(tǒng)整體的響應(yīng)時(shí)間。測試表明，整個(gè)系統(tǒng)實(shí)際運(yùn)行效果良好，Web代理服務(wù)器能滿足本館移動(dòng)網(wǎng)站和其它移動(dòng)應(yīng)用開發(fā)對Symphony系統(tǒng)的部分需要，一定程度上提升了圖書館的服務(wù)水平，同時(shí)也為未來將圖書館其它業(yè)務(wù)擴(kuò)展到無線網(wǎng)絡(luò)和移動(dòng)終端積累了經(jīng)驗(yàn)。

參考文獻(xiàn)

[1]薛崧，徐建剛.三大圖書館集成管理系統(tǒng)考察與比較[J].圖書館雜志，2008，27（10）：54-62.

[2]鄭偉，徐寶祥，高琦.“211”大學(xué)圖書館管理系統(tǒng)研究——基于“211”大學(xué)圖書館管理系統(tǒng)的調(diào)查[J].圖書情報(bào)知識(shí)，2010，（3）：4-10.

[3]王小林，李文躍，黃建輝.國內(nèi)省級(jí)公共圖書館自動(dòng)化系統(tǒng)評(píng)析[J].數(shù)字與縮微影像，2014，（1）：16-19.

[4]李秋實(shí)，楊曉華.基于Unicorn系統(tǒng)的圖書館采編業(yè)務(wù)集成管理[J].圖書館工作與研究，2008，（2）：24-33.

[5]于曦.基于Unicorn的校內(nèi)圖書文獻(xiàn)信息資源整合及自動(dòng)化管理[J].現(xiàn)代情報(bào)，2010，30（8）：49-51.

[6]王鍵.UNICORN SIRSI系統(tǒng)與外掛程序結(jié)合解決的幾個(gè)問題[J].圖書館學(xué)研究：應(yīng)用版，2011，（10）：31-33.

[7]付凱麗.天津市高校聯(lián)合書目數(shù)據(jù)庫數(shù)據(jù)質(zhì)量控制研究[J].現(xiàn)代情報(bào)，2013，33（5）：138-142.

[8]劉紅麗.國內(nèi)移動(dòng)圖書館研究現(xiàn)狀與趨勢[J].國家圖書館學(xué)刊，2012，（3）：92-98.

[9]宋恩梅，袁琳.移動(dòng)的書海：國內(nèi)移動(dòng)圖書館現(xiàn)狀及發(fā)展趨勢[J].中國圖書館學(xué)報(bào)，2013，36（189）：34-47.

[10]梁欣，過仕明.我國移動(dòng)圖書館服務(wù)模式現(xiàn)狀與發(fā)展趨勢[J].情報(bào)資料工作，2013，（5）：98-102.

[11]郭利敏，張磊，趙亮.圖書館微信服務(wù)應(yīng)用開發(fā)——以上海圖書館為例[J].現(xiàn)代圖書情報(bào)計(jì)算，2014，（5）：96-101.

[12]唐瓊，袁媛，劉釗.我國高校圖書館微博服務(wù)現(xiàn)狀調(diào)查研究——以新浪認(rèn)證用戶為例[J].大學(xué)圖書館學(xué)報(bào)，2013，（3）：97-103.

[13]高丹陽，岳延貞，張金梁，等.我國圖書館如何避免被集成系統(tǒng)開發(fā)商鎖定[J].情報(bào)雜志，2009，28（3）：199-203.

[14]李張永，陳和平，顧進(jìn)廣.跨平臺(tái)移動(dòng)Web開發(fā)框架與數(shù)據(jù)交互方法[J].計(jì)算機(jī)工程與設(shè)計(jì)，2014，35（5）：1827-1832.

[15]李善杰.二維碼技術(shù)在圖書館查詢機(jī)中的應(yīng)用與實(shí)現(xiàn)[J].現(xiàn)代圖書情報(bào)技術(shù)，2014，（1）：97-101.

[16]林偉明，曾新紅.Onto Thesaurus Web Service API及其應(yīng)用研究[J].圖書情報(bào)工作，54（2）：119-122.

[17]韓立峰.基于ASPNET Web API框架的校園一卡通手機(jī)客戶端研究[J].計(jì)算機(jī)與現(xiàn)代化，2014，（9）：128-136.

（本文責(zé)任編輯：孫國雷）endprint