通讯协议

目前的图书情报服务系统都是构架在互联网技术之上的，底层网络协议采用的也是TCP/IP和HTTP协议，这些协议大家都非常熟悉本文不再介绍。下面将主要介绍两个与图书情报服务相关的应用框架协议即Z39.50和SRW/SRU。

 

1 Z39.50协议及其应用

 

1.1 Z39.50说明

Z39.50是一个用于远程数据库进行情报检索与查询的客户－服务器连接协议。其标准名称为ANSI/NISO Z39.50,ISO 标准为Z3950。美国国会图书馆负责这一标准的维护和管理。该协议全称是“信息检索(Z39. 50)应用服务定义与协议描述”(Information Retrieval (Z39. 50)Application Service Definition and Protocol Specification )。

 

1.2 Z39.50协议应用

 

Z39.50协议被广泛应用于图书馆服务系统，特别用于馆际集成图书馆服务系统和个人参考编目软件（客户端软件）。目前图书馆的馆际互借系统大都是采用Z39.50协议接口进行查询。

 

1.3 Z39.50的历史

与Z39.50协议与1984年提出，分别在1988、1992和1995推出几个版本。该协议支持包括查找、检索、排序和浏览在内的多个与情报服务相关的动作协议。检索支持属性检索，尤其支持bib-1属性集。Bib-1是Z39.50的重要组成部分，它定义了6个与情报检索相关的属性。

Z39.50在推广中遇到的主要障碍来自标准自身，因为它是一个过于完美的、复杂的、重量级的协议。标准正式文本厚达156页，2002草案也有147页。标准的实施需要软件开发者了解数据结构、网络通讯、编码解码、数据库等诸多面的知识。该协议的展示层(Presentation Layer)采用的编目规则是20世纪80年代的发展成熟的标准，该规则需要对传输的数据进行二进制编码。协议包含的许多OSI中并不流行的概念，如:连接(Connection)、状态(Status)等。总之，标准的复杂性使Z39.50的实施工作面临技术风险，同时Z39.50协议是基于TCP/IP协议的，与目前互联网通讯为主的应用相比，也的确有些不跟潮流，有人称Z39.50为Pre_Web技术。为使239.50能成为主流的信息检索协议，以吸引更多的信息提供者、和用户，从而具有更大的应用价值，一部分Z39.50的实施者开始讨论239.50标准的改造。讨论始于在2000年12月的ZIG(Z39.50 Implementers Group,Z39.50实施小组)会议并持续至今。在2001年6月的ZIG会议上，一些ZIG成员提出了以Web服务方式实现Z39.50的一些规范，这些规范的基础是Z39.50和包括XML、SOAP、URI和HTTP的Web技术。这些规范被称作ZING (Z39.50Next Generation).意为“下一代Z39.50"，这些规范在早先的时候称作ZML(Z39.50 over XML),意为“基于XML的Z39.50”。

关于ZING中涉及Web Service服务的部分在下一部分中介绍。

 

1.3关于Z39.50的几点看法

 

尽管Z39.50协议无论从底层通讯协议(TCP/IP)还是内嵌检索接口语言方面都存在一些问题，但毕竟该技术已经经过20多年的发展基本成熟。该协议是图书馆系统满足馆际通讯与互借的唯一协议，到目前为止，多数馆际互借系统是以Z39.50协议为基础的构建的。近期要想实现图书馆系统的整合服务还必须重点考虑Z39.50接口，在中国更是如此。

Z39.50协议只是一个图书馆服务系统服务器端对外提供的接口协议，与底层数据库管理系统无关。目前还没有独立的Z39.50数据库服务系统，所有的Z39.50服务都是由应用服务器实现完成的。

传统Z39.50应用服务器对外提供的数据服务格式为MARC格式标准，与现有以XML为基础应用系统的集成也存在系统数据交换之间的问题。

 

2.    ZING与Web Service

2.1 ZING

