基于代理服務的OPAC系統擴展設計及實現

王躍虎　李松輝　穆祥昆

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

〔關鍵詞〕代理服務；OPAC；圖書館；XML；Web接口

DOI：10.3969/j.issn.1008-0821.2015.09.015

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

1 OPAC系統分析

SirsiDynix公司的Unicorn系統是典型的C/S架構，而升級后的Symphony系統是基于Unicorn系統的，因而其仍然延續了C/S結構。（如圖1所示）

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

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

借助fiddler2等Web調試工具，對瀏覽器與Symphony系統中的OPAC服務器之間的HTTP通訊數據和交互過程進行分析，則可以發現，通過關鍵詞檢索館藏時，瀏覽器中相關Web頁面與OPAC服務器之間交互過程的細節如圖2所示。

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

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

2 OPAC系統擴展設計

21 基本思路

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

22 系統集成

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

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

23 代理的實現

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

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

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

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

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

3 相應的客戶端

31 客戶端的原理

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

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

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

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

然后，使用該數據集生成相應的Web頁面，返回給移動終端上的瀏覽器呈現。

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

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

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

4 結 語

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

參考文獻

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

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

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

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

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

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

[7]付凱麗.天津市高校聯合書目數據庫數據質量控制研究[J].現代情報，2013，33（5）：138-142.

[8]劉紅麗.國內移動圖書館研究現狀與趨勢[J].國家圖書館學刊，2012，（3）：92-98.

[9]宋恩梅，袁琳.移動的書海：國內移動圖書館現狀及發展趨勢[J].中國圖書館學報，2013，36（189）：34-47.

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

[11]郭利敏，張磊，趙亮.圖書館微信服務應用開發——以上海圖書館為例[J].現代圖書情報計算，2014，（5）：96-101.

[12]唐瓊，袁媛，劉釗.我國高校圖書館微博服務現狀調查研究——以新浪認證用戶為例[J].大學圖書館學報，2013，（3）：97-103.

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

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

[15]李善杰.二維碼技術在圖書館查詢機中的應用與實現[J].現代圖書情報技術，2014，（1）：97-101.

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

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

（本文責任編輯：孫國雷）endprint