基于代理服务的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