如上一结所述ZING是Z39.50的下一代协议，是为了满足图书馆系统的基于互联网的馆际应用而提出的。这个项目起初的工作主要是力求从概念上证明建立新标准的可行性。新标准的目的是发展一个轻量级检索服务标准并可以通过新标准整合地访问不同的网络资源，更确切地说，新标准是在保留Z39.50标准近20年积累的知识成果的基础上，减少实施的技术难度，并淘汰没用的和没有意义的内容。在ZNG提出后，其它几种Z39.50的改良方案也相继提出，包括ZOOM、ez39.50和ZeeRex。其中，ZOOM (Z39.50 Object-Orientation Model，面向对象的Z39.50模型)力图推出Z39.50服务子集的抽象API，从而既保留Z39.50标准协议又隐藏协议的复杂性。ez.39.50利用XER编码实现ASN.1到XML的转换，从而可以通过SOAP - HTTP传递消息，既避免BER编码，又可以不修改Z39.50的ASNI定义。ZeeRex (Z39. 50 Explain, Explained and Re一Engineered in XML)是针对Z39.50的解释服务提出的改造计划。由于这些方案都是对“下一代Z39. 50”的讨论，所以原来的ZNG使用更明确的名称SRW (Search/Retrieve Web Service)和SRU(Search/Retrieve URI Service)，这些方案总称为ZING (Z39.50-lnternationaL Next Generation)。由于SRW /SRU产生最早，相关标准制定相对成熟，目前已被国外许多信息服务机构所接受。

2.2    SRW

SRW(Search/Retrieve Web Service查询与检索Web服务)就是以Web服务方式实现Z39.50的功能。SRW结合了Z39.50的查询(Search)和提取(Present)两个服务，定义了一个单一的Web服务。因为查询和提取是紧密联系，互相依赖的关系。为了简化，直接将它们结合定义一个成为一个Search/Retrieve对。一个Web服务只能处理一种形式的请求，如果要将Z39.50的浏览(Scan)服务包含到SRW项目中来，就必须在定义一个新的Web服务。考虑到Z39.50的主要目的还是信息的查询与检索，目前SRW只定义了一个服务，还不包括Z39.50其它的服务。目前,SRW协议的1.0版的草案初稿己经制定出来了。协议对SRW的请求和响应包含的参数做出了明确规定。

 

一个查询/检索请求(Search /Retrieve Request),包含如下参数

① Query查询语句

SRW使用CQL查询语句，仅归纳为5种形式供后面的接口标准部分介绍使用。

a.一个单一的查询子句，例如dc.Title.Word=”computer system”；

b.布尔运算符连接的多个检索子句；

c.布尔运算符连接的结果集和检索子句；

d.单个结果集名，例如“result set RSl"；

e.布尔运算符连接的多个结果集名，例如(“result set RS7” AND “result set RSV”);

② Authentication Token

鉴别标记SR W协议里包含这个参敬，是为了用于特定的用途，协议没有规定authentication Token的应用的含义，而只是规定了这个参数在清求和响应中出现的规则。具休的应用定义由特定的应用模型确定，例如可以利用它来控制结果集的命名空间，从而可以筒化结果集的命名，这样服务器可以对两个不同客户的不同的结果集给以相同的名字，并由鉴别标记区别。但是这并不是协议本身的规定。但是，如果客户收到的响应中包含结果集名字和鉴别标记在后续的请求中涉及这个结果集时，协议建议客户在请求中包含鉴别标记这个参数数，并使用响应中提供的值。在SRW协议中，鉴别标记和结果集名没有任何联系，但是具体的应用程序可以规定，如果不给出正确的鉴别标记就不能使用结果集.这样可以保证一个客户的结果集不会被其它客户引用。

③ SortSpeco排序参数

请求中可以包含排序参数，以指定返回记录的顺序。排序参数包含在一个查询/检索请求里，而不像传统的239. 50那样是一个单独操作，一方面是出于简化的目的，SRW不强制规定服务器保留结果集以备随后的请求使用。另外，如果服务器在处理查询之前就知道排序的规则，就可以对查询进行某些优化，这可能比先生成结果集然后再对结果集排序的效率更高。当查询的形式是前面所列的前三种的情况时，服务器将连同查询和排序参数处理生成结果集，当查询的形式是第5种情况时，服务器将对已有的结果集排序奋当查询的形式是第4种情况并且布尔运算符是OR时，服务器将直接合并多个检索结果集并排序。

