实体图书馆数字资源Web关联集成模式研究与实践

[摘要]基于中国实体图书馆的数字资源种类和资源集成实践，从不同角度分析各种数字资源Web关联集成模式：紧耦舍与松耦合、静态与动态、同步通讯与异步通讯、直接与间接、浏览器与服务器、检索链接与访问链接模式，探讨各模式的特点和对不同预期集成效果的适用性。并根据异步通讯资源集威模式的实践进行具体阐述。

[关键词]数字资源Web集成模式异步通讯

[分类号]G250.76

1 引 言

实体图书馆的可用数字资源快速增加，多数通过Web界面使用，给用户提供一种方便的使用环境成为图书馆的迫切任务。由此，数字资源的整合与集成…逐渐成为一种发展的趋势和业界研究与实践的热点，其中，数字资源的整合检索和关联集成是两个比较主要的方面：整合检索要解决的问题是通过统一的界面从众多的数字资源系统中获取相关的资源，已经比较成熟；关联集成要解决的问题是揭示内容相关的分布式存在的数字资源之间的内在联系，在应用系统中由一个资源对象通过关联条件与其它的资源对象建立相关关系，将相关联的资源尽可能地集中展示给用户。关联集成的效果取决于关联条件、接口类型、技术架构、响应速度、表达形式等多方面的因素，集成方案设计时需要根据预期集成效果和可用的条件选择最合适的模式。本文试从数字资源Web关联集成实现中普遍涉及的侧面对集成的模式进行研究，对具有良好应用前景的异步通讯资源集成进行具体讨论。

2　数字资源Web关联集成模式分析

数字资源Web关联集成主要从三种途径实现：①在页面中直接嵌入目标资源的内容，如：书封；②在页面上提供一个到目标资源的访问链接，如：电子全文链接；③在页面上提供一个到目标资源的检索链接，如：查找一个特定ISBN随书光盘的链接。无论何种途径，都存在一些共性的侧面，形成了不同适用性的集成模式。本文将关联集成结构中发出关联请求的资源称为源资源，将被请求的资源称为目标资源。

2.1 紧耦合模式和松耦合模式

从关联程度划分，紧耦合模式在源资源和目标资源之间有明确的绑定关系，通过加工生成的资源标识或内部ID等作为关联条件。例如：通过索书号关联处于两个不同的资源系统中的图书和随书光盘。它的优势在于有排它性的、稳定的匹配关系，其覆盖范围是所有经过这种加工的资源。它的缺点是不通用，只适用于图书馆内部或特定的采用相同标识做区分的联合体中，并且有维护各种标识体系的麻烦。

松耦合模式则通过资源本身的特征属性进行关联，源资源和目标资源之间没有事先设计的匹配关系。如：通过ISBN／ISSN号关联OPAC的书刊记录和他们的电子版全文。此模式可以跨系统、跨地域、跨国界地使用，有广泛的集成范围，但有产生误匹配的可能。如：多刊共用一个ISSN号的情况下匹配就有一定的错误几率。通过书名的关联其匹配正确率更低。实际应用中需要根据具体情况确定一个相对合适的匹配方案，如：首选ISBN号匹配，无ISBN号时自动使用“书名+著者”匹配。

2.2　静态模式和动态模式

从关联建立过程划分，静态模式将到目标资源的访问链接预先写在源资源中，典型的例子是将书目对应的电子全文的链接直接写在MARC书目记录的856字段中。也有实践是将相应的数字资源信息写在专用表中，如：Melinets书目系统提供了与其他电子资源链接的接口表manager，oth_guangcang，将相对应的电子图书的URL链接写入这个接口表中就可以在Melinets系统的OPAC检索界面上看到“其他电子资源数据”下对应的电子全文链接了。静态模式的优点是匹配相对准确，是对确定存在资源的关联，在正常情况下一定有目标资源存在，缺点是需要根据目标资源的地址变动不断地更新数据，维护成本较高，也难以保持数据的完全实时。

动态模式是通过提交含有关联条件的资源请求临时建立源资源和目标资源之间的关联，其优点是没有附加的数据维护成本，可以快速地建立起资源之间的关联连接，支持更灵活的表达形式、更丰富的信息格式，是目前占主导地位的集成模式。但它在速度上有延迟的可能，也会多消耗一定的计算能力和网络流量，并且需要一定的系统开放接口。不同类型的开放接口对资源集成的难度和效果都有很大影响。

