按照图书馆电子阅览室管理系统中各个组成部分在整个电子阅览室网络系统中的运行位置和使用环境,有学者将图书馆电子阅览室管理系统分为刷卡端、学生端、Web服务端、应用服务端、数据库5个部分^{[ 3]}。不过,这样分类还不够完整,可以再增加查询端和一卡通系统两个部分。另外Web服务端、应用服务端、数据库三个部分往往集中在一台服务器上,可以合并为一个服务端。因此,笔者将基于一卡通的图书馆电子阅览室管理系统分成一卡通系统、服务端、管理端、刷卡端、客户端、查询端6个部分,如图1所示:

图1

	Figure Option ViewDownloadNew Window
	图1 一卡通电子阅览室管理系统组成

基于一卡通的图书馆电子阅览室管理系统的模块如图2所示:

图2

	Figure Option ViewDownloadNew Window
	图2 一卡通电子阅览室管理系统模块图

由于管理端、客户端、查询端三个部分与扣费模式关系不太大,因此将着重对一卡通系统、服务端、刷卡端三个部分进行详细的论述。

(1)一卡通系统:校园一卡通系统存储了全体师生员工的信息,包括一卡通账号、姓名、学工号、密码、卡内余额、状态(禁用、注销、挂失等)等,主要负责完成一卡通账户的扣费以及为电子阅览室管理系统提供用户的原始数据^{[ 4]}。

(2)服务端:服务端是整个图书馆电子阅览室管理系统的核心,服务端从校园一卡通系统获取用户原始数据并为管理端、查询端、刷卡端、客户端提供服务。服务端与管理端之间采用C/S模式,服务端与查询端之间采用B/S模式。B/S模式是由传统的两层C/S结构发展而来的三层C/S结构在Web中的应用,它把C/S结构中的逻辑/业务规则模块从客户机的任务中分离出来,由Web服务器来承当,从而减轻了客户机的压力^{[ 5]}。

(3)刷卡端:当用户刷卡后,从一卡通系统读取用户的信息,将获取的信息传送到服务端,在下机时从服务端读取上网费用并进行写卡,并且负责将获取的信息显示出来,完成用户的上下机^{[ 6]}。基于以上功能,刷卡端可分为读卡写卡模块和信息显示模块两个部分。

后台模式是扣费不在刷卡端实现,而是通过本地服务端与一卡通服务器之间的对话来实现的一种扣费模式,该模式流程如图3所示:

图3

	Figure Option ViewDownloadNew Window
	图3 后台模式流程图

后台模式在读者下机时只是从本地服务端数据库里读取用户的上机时间、上机费用以及卡内余额等信息,并不写卡,用户下机刷卡1分钟后本地数据库将该用户的费用记录上传到一卡通数据库,待读者到食堂等地方的POS机上刷卡消费时,一卡通服务器对该用户的卡片进行写卡,这样可达到一卡通卡片中的信息与一卡通数据库中该用户信息的匹配。如果用户下机不刷卡,经过时间t(t表示用户下机不刷卡时服务端为用户保留下机前所使用机器的时间,下同)后服务端将该用户强制下机并把扣费信息通过TCP/IP协议以及SQL查询语句传递到一卡通服务器。此模式有如下两个弊端:

(1)扣费并不是在本地刷卡端完成,而是在食堂等地方的POS机上完成。如果用户一直未到食堂消费,那么该用户下次到电子阅览室刷卡时此笔费用仍旧没有被扣除,这样可能给学生造成扣费与实际情况不符合的错觉而去找管理人员查询扣费记录,从而增加管理人员的工作量。

(2)用户下机后不刷卡并在时间t以内到食堂去消费的时候发现上机费用并没有扣除掉,毕业时有可能会逃避刷卡,然后在时间t内到一卡通中心将该卡注销来逃避费用,从而导致一卡通系统扣费与电子阅览室服务端扣费不一致。

用户在后台模式下刷卡离开时不能在本地刷卡端实时扣费,而且学生在毕业离校时可能逃避刷卡并到一卡通中心注销一卡通来逃避费用,因此需要有一种新的模式来替代后台模式,而前台模式的出现刚好改正了后台模式的部分缺点。前台模式是指扣费在刷卡端实现的一种扣费模式,其流程如图4所示:

图4

	Figure Option ViewDownloadNew Window
	图4 前台模式流程图

在前台模式下,读者刷卡离开时刷卡端从本地服务端数据库里实时读取用户的上机时间、卡内余额以及上机费用等信息,并把该信息传递到一卡通服务器进行写卡。此模式不要求用户到食堂等地的POS机上写卡,只需在本地刷卡端刷卡就可以实现一卡通系统的实时扣费,但该模式对通信质量要求比较高,一旦通信失败就会导致写卡失败。另外该模式要求学生下机时必须自觉刷卡,否则导致费用不能扣除,从而在电子阅览室服务端挂账。