④ StartRecord,MaximumRacords,RecordSchema

查询/检索请求可以指定返回记录的范围，也可以指定返回记录的XML Schema. recordSchema的值是一个XML schema名称成schema的定义URI。可以通过解释信息获得Schema名字与对应URL的列表，SRW 预定义的记录schema 有DC、MarcXml等。

以上是查询的全部参数，只有query是必选的，其它参数都是可选的一个查询/检索响应(Search/Retrieve Response)包含如下参数：

● NumberOiRecords，记录数响应总会返回这个参数，这个参数数是生成的结果集包含的实际记录数.如果查询失败，这个值是0；

● AuthenticationToken鉴别标记

● AtldleTime,鉴别标记的有效期；

服务器在响应中提供一个鉴别标记的同时还要指定它的有效期，在有效期内，客户可以使用这个鉴别标记.在后续的交互中，如果服务器在响应中包含同样的鉴别标记，表示服务器里重置了鉴别标记的有效期。

● ResultSetld和rsIdleTime,结果集名和结果集有效期。服务器可能在响应中提供结果集名和结果集有效期，以便客户可以在随后的请求中引用。rsldleTime是个大于0的整教，代表以秒为单位的时间长度。如果服务器不希望用户在使用结果集，可以不提供resultSetld参数，而不是把rsldleTime设定为一个足够小的值。

关于SRW请求和响应的参数详细说明参见：

http://www.loc.gov/standards/sru/srw/index.html

SRU(search/retrieval URI service)可以说是SRW 的简化版，不同的是SRW的信息是通过HTTP POST方法发送的XML/SOAP/RPC消息。而SRU不使用SOAP,它的请求信息是通过HTTP GET发送的，参数包含在URL里。例如:

http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=dinosaur

关于SRU请求和响应的参数详细说明参见：

http://www.loc.gov/standards/sru/sru-spec.html

SRW /U作为下一代Z39. 50计划成员之一，它不是对Z39.50-1995版的更新和替代，而是一种在继承原有Z39.50标准合理成分的基础上建立的全新的体系。SRW /U的成熟和发展，最终不会简单地取代原有Z39-50标准，而很可能会与原有Z39.50标准共同发展，在不同的领城发挥作用。

SRW/U实施更简单，更加于目前的计算机行业相接轨，因此也更具有市场潜力，更有希望推广到商业信息位索领城。而传统的Z39.50将继续应用于图书、情报等文献信息领域.另外，SRW/U与原有Z39.50显然是不兼容的体系，它们有不同的数据结构和不同的通讯方式。SRW用户不能直接获得Z39.50资源，但是，可以利用SRW建立与现有Z39.50服务器的网关，从而扩展已有Z39.50服务器的服务范围。

关于Z39.50与SRW/U系统的开源代码可以通过如下地址直接获取：

http://www.indexdata.dk/yaz/

  从上面的介绍可以看出ZING和Z39.50相比做了如下两点重大变革：

将原来Z39.50的基础网络协议TCP/IP变更为现在整个计算机行业普遍采用的适用于系统整合的Web Service协议；使得图书、情报服务系统也易于与其他信息服务系统的整合应用。关于Web Service易于整合应用的技术特点，在本文后面部分介绍。

将原来Z39.50采用的比较复杂的检索语言采用了情报服务的最新通用检索语言CQL,大大简化了系统实现的复杂程度。CQL及其应用将在后面介绍。

 

3．Web Service及其应用

 

 对Web Service 目前没有一个严格的定义。一般认为Web Service是一种新型的Web应用程序，具有自包含、自描述以及模块化的特点，可以通过Web发布查找和调用。W3C 将Web Service定义为：Web Service是一个为支持在网络上可互操作的机器到机器的交互的软件系统。Web Service有一个机器可处理的格式来描述的接口，通常是WSDL。其他系统通过SOAP消息中描述的方式与WebService进行交互，一般使用HTTP、XML格式串传送消息。

 

