王躍虎　李松輝　穆祥昆

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

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

DOI：10.3969/j.issn.1008-0821.2015.09.015

〔中圖分類號〕G2507 〔文獻(xiàn)標(biāo)識碼〕A 〔文章編號〕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)逐步升級到Symphony集成圖書管理系統(tǒng)，同時使用該系統(tǒng)提供的新的OPAC服務(wù)。然而，從采用Unicorn系統(tǒng)開始，由于系統(tǒng)自身以及部署等多方面的原因，該系統(tǒng)在使用上存在諸多不便和難以滿足各館實際需要的情況，尤其在與其它信息系統(tǒng)的對接和集成，以及系統(tǒng)二次開發(fā)上，則顯得更加復(fù)雜和困難[6-7]。升級到Symphony系統(tǒng)后，這些問題在實際運行中依然存在。當(dāng)前，云計算趨勢已逐步形成，無線網(wǎng)絡(luò)也已經(jīng)普及，以智能手機為代表的移動終端迅速成為主流，移動圖書館和圖書館中移動應(yīng)用呈爆發(fā)式增長，如移動網(wǎng)站、微博，微信及其它相關(guān)移動APP等[8-12]。從而，使得Symphony系統(tǒng)在移動應(yīng)用方面的劣勢越發(fā)明顯，制約了圖書館對自身傳統(tǒng)業(yè)務(wù)的革新。本文通過編程實現(xiàn)一個Web代理服務(wù)，對Symphony系統(tǒng)的OPAC服務(wù)進(jìn)行包裝，對原有系統(tǒng)進(jìn)行適當(dāng)擴展，使之能夠更好地為圖書館移動網(wǎng)站，以及其它移動應(yīng)用和新業(yè)務(wù)提供支撐，從而提升圖書館的總體服務(wù)水平。

1 OPAC系統(tǒng)分析

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

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

對于實體圖書館的流通業(yè)務(wù)，由于牽扯到紙本圖書這一物理實體上的操作，因此，在沒有線下相關(guān)輔助業(yè)務(wù)支撐的條件下，借還業(yè)務(wù)還不適合通過移動終端在圖書館之外來實現(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ù)借圖書、編輯個人相關(guān)信息等，但是，由于沒有專門針對移動終端進(jìn)行網(wǎng)頁設(shè)計，其在移動終端上的讀者體驗欠佳，同時，對移動APP的支持也不理想，不能對移動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)鍵詞檢索館藏時，瀏覽器中相關(guān)Web頁面與OPAC服務(wù)器之間交互過程的細(xì)節(jié)如圖2所示。

顯然，完整的交互由3個獨立過程組成，而交互過程的特別之處在于，每次刷新頁面或者頁面向OPAC服務(wù)器GET/POST請求之后，OPAC服務(wù)器返回的結(jié)果頁面中，用于提交后續(xù)POST請求的URL地址總是變化的，該地址中包含了新的隨機生成的Token字符串。這種機制利于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)擴展設(shè)計

21 基本思路

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

22 系統(tǒng)集成

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

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

23 代理的實現(xiàn)

從技術(shù)的角度考慮代理服務(wù)器的實現(xiàn)，其中，向OPAC服務(wù)器發(fā)送模擬HTTP請求，可以利用HttpWebRequest對象，或者利用HttpClient對象等實現(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包等。

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

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

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

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

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

31 客戶端的原理

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

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，對于移動APP客戶端、桌面客戶端等，則可以采用其它應(yīng)用環(huán)境下的相應(yīng)的UI界面技術(shù)。

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

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

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

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

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

4 結(jié) 語

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

參考文獻(xiàn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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