基于数据库的开放接口提供了通过ODBC、JDBC等直接连接数据库进行匹配操作的途径，其优势是使用者有比较多的主动权，可以灵活地得到多种个性化输出结果。但这要求开发人员对目标资源的数据库结构有清楚的了解，同时需要制作比较复杂的SQL语句，并考虑速度等多方面的优化问题。而且，当数据库结构改变时，相应的应用程序会受到影响，需要随之变动。

基于标准工业协议的开放接口屏蔽了目标资源系统的数据库结构和技术细节，应用相对安全，如：Z39，50、OpenURL、SOAP等。他们也比较成熟，在资源系统升级换代时相对稳定。但要求源资源和相关系统都支持同样的协议，经过适当的配置。

基于Web API的开放接口近几年发展特别迅速，他们直接通过http协议实现，降低了异构系统互连的门槛，使用简单，也为将资源系统的技术实现与应用系统的构建分离开来提供了一个便捷的途径。但它也有比较明显的缺点：目前尚缺少统一的标准，信息处理难度差异大，要针对多种应答形式开发不同的解析程序。Web API的常见应答形式是：JSON、XML、文本和HT―ML。一般情况下，前三种是作为开放接口专门开发的，应答信息的长度短、结构性强、传递快；HTML API一般来自网页调用，信息结构性差，传递时要获取整个网页，信息提取也比较困难。

2.3 同步通讯模式和异步通讯模式

从通讯方式划分，同步通讯模式时，浏览器的Web页面内容采取整体处理的方式，即：无论是文字还是图片，无论来自本地还是远程，页面的显示过程要等全部内容都有响应后才结束，才允许用户进行下面的操作。因此，当某些应答反应缓慢时，用户就有等待感。

异步模式允许web页面的内容分步显示，页面中的同步部分传输完毕后就把操作权力交给了用户，异步部分的应答到达后可以局部刷新页面，等待异步请求应答期间不影响用户的其他操作。由于异步通讯改善了用户体验，人们甚至用它逼近GUI的效果。目前异步通讯主要由AJAX(Asynchronous JavaSeript AndXML)和AJAJ(Asynchronous JavaSeript and JSON)两种架构实现。由于XML、JSON格式的应答能够传输复杂的含有语义和结构的信息，并且有机会将这些信息用程序处理后使用，所以异步通讯模式下还可以实现复杂的资源集成功能。

2.4　直接模式和间接模式

从关联路径划分，直接模式是源资源直接与目标

资源发生关联。其优势是保持了各系统原有的使用独立性，数据实时，没有额外的存储开销，但与动态模式结合使用时需要目标资源系统有一定的开放接口。

间接模式下则存在一个中间数据源作为中间转换点(或称中间库)，源资源与中间转换点发生关联，中间转换点含有目标资源的访问地址，源资源从中间转换点获取目标资源的访问地址，继而与目标资源确定访问关系。中间转换点可能是通过OAI―PMH收割的信息，也可能是以批导人方式集中的元数据等，如：重庆大学图书馆构建的电子图书平台。间接模式有两个主要的作用：一是可以解决部分资源系统没有合适的开放接口，不能直接集成的问题；二是可以减少一定的网络连接数量，源资源的一个指向中间转换点的请求可以实现对多个目标资源的关联。间接模式的缺点是，需要不断维护和更新中间转换点的数据，也不能实时反映目标资源的可访问性。

2.5 浏览器模式和服务器模式

从关联请求发起点划分，浏览器模式是从浏览器发出请求到目标资源或中间转换点。其优点是不占用服务器的资源，中间环节少。但是，有一些客观上的限制需要考虑：①与异步通讯模式结合使用时，AJAX不能跨域使用，不能用AJAX在浏览器端直接集成远程资源。如果目标资源有JSON API，可以使用无跨域限制的AJAJ架构。②目标资源有IP地址限制时，要求浏览器端的IP地址必须在许可范围之内。