3.1 Web Service 的特点

① 完好的封装性，Web Service 是一种部署在Web上的对象，它具备对象的良好封装性。使用者仅能看到该对象提供的功能列表。

② 松散耦合，当一个Web Service 的方法实现发生变更，甚至是当Web Service 的实现平台发生变更时调用者都不会感到有变化。因为，调用者只关心其接口及其参数，而不必关系该接口是如何实现的。

③ 使用标准协议规范，在Web Service 中所有的技术实现都基于开放的标准协议规范。

④ 高度可集成能力，由于Web Service 采用标准Web 协议作为组件界面描述和协同描述规范，它完全屏蔽了不同软件平台的差异，任何软件都可以通过标准的协议进行互操作，具有较高的可集成性。

3.2 Web Service的体系结构

Web Service采用面向服务（Service-Oriented　Architecture SOA）的体系结构，如下图所示：

 

服务代理

发布

查询

 

 

 

服务提供者

服务提供者

发布

查询

 

 

  Web Service面向服务体系结构

 

该SOA体系结构中有服务提供者、服务请求者和服务代理三种角色，通过三个基本操作发布、查找和绑定来相互作用。服务提供者向服务代理发布服务，服务请求者通过服务代理查找所申请的服务，并绑定到这些服务上。在Web Service 体系结构中使用WSDL (Web Service Description Language)描述服务；使用UDD I(Universal Description,Discovery and Integration)统一描述、发现和集成协议）来发布和查找服务；SOAP（Simple Object Access Protocol简单对象访问协议）则用来执行服务调用。Web Service体系结构的各个模块之间以及模块内部消息以XML格式传递。

 

3.3 Web Service涉及的技术

XML

Web Service的所有协议都建立在可扩展标记语言XML基础上的，XML 可称为Web Service 的基石。XML能增加结构和语义信息，能在结构层次和语义层次上进行进行索引。无论客户端还是服务器都能即时处理多种形式的信息，当客户端向服务器发出请求时，服务器只需将数据封装进XML文件中由用户根据自己的需求选择不同的应用程序来处理数据；这不仅减轻了Web 服务器的许多负担，也大大减少了网络流量。XML使用XML Schema作为建模语言。XML Schema具有丰富的数据类型，使用了和XML完全一致的语法，并引入了命名空间的概念。XML Schema 规范实现了W3C 推荐标准提供了一种可替代DTD （Document　Type Definition 文档类型定义）的方法，使开发人员能够更精确地结构化XML数据，XML Schema 已成为Web Service 中协议制定的标准语言。

 SOAP

SOAP 是一个基于XML 的在松散分布式环境中交换结构化信息的轻量级协议包括四个部分:

SOAP 信封(Envelop) 它构造定义了一个整体的表示框架可用来表示在消息中的内容是什么? 谁应当处理它? 以及是可选的还是强制的SOAP消息的结构。SOAP 信封包括一个SOAP 头(Header) 和一个SOAP 体(Body), SOAP 头是可选的它的作用是在松散环境下且通信方之间尚未达成一致的情况下扩展SOAP 消息的描述能力。SOAP体是必需的它包含需要传输给接收者的具体信息内容。

SOAP 编码规则(Encoding rules) 是一个定义传输数据类型的通用数据类型系统，这个简单类型系统包括了程序语言、数据库和半结构数据中不同类型系统的公共特性。在这个系统中，一个类型是一个简单类型或是一个复合类型。复合类型由多个部分组成，每个部分也是一个简单类型或复合类型。SOAP 规范只定义了有限的编码规则，当用户需要使用自己的数据类型时可以使用自定义的编码规则，按需求扩展该基本定义。

