背景技术
web服务技术是为解决网络应用集成问题而提出来的,使得应用程序可以用与平台和编程语言无关的方式进行相互通信的一项技术。Web服务为实现“软件作为服务”提供了技术保障,它实质上是一种通过在网络上暴露可编程接口来共享软件服务的机制。具体来说,它描述了一组可以在网络上通过标准化的可扩展标记语言消息传递访问的操作,使用基于XML语言的协议来描述所要执行的操作或者所要与另一个Web服务交换的数据。Web服务的注册与发现是使用Web服务的前提。简单地说,所谓Web服务的注册是指服务提供者发布所能提供的Web服务并将该服务登记到注册中心,所谓服务发现是指注册中心根据服务使用者的查询请求查找满足条件的Web服务。
对Web服务的功能描述可以分为黑盒式描述和白盒式描述。前者把Web服务看成一个原子的、不可分解的流程,也称原子服务,它对外暴露的只有它的输入和输出接口;后者把Web服务看成是由一组原子操作构成的、包含复杂业务逻辑流程的服务,也称流程式服务,它对外暴露的不仅是接口,还有消息的传递、状态的转移等一系列行为规则。
相应地,对Web服务的功能性需求可以分为接口匹配需求和行为匹配需求。针对原子服务的接口匹配需求,通常认为一个服务能在接口上匹配一个请求(接口匹配:Interface/Signature Matching),当且仅当请求的所有输出能被服务的输出所满足,并且服务的所有输入能被请求的输入所满足。而针对流程式服务能的行为匹配需求,通常认为一个服务能在行为上匹配一个请求(行为匹配:Behavior/Protocol Matching),必须满足:①流程服务包涵所有原子服务在功能上能够涵盖请求的所有子功能;②流程服务包涵的所有原子服务在调用顺序上不会违背服务请求需要的行为。
事实上,原子服务也是一种特殊的流程式服务,它是只含有一个操作的流程,而针对原子服务的接口匹配也是一种特殊的行为匹配,由于单一操作构成的流程不存在操作间调用顺序上的问题,所以只需要考虑该原子操作的接口匹配问题。另一方面,行为匹配包含对流程式服务中的原子服务的接口匹配,因此我们把服务统一为流程式服务,把对服务的功能性需求统一为行为匹配。
服务注册中心作为Web服务信息的管理机构,一方面负责接收服务提供者对于服务信息的注册,另一方面负责处理服务请求者的查询请求并定位出满足请求的服务列表。然而目前的服务注册,通常只是搜集服务提供者信息、服务名称和服务接口、流程描述文档等信息,却没有对注册中心的所有服务信息做任何形式的处理和优化管理;而服务发现通常是通过顺序扫描服务库中所有注册服务的方式来实现的,即顺序查找。当执行服务查询时,所有注册服务逐一地与服务请求进行行为上的匹配比较。这种方法相对直观、容易实现,但是当服务库中的服务数量达到一定数量级别的时候,这种方法的效率就会成为制约算法性能的瓶颈问题。可以看出,该服务发现方法没有合理地管理利用服务注册信息,很多时间浪费在匹配比较一些毫不相关的服务上,效率低下。
倒排索引是一种面向单词的索引机制,它源于实际应用中需要根据属性的值来查找记录,利用它可以提高检索时的速度。通常情况下,这种索引表中的每一项都包括一个属性值和具有该属性值的各记录的地址。由于不是由记录来确定属性值,而是由属性值来确定记录的位置,因而称为倒排索引(inverted index)。正常的索引结构建立的是文档到单词的映射关系,倒排索引结构建立的是单词到文档的映射关系。由于服务匹配通常从检查服务是否满足输出上的要求开始,倒排索引能够快速定位候选服务,从而更好地适应这种发现机制。
发明内容
本发明要解决上述技术所存在的缺陷,提供一种流程式服务的注册与发现方法。这种基于倒排索引的Web服务注册与发现方法,其目的在于合理地优化管理流程式服务注册信息,对其建立倒排索引,并有效地利用该索引提高流程式服务发现的效率。
本发明解决其技术问题所采用的技术方案:本发明提供了一种基于倒排索引的流程式服务注册与发现方法,在接收到来自服务提供者提交的Web服务注册请求时,将该注册请求中的服务信息在服务注册中心进行常规注册;在Web服务注册成功后,解析该注册服务的接口、流程描述文档,提取出流程ID、流程包含的原子操作、原子操作包含的输入/输出消息等信息,建立消息到操作和操作到流程的倒排索引;在接收到来自服务请求者提交的查询请求时,服务注册中心将该请求分解成消息索引、操作索引查询请求发送给索引信息中心,在接收到来自索引信息中心返回的分解索引查询结果之后,对索引查询结果做合并处理,根据消息到操作的索引信息,快速确定需要包含的原子操作,再根据操作到流程的索引信息,快速定位包含这些原子操作并满足操作间调用顺序的流程式服务,将筛选出的满足请求的流程式服务的列表返回给用户。
本发明有益的效果是:首先,本发明将所有的服务表示为流程式服务,将服务匹配规则定为行为匹配,在服务注册中心注册更详细的服务信息,使用更精确的需求匹配规则,能够满足更复杂的用户请求。其次,本发明针对服务注册中心的流程式服务信息进行了优化管理,对所有信息建立了从消息到操作和从操作到服务的倒排索引,并有效地利用了该索引提高流程式服务发现的效率。再次,由于web服务索引信息的建立和更新等操作都是在索引信息中心中实现,索引信息中心是可插拔、可扩展的,可以按照实际情况建立不同的索引对服务库进行查询优化。
具体实施方式
下面结合附图和实施例对本发明作进一步介绍:
本发明提供了一种基于倒排索引的流程式服务注册与发现方法,包括:在接收到来自服务提供者提交的Web服务注册请求时,将该注册请求中的服务信息在服务注册中心进行常规注册;在Web服务注册成功后,解析该注册服务的接口、流程描述文档,提取出流程ID、流程包含的原子操作、原子操作包含的输入/输出消息等信息,建立消息到操作和操作到流程的倒排索引;在接收到来自服务请求者提交的查询请求时,服务注册中心将该请求分解成消息索引、操作索引查询请求发送给索引信息中心,在接收到来自索引信息中心返回的分解索引查询结果之后,对索引查询结果做合并处理,根据消息到操作的索引信息,快速确定需要包含的原子操作,再根据操作到流程的索引信息,快速定位包含这些原子操作并满足操作间调用顺序的流程式服务,将筛选出的满足请求的流程式服务的列表返回给用户。
本发明提供了一种基于倒排索引的流程式服务注册与发现系统,包括:服务注册中心和索引信息中心。
服务注册中心进一步包括服务注册模块和服务发现模块。服务注册模块,用于在接收到来自服务提供者提交的Web服务注册请求时,进行Web服务常规注册,登记服务提供者信息、服务名称和服务接口、流程描述文档等信息,返回注册成功后该Web服务的标识符ID,在Web服务注册成功后,将服务注册信息传递给索引信息中心,通知索引信息中心更新倒排索引;服务发现模块用于在接收到来自服务请求者提交的查询请求时,将该请求分解成消息索引、操作索引查询请求发送给索引信息中心,在接收到来自索引信息中心返回的分解索引查询结果之后,对索引查询结果做合并处理,根据消息到操作的索引信息,快速确定需要包含的原子操作,再根据操作到流程的索引信息,快速定位包含这些原子操作并满足操作间调用顺序的流程式服务,将筛选出的满足请求的流程式服务的列表返回给用户。
索引信息中心进一步包括索引更新模块和索引查询模块。索引更新模块,用于在接收到来自服务注册中心的索引更新通知时,解析该注册服务的接口、流程描述文档,提取出流程ID、流程包含的原子操作、原子操作包含的输入/输出消息等信息,建立消息到操作和操作到流程的倒排索引;索引查询模块,用于在接收到来自服务注册中心的索引查询请求时,查询消息到操作和操作到流程的倒排索引信息,将分解查询结果返回给服务注册中心的服务发现模块做进一步处理。
索引更新模块中,消息到操作的索引信息由两部分组成:操作的输出消息作为键,服务注册中心所有能产生该输出的操作(服务)列表作为键值;操作到流程服务的索引信息也由两部分组成:具有特定功能的操作作为键,服务注册中心所有包含该操作的流程式服务作为键值,键值中的每个元素由<流程式服务标识,操作在该流程式服务中的调用顺序>组成。
索引更新模块支持的操作包括:对于一组消息->操作(或者操作-><流程,序号>),如果该键的索引记录在索引信息中心中不存在,生成该索引键,并将该操作(或<流程,序号>)作为它对应的操作列表(或服务列表)的第一个成员插入;否则,将该操作(或<流程,序号>)直接添加到该索引键对应的操作列表(或服务列表)的末端。索引查询模块支持的操作包括:根据消息索引键,得到服务注册中心所有能产生该输出的操作(服务)列表;根据操作索引键,得到服务注册中心所有包含该操作的流程式服务列表。
如图4所示的Web服务是一个售货服务,它包括六个原子操作:查询操作(Query),根据输入的货品名称(ItemName),返回库存信息(Storage-Info);订单操作(Order),根据输入的货品信息(ItemInfo)如货品名称和订购数量等,返回订购总价(Total-Price);付款通知操作(Payment-Notify),输出付款通知;通过BOC银行付款操作(Pay through BOC),在输入BOC银行卡号相关信息之后,返回付款状态;通过CCB银行付款操作(Pay through CCB),在输入CCB银行卡号相关信息之后,返回付款状态;发货确认操作(Affirm Delivery),在输出发货通知之后,返回收据确认消息。该服务各操作间的逻辑关系是:用户在开始与售货服务交互之后,可以先进行查询操作来查询某个特定商品的库存信息等,也可以跳过查询操作直接进行订单操作,确定需要购买的商品及数量。然后该服务会执行付款通知操作,用户在收到该通知后,可以选择通过CCB银行付款操作或者BOC银行付款操作来支付。在收到款项之后,该服务会处理送货并提醒用户货品已经送出,在用户返回收据确认消息之后,用户与该服务的交互结束。
当如图4所示的Web服务注册到服务注册中心时:
如图2.2所示步骤,首先进行常规信息注册,包括服务提供者、服务接口、流程描述文档等信息登记到服务注册中心;
如图2.3所示步骤,服务注册中心将服务注册标识(如ID:purchase A)返回给服务提供者;
如图2.4所示步骤,更新消息到操作索引表:storage-Info对应的操作列表增加Query操作;Total-price对应的操作列表增加order操作;payment-notification对应的操作列表增加Payment-Notify操作;Payment-State对应的操作列表增加Pay through BOC和Pay through CCB操作;Delivery-Notification对应的操作列表增加Affirm Delivery操作。并且更新操作到服务索引表:Query对应的服务列表增加<purchase_A,1>;Order对应的服务列表增加<purchase_A,2或1>;Payment-Notify对应的服务列表增加<purchase_A,3或2>;Pay through BOC对应的服务列表增加<purchase_A,4或3>;Pay through CCB对应的服务列表增加<purchase_A,4或3>;Affirm Delivery对应的服务列表增加<purchase_A,5或4>。索引更新完毕。
服务注册流程结束。
假设有另一个售货服务purchase_B,它只有订单、送货、通过BOC付款三个操作,操作的接口与purchase_A相应的操作一致,该服务的执行流程是订单-送货-通过BOC付款,那么该服务注册进入服务注册中心后,需要更新的索引包括:消息到操作索引表,无;操作到服务索引表,Order对应的服务列表增加<purchase_B,1>;Affirm Delivery对应的服务列表增加<purchase_B,2>;Pay through BOC对应的服务列表增加<purchase_B,3>。
假设服务注册中心接收到一个服务查询请求,该请求提出所需的服务必须包涵以下两个操作:操作A可以提供BOC银行卡号相关信息,需要返回付款状态(Payment-State);操作B需要发出发货通知(Delivery-Notification),等待接收收据确认消息。另外,该请求提出操作A先于操作B。
根据消息到操作索引表,由于可以输出Payment-State消息的操作有Pay through BOC和Pay through CCB操作,而请求可以提供的输入是BOC银行卡号相关信息,从而确定操作A即Pay through BOC;而可以输出Delivery-Notification消息的操作是Affirm Delivery,从而确定操作B是Affirm Delivery。
根据操作到服务索引表,确定同时包涵Pay through BOC和Affirm Delivery的操作有purchase_A和purchase_B。
pay through BOC在purchase_A里的调用顺序是4或3,Affirm Delivery在purchase_A里的调用顺序是5或4,满足操作A先于操作B;而pay through BOC在purchase_B里的调用顺序是3,Affirm Delivery在purchase_B里的调用顺序是2,不满足操作A先于操作B。因此,可以快速定位到purchase_A是满足该服务请求的。
上述实施例用来解释说明本发明,而不是对本发明进行限制,在本发明的精神和权利要求的保护范围内,对本发明作出的任何修改和改变,都落入本发明的保护范围。