服务器模式下浏览器将请求发到本地服务器，由服务器再发出到目标资源或中间转换点的请求，服务器负责反馈应答信息至浏览器。这种模式下的所有流量都经过服务器，对服务器的性能要求较高。但是它可以解决浏览器模式不能解决的一些问题。如：异步通讯模式下使用AJAX集成远程资源。另外，在目标资源有IP地址访问限制时，可选择不同的揭示方案，对于互联网上的公开资源，可取浏览器模式，而图书馆购买的资源使用服务器模式，这样可以不受浏览器端的IP地址限制去显示图书馆的资源信息，而实际访问由IP地址控制。

2.6　检索链接模式与访问链接模式

从链接性质划分，检索链接模式提供含有关联条件(如：ISBN号)的到目标资源的检索表达，用户点击后可以得到在目标资源库的检索结果。这种链接在技术上实现简单，缺点是有无命中记录事先不确定，用户每次都要搜搜看。

访问链接模式提供到确定性存在资源的使用链接，用户在界面上可以一目了然地知道存在哪些相关资源。如：在书目记录显示页面直接给出相应的电子图书、随书光盘等的使用链接。这种模式服务更主动，给用户提供了更大的方便。但动态模式下实现起来比较复杂，需要系统自动判断目标资源是否存在，然后根据实际情况给出链接。

3 　数字资源集成实践

针对数字资源集成的一些问题：如何在应用系统中无缝地融合与揭示，如何消除延迟响应造成的用户等待感，如何协调不同的接口与预期集成效果等，笔名进行了Web API(XML API、HTML API、JSON API)接口的异步通讯资源集成实践，获得了预期的集成效果。即：在现有资源系统的基础上，不借助第三方软件，主动揭示出一个资源项在其它资源系统中的相关资源，同时具有可设计的显示形式和良好的用户界面响应速度。本实践使用ALEPH 500的OPAC作为Web应用系统，几类具有代表性的资源如表1所示：

3.1　通过XML／HTML API进行异系统异步通讯资源集成

XML API和HTML API接口的异步通讯资源集成技术架构选用AJAX和MAH(Asynchronous JavaScriptAnd HTML)。两个关键点是：AJAX／AJAH不能跨域的问题和应答信息处理问题。前者的解决使用了CGI技术，将浏览器的异步请求转向本地服务器的CGI；后者使用XML DOM解析了XML应答信息，另使用正则匹配方法通过页面分析从无结构的HTML应答中提取信息。其AJAX／AJAH集成架构如图2所示：传递应达信息；⑤解析应答信息，提取目标资源访问地址，在Web页面上生成访问链接；⑥用户点击链接打开目标资源。

3.2　通过XML／HTML API进行同系统异步通讯资源集成

在同系统异步通讯资源集成中不涉及跨域问题。其AJAX／AJAH集成架构如图3所示：

异步通讯资源集成架构

注：①通过XMLHttpRequest向本地服务器发出请求；②返回 XML／HTML应答信息；③解析应答信息，并在Web页面上生 成链接；④用户点击链接打开目标资源。

3.3 通过JsON API进行异步通讯资源集成

JsoN应答信息可以通过HTML中script标签的src属性获取。其AllAJ集成架构见图4所示。

注：①通过scrpt标签的src属性使用JsON API访问目标资源席；②返同JSON格式应答信息给callback函数；③解析JSON信息，在Web页面上生成访问链接；④用户点击链接打开目标资源。

3.4　基于中间库的xML／HTML API接口异步通讯资源集成

源资源通过中间库获得相应的目标资源的访问地址。其AJAX／AJAH集成架构如图5所示：

注：①通过XMLHttpRequest向本地服务器发出请求；②使川XML／HTMLAPI访问中间库；③返回XMIVHTML应答信息；④传递应答信息；⑤解析应答信息，提取目标资源访问地址，并在Web页而面上生成链接；⑥用户点击链接打开目标资源。

4　结语

笔者认为，在理想状态下，资源与应用应该成为一对多的关系，一份资源可以被多个应用集成使用，即：多维使用。有关联的资源能够互相调用，形成一个网状结构。在+应用系统中，良好的资源集成效果要依靠不同的资源集成模式、不同的技术实施路线的合理与优化的搭配和设计。目前在如何提高集成的匹配率、如何使web API接口标准化和规范化等方面都存在需要深入探讨的问题。