SOAP RPC 表示(RPC Representation)定义了远程过程调用和应答的协定。R P C 的调用和响应都在SOAP Body元素中传送。在RPC中使用SOAP时，需要绑定一种协议，可以使用各种网络协议如HTTP 、SMTP、 FTP 等来实现基于SOAP 的RPC。一般使用HTTP 来作为SOAP 协议绑定。SOAP 通过协议绑定来传送目标对象的URI，在HTTP 中的请求URI 就是需要调用的目标SOAP 节点的URI。

SOAP绑定（Binding），定义了一个使用底层传输协议来完成在节点间交换SOAP 信封的约定。目前SOAP 协议中定义了与HTTP 的绑定。利用HTTP来传送SOAP 消息，主要是利用HTTP 的请求/ 响应消息模型，将SOAP 请求的参数放在HTTP 请求里，将SOAP 响应的参数放在HTTP 响应里。当需要将SOAP消息体包含在HTTP 消息中时，HTTP 应用程序必须指明使用text/xml 作为媒体类型。

虽然这四个部分是作为SOAP 的不同部分作为一个整体定义的，但他们在功能上相交，彼此独立。特别的信封和编码规则被定义在不同的XML命名空间中，这样有利于通过模块化使得定义和实现更加简单。SOAP 基于XML，本身并没有定义任何编程模型和应用语义，只是定义了一个消息结构的框架，其具有良好的可扩展性。SOAP 消息结构框架扩展的一个特别类型是MEP( Message Exchange Pattern 消息交换模式),SOAP MEP 是一个在SOAP 节点间信息交换模式的样板，以提高对上层应用的有力支持。

SOAP的设计目标是简单性和可扩展性，所以SOAP 是一个轻型协议，一些传统消息系统或分布式对象系统中的某些性质将不是SOAP 规范的一部分。比如SOAP 没有定义有关分布式垃圾收集、成批传送消息对象引用和对象激活等方面的内容。

 WSDL

WSDL 是一种XML格式，用于将网络服务描述为一组端点，这些端点对包含面向文档或面向过程信息的消息进行操作。这种格式首先对操作和消息进行抽象描述，然后将其绑定到具体的网络协议和消息格式上以定义端点。相关的具体端点即组合成为抽象端点（服务）。WSDL是可扩展的，使得无论通信时使用何种消息格式或网络协议都可以对端点及其消息进行描述。WSDL 文档将服务定义为网络端点或端口的集合。在WSDL中，端点和消息的抽象定义从具体的网络部署或数据格式绑定中分离出来，这样就可以再次使用抽象定义。消息指对交换数据的抽象描述，端口类型指操作的抽象集合。用于特定端口类型的具体协议和数据格式规范构成了可以再次使用的绑定。将网络地址与可再次使用的绑定相关联可以定义一个端口，端口的集合则定义为服务。WSDL 文档在网络服务的定义中使用以下元素：

Types:types元素包含与交换的消息相关的数据类型定义。为了获得最大程度的互操作性和平台中立性，WSDL 选用XSD 作为标准类型系统，并将其当作固有类型系统。WSDL 允许通过扩展性元素来添加类型系统。扩展性元素可能出现在types 元素之下，标识正在使用的类型定义系统并为类型定义提供XML 容器元素。该元素的作用与XML Schema 语言的schema 元素的作用相似。

Message:它代表所传输数据的抽象定义。消息由一个或多个逻辑片段构成，每个片段使用一个消息类型属性与某个类型系统的类型相关联，消息类型属性的集合是可扩展的。如果使用的名称空间与WSDL 所用的名称空间不同，还可以定义其它消息类型属性来绑定扩展性元素，也可以使用消息类型属性。

Operation：对服务所支持的操作的抽象描述。

 Port Type:一组指定的抽象操作和有关的抽象消息。WSDL 提供四个可得到端点支持的传输原语,即：

1.单向（One-way）： 端点接收消息。

        2.请求响应（Request-response）: 端点接收消息和发送相关消息。

        3.要求响应（Solicit-response）: 端点发送消息和接收相关消息。

4.通知(Notification): 端点发送消息。

