异构数据库统一检索平台

分类:其它    发布时间:2011-1-21 17:56:00

1 引言

异构数据库统一检索平台是近来高校图书馆与相关公司开发与研究的一个热点,他们不断推出新的方案与产品,复旦大学图书馆与上海金鑫公司、清华大学图书馆与清华同方公司、北京大学图书馆与CALIS中心合作开发过同类系统。华中科技大学图书馆采用DotNet框架技术开发出同类应用系统。

目前国外的webfeat的技术来自于自身的研发,应该说在目前的三个国外同类的跨库检索软件中(webfeat、MetaLib和Muse)中独具特色,很有竞争力。

网站(http://www.webfeat.org/)。首页介绍:“WebFeat被用于超过16500个公共、学术与政府机构,及全球1000图书馆与信息中心──包括美国100个最大公共图书馆中的1/3、17个州立图书馆、1/5研究图书馆协会馆。

异构数据库统一检索平台要求有较好的互操作性。互操作在异构仓储间有四种方式:一是集成,它是对资源深层次挖掘的基础,实现概念、语义的联合和知识的互操作;二是联邦,是指将查询请求分发到各个信息仓储去分别执行,收集返回的检索结果,汇总、整理后交给用户。联邦的方法要求每个仓储都支持统一的搜索语言,或者在本地语言和协议语言间相互转换,而且要求对查询做出快速的实时响应。三是收集,它是先把仓储中的资源收集到本地,而利用本地的资源拷贝提供服务。由于存在收集的困难和存贮的限制,在数字图书馆的互操作方案中很少采用收集的方法。四是采集,采集方法不直接收集原始资源,只是将关于这些资源的元数据从各个仓储中收集来提供服务,原始资料还需要到它所在的仓储中去提取。

由于大多图书馆只有对电子资源的使用权,而电子资源中的大多数据库接口不大可能向用户开放接口,在异构仓储间的互操作方法中,常用的也就是采集方法。

2 异构统一检索平台特点

大量数字文献资源的出现,不仅仅给图书馆在资源建设和组织管理上带来冲击,同时还要求图书馆采用先进技术构建一种全新的文献信息服务环境来满足不断扩张的用户需求。用户对资源缺乏足够的认识,读者若想获得全面而准确的信息往往需要依次进入各个电子资源的搜索界面进行搜索,并且要对各个数据库的搜索规则有足够的认识,方可获得所需的信息,而且我校的电子资源还在不断购进。如果用户对资源缺乏足够的认识,对系统不熟悉,而且各个系统都要进行登录和认证,这给用户检索利用数字带来极大不便。

华中科技大学图书馆针对这一情况,依托图书馆丰富的电子资源,经过反复的酝酿,开发出了华中科技大学图书馆统一检索平台(HUSTLIB-URP,HUSTLIB-UNION RETRIEVAL PLATFORM),并应用于为全校师生服务。

系统具有如下优势与特点:

并发统一检索:

多个网络数据库通过多线程机制并发检索,使用户感觉不到同时在检索多个数据库。

快速响应及结果缓存:

用户对多个数据库进行检索时,采用先出来先显示的机制,速度最快的检索结果会先显示给用户,其它数据库的检索结果存入缓存。在用户要查看其它数据库的结果时会大大提高速度。

通用性好:

统一检索平台无须数据库提供接口,利用已有的各种Internet途径访问网络数据库,然后采用网页分析技术得到数据库记录。

结果页面可继续浏览,支持文件下载

在结果页面中可以点击链接继续浏览或下载各种格式的文件。

支持简单检索和高级检索:

在简单检索中用户可以像在原库中一样选择各种检索字段。在高级检索中可以输入多个检索条件进行逻辑组合检索。

异构数据库统一检索平台IP认证

虽然购买的各个数据库都进行了IP认证,但统一检索平台相当于一个代理程序,如果不进行IP地址限制,非法用户将会访问到相应的资源。

主页面数据库导航功能

异构数据库统一检索平台通过按中文数据库学科分类导航或西文数据库学科分类导航来选择数据库,帮助用户选择相应的数据库。

与用户合作进一步开发应用

现正与在武汉的全国8所重点大学图书馆合作,为他们开发有自身特点的相应应用系统。

对外技术成果转让

已对省图书馆和地质大学进行定制开发。

开发费用合理

可向用户提供部分源代码。

3 采用模式和架构的原则

模式完全采用了DotNet技术及架构。架构(Architecture)是软件设计中非常重要的一个环节。软件开发的过程中只要需求和架构确定之后,这个软件基本上可以定型。架构设计是一种权衡。一个问题总是有多种的解决方案,而要确定唯一的架构设计的解决方案,就意味着要在不同的矛盾体之间做出一个权衡。在设计的过程中总可以看到很多的矛盾体:开放和整合,一致性和特殊化,稳定性和延展性等等。任何一对矛盾体都源于对软件的不同期望。满足软件稳定运行的要求,就必然会影响对软件易于扩展的期望。要软件简单明了,就会增加设计的复杂度。没有一个软件能够满足所有的要求,因为这些要求之间带有天生的互斥性。而评价架构设计的好坏的依据,只能是在其间做出权衡的合理性。

一个好的架构目标能够:重用、透明、延展、简明、高效、安全。

应用程序体系结构。从抽象的体系结构级别开发应用程序。应用程序是面向对象的应用程序,它在逻辑上构造成三层服务应用程序。应用程序是基于OLTP 处理模型的。从基础结构视点,硬件和网络体系结构是基于四级分布的,这要求 Web 服务器功能和应用程序服务器功能具有不同的物理级。并基于复杂的 Web 应用程序创建了一个部署规划,以便将组件映射到服务器。

解决方案是使用 Microsoft.NET 技术构建的。表示层基于 ASP.NET 中内置的 Web 表示框架。ASP.NET 使用内置的代码隐藏页功能来简化 Model-View-Controller 的实现。使用 ASP.NET 中内置的 Page Controller 机制来实现表示逻辑。业务层中的域对象是 .NET 托管对象。因为表示层和业务层部署在不同的级上,所以使用服务器激活对象通过 .NET Remoting 实现代理。最后,数据层基于Microsoft.NET Framework 中的 ADO.NET 类来提供数据库访问。表模块和业务实体是使用 ADO.NET 的数据集组件构造的。数据访问组件的其余部分由.NET 构建块提供。

由于在构建企业级解决方案时会涉及到大量模式,将各种模式组织成了更小、更紧密相关的模式集。

在浏览模式的机制方面,利用了关系、抽象级别、群集和视点。

实际上,当用户在角色、主题范围和详细程度之间切换时,将自然而然地在这些机制之间进行了切换。

Web 应用程序的用户界面功能实现模块化。

用户界面逻辑的更改往往比业务逻辑频繁,尤其是在基于 Web 的应用程序中。例如,可能添加新的用户界面页,或者可能完全打乱现有的页面布局。毕竟,基于 Web 的瘦客户端应用程序的优点之一是可以随时更改用户界面,而不必重新分发应用程序。如果将显示代码和业务逻辑组合一起并放在单个对象中,则每次更改用户界面时,都必须修改包含业务逻辑的对象。这很可能引入错误,并需要在对用户界面进行每个极小更改之后都要重新测试所有业务逻辑。

在某些情况下,应用程序以不同的方式显示同一数据。在一些胖客户端用户界面中,常常用多个视图同时显示相同数据。如果用户在一个视图中更改了数据,则系统必须自动更新该数据的其他所有视图。

简单有效的 HTML 页通常要求采用一套与开发复杂业务逻辑不同的技能。用户界面活动由以下两部分组成:显示和更新。显示部分负责从数据源检索数据,并格式化数据以便进行显示。当用户基于该数据执行操作时,更新部分将控制权返回给业务逻辑,以便更新数据。

在 Web 应用程序中,单个页面请求将这两方面的工作组合在一起:与用户所选链接相关联的操作进行的处理,以及目标页面的显示。在许多情况下,目标页可能不与操作直接相关。例如,假设有一个用于显示项目列表的简单 Web 应用程序。在将项目添加到列表或从列表中删除项目之后,用户将返回主列表页。因此,应用程序必须在执行两个有很大差异的命令(添加或删除)之后显示相同页面(列表),而所有这些操作均在同一个 HTTP 请求内进行。

4 结构分析

HUSTLIB-URP结构分析采用的是模式分析方法。模式描述能给定上下文中反复出现的问题,并基于一组指导性影响因素来建议解决方案。解决方案通常是一种简单的机制,是为了解决模式中所标示出的问题而一起工作的两个或多个类、对象、服务、进程、线程、组件或节点之间的协作。而OLTP 系统是用来管理事务处理的数据库子系统。这些子系统确保每个事务的原子性、一致性、独立性及持久性(所谓的 ACID 特性)。

由于HUSTLIB-URP 是一个典型的N层架构,其结构分为四个逻辑层:

4.1 Web 层

Web 层为客户端提供对应用程序的访问。这一层是作为 HUSTLIB-URP.sln 解决方案文件中的 Web 项目实现的。Web 层由ASP.NET Web 窗体和代码隐藏文件组成。Web 窗体只是用 HTML 提供用户操作,而代码隐藏文件实现各种控件的事件处理。

Web 层上还用到了JAVA页面处理技术,实现选择数据库个数计数、内容介绍显示、流量计算等功能。

4.2 业务外观层

业务外观层为 Web 层提供处理合法用户验证、服务器选择、日期处理结果及程序异常结果显示的界面。业务外观层用作隔离层,它将用户界面与各种业务功能的实现隔离开来。除了低级系统和支持功能之外,对数据库服务器的所有调用都是通过此程序集进行的。

4.3 业务规则层

业务规则层是作为 HUSTLIB-URP解决方案文件中的商务规则项目实现的,它包含各种业务规则和逻辑的实现。业务规则完成合法数据的验证、实现各个检索数据库的接口数据传输这样的任务。

4.4 数据访问层

数据访问层为业务规则层提供数据服务。这一层是作为 HUSTLIB-URP解决方案文件中的检索项目来实现的。

这里有特点的是业务外观层和业务规则层,在WEB应用的N层结构开发的中,使用最多的是三层结构,分别为:表示层,中间层和数据层。HUSTLIB-URP的WEB层和数据访问层比较好理解,也就是传统意义上的表示层和数据层,其业务外观层和业务规则层则是其独有的。

5 系统界面与检索结果展示

系统界面与检索结果展示见图1~3所示。

clip_image002

图1 检索主界面

6 结束语

本系统可检索中文和外文数据库,兼容所有可检数据库。真正的原始结果,在原有界面中提供全文结果,保留所有原有功能。兼容所有主要OpenURL链接解析器,OpenURL链接可嵌入结果引文,方便用户通过鼠标点击找到电子文章。

解决方案必须确保满足不可预知数量的用户的要求,尽管可通过多种方法来提高性能和可靠性,主要关注如何组合服务任意数量的应用程序或用户的多个系统,以提高可伸缩性和可用性。在本系统中分别应用服务器群集、负载平衡群集和故障转移群集方案,以提高系统的性能和可靠性模式。在研究与开发HUSTLIB-URP系统时,就所能够领悟到.Net应用架构的设计思想,应用到.Net的编程中。随着开发软件的便利与通用性,各类统一开发平台的不断推出,统一检索开发应用系统与产品和软件开发工作将会更完善。

Email: hustdl@sohu.com

clip_image004

图2 检索元数据结果界面

clip_image006

图3 点击检索元数据可直接显示全文结果界面

最新评论

我要发表评论

名称:
电子邮件:
个人主页:
内容:

 博客分类