基于Pastry平台的Web服务组合系统框架研究

摘 要：本文针对集中式Web服务组合系统，提出了一种基于Pastry结构的分布式服务组合系统框架。希望本文的研究能为相关理论的研究带了一定的启示和作用。

关键词：Pastry结构；Web；服务组合

中图分类号：TP311.52

Web服务组合系统负责整个服务组合过程，需要完成包括服务注册、查找、选择和协调执行等在内各个阶段的功能。系统框架的不同构建方式会直接关系到系统内各功能的具体实现，即直接影响到服务组合系统的性能，执行的效率。Web服务具有独立、自治的特性，随着Internet上服务数量的增多，而且其中包含大量功能相似、非功能特性各异的服务，同时它们又运行在动态性极强的Internet之上，这些都为 Web服务组合系统的构建提出了新的要求。

本文的服务组合系统ServiceStore建立在Pastry系统上，利用DHT的特性将具有相同功能的Web服务归类成为一个服务社区（Service Community）。为了便于描述，本小节首先介绍服务组合的基本术语。

1 服务组合的基本术语

抽象组合方案（Abstract Composition Plan）是用来描述组合服务的实现逻辑，定义组件服务之间的协同关系。一般情况下，抽象组合方案不指定具体的组件服务，而只是定义组件服务的功能需求来抽象参与者。

组合方案（Composition Plan）是指组合服务模型中定义的参与者到具体组件服务的一次映射。由于抽象组合方案中不指定组件服务的具体提供者，因此在组合服务执行时之前，运行环境根据抽象组合方案及用户需求来绑定具体的组件服务，即为组合中的每个参与者指派一个具体的组件服务，从而完成组合方案的确立过程。

组合服务实例（Composite Service Instance）标识了特定用户组合方案的一次运行，组合服务系统需要维护与特定用户相关的执行状态和数据。

2 基于Pastry的服务组合系统框架

本文提出的服务组合系统框架 ServiceStore 建立在Pastry平台之上，首先对Pastry网络做简单的介绍。

Pastry 是一个可扩展的分布式对象定位和路由协议，可用于构建大规模的P2P系统。在Pastry中，每个节点分配一个128位的节点标识（nodeID），所有的节点标识形成了一个环形的nodeID空间，范围从0到2128-1，节点加入系统时通过散列节点IP地址在128位nodeID空间中随机分配。每个节点维护一个路由表（Routing Table），一个邻居节点集（Neighborhood Set）和一个叶子节点集（Leaf Set），它们一起构成了节点的状态表。Pastry路由表是一个分层的结构，共有logNB（B=2b）行，每行包括B-1个表项。第n行存储的节点标识与本地节点标识的前n-1位相同，且第n位与本地节点不相同。b的取值需要权衡路由表所占的存储空间和任意节点间的路由效率，通常取3或4。叶子节点集的容量为L，维护的是数值上距离本地节点标识最近的节点，即逻辑地址上的相邻节点。其中前|L|/2个节点的标识大于本地节点，后|L|/2个节点的标识小于本地节点，叶子节点集用于保证路由的正确性。邻居集中包含|M|个在实际的物理层与本地节点邻近的节点，其作用是增强 Pastry 的局部性，路由过程通常不使用邻居节点集。|L|和|M|的典型取值为2b或2×2b。

Pastry采用了成熟的最大前缀匹配的路由算法。通常被查询的键值，即对象ID，会保存在路由查询消息中。当收到路由消息时，节点首先检查该键值是否络在本地的叶子节点集的范围内。如果是，则直接把消息转发到距离消息键值最近的节点（包括相等，即它就是实际的目的节点）；否则，就根据最长前缀优先的原则，从路由表中选择一个前缀至少多匹配一位的节点，转发路由消息。但在某些情况下，也会出现路由表项空缺或者不可达的情况，此时没有办法匹配更多位，所以消息被路由到匹配前缀相同并且与目的节点更接近的表项。除非消息已经到达距离目的节点最近的节点，否则这样的节点一定位于叶子节点集中。而且，只要叶子节点集中一半以上的节点不同时失效，就一定可以找到满足要求的节点。