Binding:为特定portType 所定义的操作和消息指定消息格式和协议细节。对于某个给定的portType，可能有多个绑定。绑定必须明确指定一个协议，不能指定地址信息。

Port:通过为绑定指定一个地址来定义一个端口。一个端口不能指定多个地址，它不能指定除地址信息之外的任何绑定信息。

 Service 相关端点的集合。服务中的端口具有如下关系：所有端口都不相互通信；如果一个服务中有几个端口属于同一端口类型，但是使用了不同的绑定或地址，则这些端口是可以互相替换的端口。每个端口根据每个绑定所规定的传输限制和消息格式限制提供在语义上等价的行为。通过检查端口可以确定服务的端口类型，从而使WSDL 文档的使用者可以根据所支持的端口类型来确定是否要与特定的服务通信。

 UDDI

UDDI 基于现成的标准，比如：XML和SOAP，是一套基于Web的、分布式的、为Web 服务提供的信息注册中心的实现标准和规范，同时也包含一组使企业能将自身提供的Web 服务注册以使得别的企业能够发现的访问协议的实现标准。UDDI 注册中心是对所有提供公共UDDI注册服务站点的统称。UDDI注册中心是一个逻辑上的统一体，在物理上则以分布式系统的架构实施；不同站点之间采用P2P (对等网络)结构实现，因此访问其中任意一个站点就基本等于访问了UDDI 注册中心。UDDI注册中心提供的信息分成三组。白页：包括地址联系方式和已知的企业标识；黄页：包括基于标准分类法的行业类别；绿页：包括关于商业实体所提供的服务技术信息，包括Web 服务规范的引，用也支持指向基于发现机制的不同文件和URL 的指针。

UDDI XML Schema 定义了四种主要信息类型，它们是技术人员在需要使用合作伙伴所提供的Web 服务时必须了解的技术信息。这些元素构成UDDI信息结构，它们是：服务信息（business Service 结构）、商业实体信息（business Entity 结构）、绑定信息（binding Template 结构）和技术规范信息（tModel）。

3.4 Web Service应用

 

  3.4.1 数据服务应用

       Web Service是一个崭新的面向服务的分布式计算模型，是一种Web 上数据和信息集成的有效机制，Web Service在各个领域具有巨大的应用潜力和市场。

（1）互联网应用构架结构(B/S 结构)

 

 

图3.4.1  互联网应用构架结构(B/S 结构)

 

如上图所示，互联网应用构架特点如下：

① 对外服务的所有数据存放在数据库系统里进行维护和管理；

② 用户借助浏览器（IE）通过网络（HTTP）向应用服务器发送请求（Get/Post），该请求一般为宜URL；

③ 应用服务器接到用户请求转换成SQL/CQL等向数据库服务器发送请求，一般情况下数据库服务器和应用服务器通过TCP/IP协议链接；

④ 数据库服务器接到SQL/CQL请求，并进行处理，将处理后的结果集返回应用服务器；

⑤ 应用服务器将数据库服务器返回的结果集按OprnURL的参数要求处理成HTML返回用户。

这种B/S结构的服务称之为传统的Web服务。这种服务是一种功能式服务，用户向应用服务器发出请求只能获得特定的服务，比如：检索服务，而其得到的检索结果只能浏览。

（2）基于Web Service的服务体系结构

                                             基于Web Service的服务体系结构

 

    基于Web Service的服务体系功能如下：

① SOAP服务器所提供的接口，可以通过注册中心获得，也可在系统内部值得获得；

② 用户在知道SOAP服务器所提供的接口情况下，通过常规SOAP客户端程序直接调用所需的SOAP接口（通过SOAP服务器URI、接口名称、参数等）；

③ SOAP接到用户请求，根据请求的接口名称、参数等信息情况并转化成相应的SQL并传递到后台数据库服务器；

④ 后台服务器接到请求，生成相应的结果集并传递到SOAP服务器；

⑤ SOAP服务器接到结果集，先生成相应的XML格式数据，然后返回到用户端（SOAP客户端）；

