网上实时参考咨询系统的设计与实现_实时系统论文

网上实时参考咨询系统的设计与实现,本文主要内容关键词为:实时论文,系统论文,网上论文,此文献不代表本站观点,内容供学术参考,文章仅供参考阅读下载。

1 引言

参考咨询是图书情报机构的一项重要工作,帮助解决读者使用文献时遇到的各类问题,深受读者欢迎。传统上,参考咨询有信函(含传真)咨询、面对面咨询(含电话)两种主要的方式。

随着网络的普及,读者希望能借助网络足不出户也能进行咨询。对于两种传统的咨询方式,网上参考咨询分别是非实时参考咨询和实时参考咨询。

笔者于2002年下半年为国家科技图书文献中心(NSTL,http://www.nstl.gov.cn)开发了专家咨询系统[1],即非实时参考咨询系统,并于当年投入使用,是国内较早的网上非实时参考咨询系统之一。近两年来,在总结非实时参考咨询工作相关经验与问题的基础上,我们又为NSTL开发了实时参考咨询系统,并于2004年9月投入使用。目前,NSTL的咨询专家通过互联网可为用户提供“实时参考咨询”服务和“非实时参考咨询”服务,并实现“实时”与“非实时”服务的互动,深受用户的欢迎。在NSTL开展“实时参考咨询”服务和“非实时参考咨询”服务的同时,国内一些高校图书馆也都开发了自己的实时咨询系统,但这些系统的一个共同点就是它们都建设在局域网上,供特定地理分布的人群使用。这些系统如果直接应用到互联网络上,由于带宽及传输不稳定等因素没有给予特殊的考虑,可能会遇到一定的问题。

另一方面,现在网上有很多的实时信息服务,如QQ,MSN等,借助这类聊天软件也可以实现实时交互,而且作为成熟的应用软件,这些工具功能齐全,也比较稳定,能够为对话双方提供各方面的便利。但是,这类软件并不适合在参考咨询中使用。首先,使用这类软件会使咨询服务的效果依赖于外部因素,使服务机构失去在服务信息和系统运行等方面的控制;其次,对咨询的内容和工作情况不能够进行有效的管理,以形成知识沉淀;第三,不利于咨询服务的持续发展,进一步提高服务水平。因此,从信息安全、系统稳定性、可管理性等方面来看,这类通信软件难以适应实时参考咨询系统的要求,不宜用于构建参考咨询系统。清华大学等几家单位租用了国外的Question Point联合虚拟咨询系统(以下简称QP)[2] 来提供实时参考咨询服务,由于服务器在国外而产生的网络迟延以及字符集等问题,在实际使用中多有不便[3],而着手开发自己的实时参考咨询系统。

2 系统体系架构及功能设计

系统设计的指导思想是,以人为本,较高起点,持续发展,实事求是。要最大限度地满足用户的需求,既方便用户的使用,又方便咨询专家和管理员的操作;要尽可能体现最新的技术进展,体现最先进的服务理念;系统要有可扩展性,以便不断升级,满足用户不断增长的信息需求,为系统从文本交互向多媒体转移留出空间;要根据自身的实际情况设计开发方案。

系统的体系结构以及主要模块的构成如图1。

图1 系统的体系结构及主要模块图

2.1 数据层

系统共有三种保存数据的方式:文本文件、内存变量、数据库,分别适应不同数据的使用需要。

在线用户的信息以程序变量的方式保存在内存中,可以最大限度地提高存取速度,使列表能够最快速地反映实时信息。

用户和咨询员之间的对话信息保存在HTM文本文件中,而不占用内存,减少了系统的运行开销,在双方对话时直接存取文件,避免了频繁访问数据库而造成阻塞。

咨询结束后统一将保存咨询记录的文件内容装入数据库中,并实现和用户信息、咨询员信息、反馈信息的关联,实现全文检索。

2.2 控制层

控制层实现对以上三种数据的管理,主要通过在服务器后台运行的主控模块来自动遍历用户列表,检查在线用户的状态,并实现文件管理、数据入库等操作。

2.3 应用层

应用层主要包括实时咨询模块和多个管理模块。实时咨询模块实现咨询员之间和用户之间的文字交互。反馈表、用户管理、记录管理、统计等管理模块则主要对已经入库的数据进行操作整理。

2.4 辅助层

通过使用常用语、网页推送、文件传送等功能,为咨询员提供除文字交互以外的其他辅助手段来解答咨询。

图2为用户、咨询员、管理员等不同角色进入系统后的流程示意图。

图2 系统的主要流程图

系统具有支持多语种、并发多用户等特点,除具有基本的实时问答功能外,还提供其他多种管理功能和辅助服务功能,主要包括:

(1)网页推送:咨询员输入网址,用户端将显示该网址所对应的页面。推送过程为单向;

(2)文件传递:咨询员可以根据需要将本地的文件发送给用户;

(3)电子邮件:问答结束后,咨询记录将自动发送到读者的电子信箱中;

(4)保存和打印:用户可以在咨询过程中随时对谈话内容进行保存和打印;

(5)常用语:咨询员可以将经常使用的文本保存为常用语,在服务中随时调用,提高服务效率;

(6)问题转移:根据在实际咨询过程中出现的情况,咨询员可以随时将用户的提问转移给其他的在线人员,也可以转移到非实时咨询中;

(7)实时监控:系统管理员能够实时查看系统的运行情况,以及正在咨询中的具体内容;

(8)统计:可以对咨询记录、用户访问、意见反馈等数据进行统计,以了解系统的运行效果;

(9)知识库:管理员定期对咨询记录进行整理,并将具有参考价值的内容存入知识库中,支持全文检索。

3 系统开发关键技术的选择与实现

3.1 技术架构的选择

本系统采用主流的B/S架构,遵循J2EE规范,后台用文本数据库进行持久存储,支持全文检索。目前,基于Web的文本交谈从获取信息的方式上,大概可以分为两类[4]:一类是基于刷新的,另一类是基于“推”(Push)的。

前者在客户端的网页中使用某种机制,使该页面每隔一定时间自动刷新一次,借刷新所发出的HTTP请求,从服务器获取最新的发言信息。其优点是实现简单,且如果网络延迟不是问题的话,其总体成本将是最优的;其缺点是由于网络传输量大,在一个低速的网络上,延迟将变得很明显,及频繁的数据传输任务还将加重服务器的负担。

后者则需要一种服务器主动的传输机制。由于HTTP的限制,服务器端不可能直接发起连接到客户端并传输最新数据,整个实现空间被完全限制在现有的拉的方式中,即由客户端以通常拉的方式发起一个连接到服务器端,然后该连接一直保持。当有新信息到达时,服务器便将该信息经由用户打开的连接送出。从客户端来看,该过程就好像一个长时间的拉过程,服务器的响应是断续的,每次响应都是一条(或多条)新信息。其优点是节约了网络带宽、降低了网络延迟,又减少了服务器的负担。其缺点是持续响应时间有限,必须进行连接管理,且面对不同类型的浏览器和网络连接环境,使用效果差别大,部署成本非常高。如果网络带宽和服务器负担实际上不是问题,其总体拥有成本将高于基于刷新的聊天室。

考虑到读者使用的操作系统、浏览器的多样性,以及上网条件的复杂性,为了能保证最基本的功能的实现,采用前者作为系统的技术选择。

3.2 刷新策略的选择

实时咨询系统通过定时自动刷新页面的方式来完成咨询员与用户之间的交互,然而定时刷新作为一种基本的交互方式在实际中存在一些问题,比如会造成页面闪烁、妨碍用户操作等,因此需要通过使用一些技术手段进行优化,主要包括:框架结构技术,隐藏帧刷新技术,XMLHTTP技术等。

3.2.1 框架结构技术

将系统的对话界面划分为展示帧和提交帧,通过展示帧的定时刷新来显示动态的对话内容,用户通过提交帧来向服务器提交信息,将两者放置在同一个框架结构中。这样在保证了页面完整的同时使获取信息和提交信息相分离,使定时刷新不会影响用户的操作。

3.2.2 隐藏帧刷新技术

在页面框架中再分割出一个尺寸为0的隐藏帧,由这个帧完成定时刷新获取服务器的信息,然后通过javascript将信息写入展示帧,从而代替展示帧自身的刷新任务,这样就解决了页面闪烁的问题,使实时咨询系统达到预期的效果。

3.2.3 XMLHTTP技术

使用隐藏帧后仍然没有脱离定时刷新的一些影响,当隐藏帧刷新的时候虽然不会造成闪烁,但是会使提交帧暂时失去焦点,在某些中文输入法和非IE浏览器的使用上,会因为焦点的失去而丢失浮动窗口中的文字内容,例如在Maxthon中使用智能狂拼时。因此引入XMLHTTP对象来代替定时刷新。

实时咨询系统中使用的各页面之间的操作关系如图3。

图3 系统主要页面之间的操作转换关系图

3.3 性能的考虑

对于采用刷新策略来动态更新客户端显示内容的系统,交谈双方必然要频繁地访问服务器,以获取最新的信息。这就要求服务器端的程序要有较高的响应性能。一旦服务器程序不能满足要求,整个系统的交互瞬时将被堵塞。因此,必须对服务器的信息处理进行优化。

服务器端收到信息主要有两大类:一是用户提交自己的发言,二是用户要求系统提供最新的交谈记录。对这两类信息的处理是优化的重点。对于前者,需要将其保存以便于其他交谈对象看到。由于无法预知一次交谈的内容的长短,所以需要提供一种不限长度的存储机。目前比较成熟的存储机制,一是文件系统,二是数据库系统。对于后者,要尽可能快的将信息生成并返回。理论上讲,如果数据都在服务器的内存里,则可以达到最快的响应速度。但将无限增长的交谈信息保存在有限物理内存中是不现实的。如果将交谈信息保存于数据库中,则对于这样一个并发系统,数据库的访问会成为系统的瓶颈。如果将交谈信息保存在文件中,则整个系统的性能将受限于服务器硬盘的I/O速率。根据实际测试,本系统采用了两级缓存机制:将最近交谈的20条(具体数值可以由系统管理员动态设置)信息,存放于内存中,每次用户请求最新交谈内容时返回这20条信息;这次交谈的全部信息临时存放于硬盘文件中,同时提供给用户一个访问全部交谈信息的链接;当交谈结束时,将该文件的内容连同其他信息一次性转存于数据库中。

两级缓存的引入借鉴了“推”技术的长处,减轻了网络传输的流量,降低了服务器的压力,减少了客户端信息显示的迟延,用户体验非常好。

3.4 系统的监控

本系统引入两种实时监控:一种是定期自动监控,用于解决网络连通的不确定性问题;另一种是人工实时监控,用于系统的维护管理。

由于网络传输的数据帧异常丢失,或者客户端的系统不稳定,会出现用户突然联系的现象。引用第一种监控,就是为了能够尽快发现用户丢失的问题,以保存交谈的信息,回收系统的资源。由于每个咨询人员同一时刻只能同时跟有限个读者进行交谈,后到的读者只能处于等待状态,迅速清理这类丢失的用户,才能为等待的用户提供交谈机会。这也是这种监控的必要性之所在。

人工实时监控主要用于管理目前在线的咨询人员和读者,可以在线审查他们的交谈内容,以及必要时可以中断他们的不合适的交谈。同时,管理员根据需要可以动态设置不同种类的信息的显示颜色(为色弱读者准备)、在线用户最大数目(以动态调整系统的运行性能)、页面刷新时间间隔(兼顾拨号上网、专线上网等不同带宽的读者)、系统服务时间区间(以动态适应节假日工作时间调整)及用户发呆时间等内容。

4 系统实际应用效果

NSTL实时参考咨询服务自2004年9月中旬开通试运行,对广大网络用户提供文献咨询服务,目前已经接受了1000多次用户提问,其中有500多条具有参考价值的记录经咨询员审核后进入知识库供用户检索查看。实时咨询的开通为广大用户提供了一种新的服务方式,解决了许多用户在文献查找和使用中所遇到的实际问题,促进了NSTL的发展。

实时咨询开通的前期采取2名咨询员同时值班的工作方式,服务时间为周一至周五的上午9点至11点,每天2个小时。通过咨询员之间的协调和配合共同向用户提供服务,当出现较多的并发用户时也能够分担工作量。经过一段时间的运行后,咨询员的业务水平得到了提高,能够处理较为复杂和繁忙的情况。因此从2005年3月起实时咨询增加了每天下午2点至4点的开放时间,改用单人值班的方式。

用户反馈调查是实时咨询的一项重要功能,通过反馈表,可以及时了解用户需求,发现问题,从而进一步完善系统功能,提高服务质量。反馈表会在用户结束咨询的时候自动弹出供填写。根据对用户反馈的调查,对反馈表中关于实时咨询的六个方面的问题,有76%的用户表示非常满意,21%的用户较为满意,不满意的占3%,其中由于网络传输造成的时间上的延迟是影响用户满意度的主要原因。许多用户在反馈表中还提出了许多有益于系统完善的意见和建议,促进了实时咨询服务水平的提高。

5 下一步要研究的问题

咨询过程的互动性,如白板或同步浏览等,以及多媒体实时咨询,目前受限于网络的带宽等因素,在实际中难以形成有效应用。但是采用IPv6技术的下一代互联网,将给我们提供高速通讯的带宽。随着它从实验网络逐渐走向实际应用,咨询过程的互动性的需要越来越迫切,值得进一步研究。另外,系统建成之后,如何与QP及国内各家实时咨询系统进行互联互通,实现咨询协作,也将是下一步要研究的问题。

随着浏览器更新的普及和网络环境的日益改善,一些新的客户端技术的不断出现,为实现实时咨询系统提供了新的技术手段,值得关注。比较有代表性是MacroMedia公司引入了RIA概念并推出的flex[5],以及Sun公司计划纳入到j2EE中[6] 的ajax[7],这两者不但能用于构建丰富行为功能的客户端,且为解决客户端与服务器的后台交互提供了新的思路。

收稿日期:2005年4月25日

标签:;  ;  

网上实时参考咨询系统的设计与实现_实时系统论文
下载Doc文档

猜你喜欢