能支持大范围的Web服务组合，它的核心是由大量互相链接的Web服务器节点共同组成，每个节点运行一个组合管理器，负责管理本节点上部署的服务、解释流程模型、管理流程实例、调度本节点上的服务操作，节点之间可以直接交换执行状态和业务数据。它们构成了一个服务覆盖网（Service Overlay）。网络中的每个节点都可以发起一个组合服务请求，成为组合服务的提供者，同时也可以作为参与者参与其它节点所发起的组合服务。用户以付费的方式来享受Web服务（或组合服务）。

3 ServiceStore 系统的服务组合过程

虽然实现服务组合有多种不同方法，但是其实施过程均可以划分为抽象组合方案建立（Build Time）与组合方案实际运行（Run Time）两个阶段。本文研究的基于业务流程的服务组合，抽象组合方案是在Build Time确定，但在Run Time不可修改；而组合方案是在Run Time 确定，也可在Run Time修改。

本文将服务组合实施过程分为需求分析、建立和执行3个阶段。

在需求分析阶段，本文采用的基于业务流程的服务组合是依赖于现有的过程模板来建立组合服务模型，服务组合系统依据用户的功能需求和组合服务模板库，获得由一组活动组成的抽象组合方案。

在建立阶段，抽象组合方案中的基本功能经过服务发现与选择被实际化为服务空间中具体的组件服务，从而建立组合方案。根据抽象组合方案中包含的服务功能来发现服务，发现满足相应功能需求的一类服务，然后根据用户请求中传达的非功能需求，按照特定的服务选择策略进行服务选择，建立组合方案。由于服务组合的动态性，即使对于相同的抽象组合方案，组合方案在不同时刻包含的具体组件服务也会不同。

执行阶段，服务组合系统根据组合方案中组件服务之间的调度关系，建立相应组件服务的实例，协调实例之间的控制和数据的传递。

一个完整的Web服务组合系统要能够完成服务组合生命周期的所有活动，包括服务注册、服务发现、服务选择、服务组合、执行和监控等过程。本节将结合上述实施过程详细讲述ServiceStore 对服务组合生命周期过程的支持。

3.1 Web服务的与注册

与Pastry中节点加入系统的过程类似，服务节点N在加入ServiceStore 时，系统利用哈希算法（SHA-1）将它的IP地址映射为一个全系统唯一的124位的nodeID，在接下来的功能实现中所涉及的消息路由，均调用Pastry的最长前缀优先方法（route函数）。然后，该节点Web服务s，利用哈希算法将服务功能（如天气预报，股票查询）映射为一个160位Func_ID值，然后调用Pastry的函数把服务s的注册信息作为资源（如图2-8所示）路由到距离该Func_ID值最近的服务节点，完成服务的注册，这个节点便成为社区的节点。可以看出，具有相同功能的Web服务会由哈希函数得到相同的Func_ID而注册到同一个社区。社区节点维护着社区服务表，表中的一行数据对应着一个Web服务的基本信息和最近的表现（服务质量）。Web服务所对应表项的具体内容，包括Web服务的基本信息和服务质量信息。IP地址是Web服务节点的地址，它作为区分不同表项的标识；为了体现出Web服务信息的动态性，我们增加了最后更新时间，用它来表示该表项的最后更新时间。灰色填充的部分在表项中固定不变，无填充的部分表示Web服务最近的服务质量，会随着 Web 服务运行时状态的变化而改变。

服务节点注册服务时发送的消息结构，每个资源数据包由资源id和资源组成。其中资源id为经过哈希函数运算得到的Func_ID，功能相同的Web服务具有相同的资源id。的资源由IP地址和子消息组成。IP地址用来区分提供相同功能的不同服务节点。子消息包括消息类型和消息体，不同的消息类型所对应的消息体内容是不同的。在服务注册时，发送的是REGISTER类型的消息，消息体由Web服务基本信息和服务质量信息组成。