前后台模式将前台模式和后台模式结合在一起,在读者正常刷卡下机时采用前台模式,在学生不刷卡或者采用前台模式刷卡下机通信失败时采用后台模式。前后台模式与前台模式、后台模式相比有如下优点:

(1)前后台模式很好地解决了前台模式在学生下机不刷卡或者刷卡失败的情况下服务端所出现的挂账问题;

(2)前后台模式扣费在本地完成,学生不需要到食堂等处的POS机上去完成补扣费,这样很好地解决了在后台模式下学生刷卡离开时不能实时扣费的问题。

前后台模式虽然比前台模式和后台模式都要优越,但是它仍旧有缺点:学生毕业时可以通过下机后不刷卡并在时间t以内到一卡通中心销卡的方式来逃避费用。如果要改正类似学生通过毕业注销一卡通来逃避费用的缺点,还需要对前后台模式进行改进才能达到要求。基于这个目的,本文对该模式进行了改进,可把它称为改进型前后台模式。改进主要针对时间t进行,t表示用户下机不刷卡时服务端为用户保留其下机前使用的那台机器的时间。在前后台模式中,时间t= t₁+ t₂+ t₃+ t₄,其中t₁表示处理客户端电脑故障的平均时间;t₂表示从电子阅览室到一卡通中心路途中所花的平均时间;t₃表示在一卡通中心排队的平均时间;t₄表示填写注销单的平均时间。而在改进型前后台模式里将用户下机不刷卡时服务端为用户保留机器的时间由t缩短为t', t'满足 t'₁2+ t'₃+ t'₄,其中t'₁表示处理客户端电脑故障的最短时间;t'₂表示从电子阅览室到一卡通中心路途中所花的最短时间; t'₃表示在一卡通中心排队的最短时间; t'₄表示填写注销单的最短时间。在用户下机不刷卡的情况下经过时间t'后服务端将该用户强制下机,然后将用户信息通过TCP/IP协议以及SQL查询语句传递到一卡通服务器,从而解决了前后台模式所出现的逃费问题。将时间t缩短为t'而不是1分钟的原因是大学的图书馆电子阅览室到一卡通中心往往比较远,在时间t'内学生一般不可能在关闭计算机后从电子阅览室赶到一卡通中心去注销,即使学校一卡通中心与电子阅览室比较近,学生能在时间t'内从电子阅览室赶到一卡通中心,但还需要排队、填写注销单等,这些过程完成后时间t'已经过去了,学生仍旧不能逃避费用。此外把保留时间定为t'(t'>t'₁>1)与1分钟相比有一个明显的优势,那就是学生在电脑出现死机等故障后要花1分钟以上的时间(t'₁>1)找到管理员并处理遇到的问题,在时间t'内(t'>t'₁)服务端仍旧为该用户保留其使用的那台机器,在机器恢复正常后用户仍可以使用该机器,不需要重新刷卡来分配机器,这可以体现图书馆以人为本的服务理念。改进型前后台模式的流程如图5所示:

图5

	Figure Option ViewDownloadNew Window
	图5 改进型前后模式流程图

该模式目前已经在杭州师范大学钱江学院图书馆进行了应用。该校图书馆电子阅览室是教育硕士机房,对本科生和教育硕士均开放。图书馆于2010年3月中下旬对原先采用的前后台模式进行了改进,4月初进行试运行。如表1所示,对升级前后服务端与一卡通系统的扣费情况进行对比,可以看出:在升级前的1月份,由于没有学生毕业,所以一卡通扣费与本地服务端扣费基本一致。在2010年2月份有教育硕士毕业,存在个别教育硕士在下机时逃避刷卡并到一卡通中心注销的现象,所以在表1中2月份服务端扣费与一卡通扣费存在较大的偏差。2010年4月、5月,在升级后由于不存在学生毕业,所以本地服务端扣费与一卡通系统扣费几乎无偏差。2010年6月22日为本科毕业生以及研究生离校的时间,截止到23日服务端扣费与一卡通系统扣费的偏差比2010年2月小很多。因此,改进型前后台模式在应用时是比较成功的。

表1

表1

表1 服务端与一卡通系统扣费对比情况 月份 扣费情况 (单位:元) 2010.1 2010.2① 2010.4② 2010.5 2010.6③ 一卡通系统扣费 5736.45 1643.32 5105.93 6564.33 4308.02 本地服务端扣费 5737.81 1653.70 5106.49 6565.51 4309.20 本地服务端扣费与一卡通扣费的偏差(%) 0.02% 0.63% 0.01% 0.02% 0.03% (注: ①2010年2月初放寒假,所以数据比较小;②2010年3月系统升级,数据无效;③2010年6月份数据截止到6月23日。)

表1 服务端与一卡通系统扣费对比情况