⑥ SOAP客户端接到SOAP返回的结果，可根据自己需要处理所获得的XML信息集。

和传统的Web服务相比，基于Web service的服务系统具有如下特点：

① 用户可以通过标准SOAP客户端获取SOAP服务接口，并可调用；

② 用户获得的数据是XML格式数据，用户可利用一些标准XML工具处理这些数据，就像使用本地数据一样；

③ 理论上讲，客户通过Web Service可以使用服务商的数据库系统和数据，就像使用自己的一样；

④ 当然，Web Service是需要授权认证的。

和传统Web服务相比，基于Web Service的服务称为数据服务（作者命名）。

3.4.2 Web Service与整合应用

如果信息服务商或内容服务商所提供的接口为符合某种标准的SOAP整合接口，那么数据整合将变得更加规范内和高效。如果所有接口都符合SRW标准，数据整合的结构如下图所示：

 

 

图3.4.2.1  数据整合的结构

 

在基于Web Service（SRW）的Provider 体系结构中：

（1）整合服务器或内容收割者向SRW服务器发出获取信息的请求(基于CQL的SOAP请求)；

（2）信息服务商或内容提供商将请求经过处理转换成SQL向数据库服务器发出请求，或转换成PQF (Prefix Query Format Z39.50服务器使用的一种查询语言)；

（3）数据库服务器或Z39.50服务器将查询结果返回给SRW服务器；

（4）SRW服务器将数据库服务器或Z39.50服务器返回的结果转换成XML格式的DC或MARC数据，并返回给信息请求者。

 

                     图3.4.2.2 基于Web Service （SRW）的系统整合示意图

 

如上图所示，基于SRW的数据整合系统流程为：

① 用户通过统一检索界面（可选择信息服务商）向整合服务器发出请求；

② 整合服务器根据用户请求和指定的信息服务商（也可以是缺省的信息服务商），首先将用户的检索请求转换成CQL,然后封装成SOAP请求，分发到不同的信息服务商；

③ 信息服务商将数据整合服务的请求进行处理，处理后返回符合SRW标准的XML数据包；

④ 整合服务器将各信息服务商返回的结果，按照指定的规则进行、合并、分类、排序等处理，然后将结果返回最终用户。

从上面的分析可以得出结论：如果各信息服务上商能够提供RSW服务，系统整合将变得非常简单和高效。随着SRW服务的不断推广和普及，上述整合服务模式必将成为信息服务界的主要整合服务模式。

 

3.4.3 Web Service 与分布式数据服务

从前面关于WebService的介绍，可以看出基于Web Service的信息服务体系的规范化可分布的技术特点，目前人们构建分布式服务/计算系统所采用的应用服务器一般为SOAP服务器。基于Web Service的分布式体系结构如下图所示。

目前国际上采用的分布式数据服务的体系结构如下：

 

 

 图3.4.3.1 基于Web Service的分布式数据服务体系结构

 

 

下面对上述分布式数据服务体系结构原理做简单介绍。

① 基于Web Service 的数据服务系统对外提供针对数据的符合SOAP接口标准的数据服务，比如：采用SRW标准，对于一个内部服务体系而言也可以定义自己的SOAP服务标准；

② 智能检索网关它首先是SOAP服务器的一个客户端，对用户而言也是一个应用服务器（Application Server）。检索网关负责生成基于分布式结构的检索网页，接受用户的检索请求，根据各SOAP服务器的数据库配置情况和繁忙情况确定检索策略，决定向那些数据发出请求。请求的格式根据SOAP服务器采用的标准而定；

③ 检索网关将各SOAP服务器返回的结果进行处理，生成用户所需要的格式并返回用户。

 

目前万方数据资源整合服务系统无论从资源整合还是资源服务方面都是基于Web Service技术来构架的。

 

 

服务申请者

转载本文请联系原作者获取授权，同时请注明本文来自吴广印科学网博客。
链接地址：https://blog.sciencenet.cn/blog-467639-352007.html

上一篇：RMS数据库基础之ISO-2709格式
下一篇：跨系统整合服务接口标准及其应用