3.2 Web服务发现与选择

（1）服务发现。服务发现阶段的任务是分析用户提出的功能需求，可以借助人工智能规划（AIPlanning）技术，获得单个或多个由基本功能组成的组合服务流程，再从服务覆盖网上找到这些基本功能所对应的Web服务。在这篇论文中，我们采用基于业务流程的服务组合方法，根据流程模型库中提供的模板，获得抽象组合方案。根据方案中包含的基本功能，计算每个基本功能F的Func_ID值，然后调用Pastry系统将服务请求发送到距离Func_ID最近的节点。由于采用与服务注册阶段相同的哈希函数，所以接收到服务请求的节点即为保存服务注册信息的节点，该节点保存着所有提供基本功能F的Web服务信息。

（2）服务选择。社区节点运行服务选择算法，从所有已注册的服务中选出满足用户非功能需求的服务，并将选择结果发送到组合服务节点。服务选择算法的输入为所有参与选择的Web服务QoS信息。文献的服务选择方法直接使用服务供应商提供的服务质量，但是在商业利益的驱动下，服务供应商很可能为了吸引客户而公布高于真实情况的服务质量，真实性难以保证。而且，Web服务在运行时又具有动态性的特征（网络和服务节点状态的不稳定），所以，单凭供应商公布的静态服务质量难以满足要求。ServieStore通过引入监测机制，来收集服务社区中服务的QoS信息，实现对服务供应商的评价，监督它们在Web服务市场的行为。

3.3 Web组合服务的分布协调执行

在集中模式下，组合服务执行过程中的控制流（服务调用）和数据流都需要经过中心服务器来转发，间接的路由增加了消息的数量，会给中心服务器和网络带来额外的负担，也延长了组合服务的执行时间。对于某些自治性比较高的应用还会带来潜在的安全问题，应用范围受到了限制。已有研究表明，分布协调方式在系统性能上要优于集中协调方式，所以，在ServiceStore中组合服务采用分布协调运行方式。

文献提出了基于角色的分布式协调机制，将组合服务的执行过程理解为多个角色之间的协调过程，力图将全局流程模型转化为由各个角色独立执行的本地流程模型，因为这样可以尽量减少对原有执行引擎的改动，达到在集中协调机制的运行环境中透明地实现分布协调。文献使用I/O自动机来表示Web服务和服务组合目标，为了减小分布式服务编排所消耗的网络和计算代价，给出了计算自动机代价的算法，实现了由集中式方案向最优化分布式方案的转化。ServiceStore在组合服务的分布式协调机制的设计与实现将作为未来的研究工作。

4 小结

本文分析了服务组合的基本术语，基于Pastry的服务组合系统框架，对ServiceStore系统的服务组合过程进行了系统的分析。该系统具有良好的可伸缩性，可适应上万数量级的服务节点，且定位服务迅速（log（n）跳数内）；采用并行的服务选择方法后，能够明显地缩短了生成组合服务方案的时间，提高了服务组合请求的响应效率。

参考文献：

[1]邓水光，吴健，李莹，吴朝晖.基于回溯树的Web服务自动组合[J].软件学报，2007，18（8）：1896-1910.

[2]汤宪飞，蒋昌俊，丁志军，王成.基于Petri网的语义Web服务自动组合方法[J].软件学报，2007，18（12）：2991-3000.

[3]葛声，马殿富，胡春明.基于Web服务的网络软件运行平台研究与实现[J].北京航空航天大学学报，2012，29（10）：897-900.

[4]杜宗霞，怀进鹏，王勇.组合Web Service支撑系统的研究与实现[J].北京航空航天大学学报，2012，29（10）：889-892.

[5]金海，陈汉华，吕志鹏，宁小敏.CGSP作业管理器合成服务的QoS优化模型及求解[J].计算机学报，2012，28（4）：578-588.

作者简介：王晓军（1973.3-），男，讲师，学历本科。

作者单位：达州广播电视大学，四川达州 635000