一种基于面向物联网应用的Web服务并发控制方法及系统

摘要

本发明提出的一种基于面向物联网应用的Web服务并发控制系统，该系统在SOAP Body内容解析模块之后增加并发控制模型来实现Web服务的并发控制，所述的并发控制系统，包含：两个线程池和一个并发控制模型，该并发控制模型包含：重复和冲突检测模块、优先级设定模块和执行模块；所述的重复和冲突检测模块包含：预处理子模块，重复检测子模块，过滤器子模块，和冲突监测子模块；所述的优先级设定模块包含：优先级设定子模块，用于对存在冲突的服务请求消息进行优先级排序；所述的执行模块包含：请求消息预处理子模块，用于对标记优先级的服务请求进行排序并分配线程；和寻址子模块其中，上述模块的所有操作基于在SOAPBody中定义了服务设备资源统一描述框架。

说明书

技术领域

本发明涉及Web服务并发控制方法，具体涉及一种基于面向物联网应用的Web服务并发控制方法及系统。。

背景技术

物联网(Internet of Things，IOT)是一个新兴的概念，是一种通过射频识别(RFID)、红外感应器、全球定位系统、激光扫描器等信息传感设备，把任何物品与互联网连接起来，进行信息交换和通讯，以实现智能化识别、定位、跟踪、监控和管理的网络。通过物联网的定义可以看出，其核心和基础仍然是互联网，不同的是将互联网连接的用户端扩展到物品和物品。因此，提供商提供的各种物联网应用服务，可以通过Internet进行部署以便客户端远程访问和调用执行，这将是物联网服务管理的一种必然发展趋势。

Web服务(Web Service，WS)是当前Internet上最主要的一种服务实现技术，它通过Web服务描述语言(WSDL)对各种软件应用程序进行描述和封装，进而利用统一资源标识符(URI)对封装后的软件应用程序进行标识定位，通过简单对象访问协议(SOAP)进行消息通信，最终实现跨越不同地域、不同行业的服务间互操作。

Web服务技术为Internet上的服务管理提供了有效的技术支撑。然而，面向具体的物联网应用，Web服务将特别呈现出以下两个新特点：

第一，物联网的服务将主要建立在各种传感设备之上，通过与底层传感设备的数据交互来实现特定的功能。例如，一个温度传感器就可以构建入侵检测和空调控制等多个服务。因此，随着接入Internet的传感设备种类和数量大大增加，物联网中的Web服务规模将远超于当前Internet上的服务规模，呈指数级增长趋势。

第二，由于底层传感设备的高度互联，物联网的服务依赖关系也将更加紧密。在这种情况下，同一个服务资源往往可能要被多个服务调用和操作。例如，在提供游客实时视频浏览的公园旅游场景下，摄像头就属于公共的服务资源。服务S₁可以提供查询摄像头是否空闲的服务，而服务S₂也可以提供对该摄像头的移动操作。

随着物联网的快速发展，Web服务中的资源共享程度大大增加，将对Web服务的并发控制提出新的机遇和挑战。Web服务发展了近十年，至今没有有效地并发控制研究，通过调研分析，可能有两个方面的原因。一方面，Web服务请求SOAP协议是建立在HTTP协议基础之上的，在资源冲突发生不频繁的情况下，仅依赖成熟的HTTP并发控制来解决Web服务的并发控制，是可以满足基本需求的。另一方面，Web服务是面向普适计算而提出的新理论，在缺乏具体应用需求驱动的背景下，面对复杂多样的服务表示及资源刻画，设计一个通用的并发控制方法是不切实际的。因此，在物联网领域，针对物联网的服务设备资源提出新的Web服务并发控制方法，可以说，既有强烈的需求驱动又有具体的实施目标，是物联网上成功开发Web服务不可避免的关键研究问题。

目前，Web服务请求主要采用IBM、Microsoft、UserLand和DevelopMentor在1998年共同提出，并于2000年提交给万维网联盟(W3C)的SOAP协议，当前的最新版本为SOAP1.2。SOAP是建立在XML语言基础上的一个轻量的协议，用以规范在一个分布式环境下进行结构化的信息交换。一条SOAP消息就是一个普通的XML文档，包含Envelope、Header、Body和Fault四个基本元素，通过HTTP进行承载(如图1所示)。对于搭载在HTTP上的Web服务请求，相应的并发控制机制如图2所示。

搭载Web服务请求的HTTP消息到达Web服务器后，线程池分配线程用以处理HTTP消息。首先经过HTTP解析得到搭载的SOAP消息，进一步进行XML解析，获得SOAP Body包含的服务请求内容，由相应的Web服务进行处理，经过上述相反过程对响应信息进行封装并返回给服务请求端。最后，线程释放该Web服务请求实例并放回线程池以循环执行Web服务请求。以上Web服务并发控制核心在于：线程池维护确定数量的等待线程，每当有Web服务请求到达，线程池就分配一个线程为请求服务。为了运行这些线程，处理器为每个独立线程安排一些处理器时间，处理器以顺序轮换方式向线程提供时间片，实现多线程的并发处理。线程池的优势在于服务器运行之初一次性创建多个线程并循环使用，将线程创建开销分摊到多个任务上，避免了频繁创建、销毁线程带来的巨大资源开销，以及创建过多的线程耗尽系统资源。

由图2可知，Web服务器在收到服务请求时即分配线程进行响应，而具体的服务请求内容是在经过HTTP及XML解析后获得。传统的Web服务并发控制方法缺陷就在于：线程的分配没有考虑HTTP消息中封装的服务请求内容，多个HTTP请求被分配独立的线程单独执行。如果当前的多个HTTP请求封装相同的服务请求或服务请求之间有冲突或执行优先级之分，有可能会造成线程浪费、资源冲突和错误的发生。仍然以上面提到的公园旅游场景为例，用户A将请求服务S₁来询问摄像头是否空闲，而用户B将请求服务S₂来移动摄像头查看景点。当用户A与用户B的请求同时到达时，目前的Web服务并发控制方法是分配两个独立线程并随机执行Web服务响应。但是，这两个服务请求是存在优先级之分的，用户B的请求应该优先用户A的请求执行，以避免用户A查询到摄像头空闲而请求操作时摄像头已被占用。

发明内容

本发明的目的在于，为克服传统的Web服务并发控制方法造成线程浪费、资源冲突和错误的发生等问题，从而提供一种基于面向物联网应用的Web服务并发控制方法及系统。

本发明的一种基于面向物联网应用的Web服务并发控制系统，该系统在SOAPBody内容解析模块之后增加并发控制模型来实现Web服务的并发控制，所述的并发控制系统，包含：两个线程池和一个并发控制模型，该并发控制模型包含：重复和冲突检测模块、优先级设定模块和执行模块；

所述的重复和冲突检测模块包含：预处理子模块，用于对解析的服务请求消息进行数学表示；重复检测子模块，用于对解析消息的数学表示进行重复性检测；过滤器子模块，用于过滤检测得到的重复的服务请求消息；和冲突监测子模块，将过滤后的所有服务请求消息进行再冲突性检测。所述的优先级设定模块包含：优先级设定子模块，用于对存在冲突的服务请求消息进行优先级排序。所述的执行模块包含：请求消息预处理子模块，用于对标记优先级的服务请求进行排序并分配线程；寻址子模块，使用该子模块通过消息发送模块执行服务请求。

其中，上述模块的所有操作基于在SOAP Body中定义了服务设备资源统一描述框架，该框架如下所示：

表1，服务设备资源属性定义

  属性名  说明  ResourceID  服务设备资源ID  ResourceType  服务设备资源类型  ResourceList  同属一个服务的设备资源列表  ResourceURL  设备资源所属服务的访问地址  OperationName  服务设备资源的操作名称  OperationType  服务设备资源的操作类型  OperationInput  服务设备资源操作的输入变量  OperationOutput  服务设备资源操作的输出变量

上述技术方案，所述的优先级设定模块还包含：当前场景获取子模块和规则子模块，用于为优先级设定子模块的优先级算法提供信息。

本发明还提供了一种基于面向物联网应用的Web服务并发控制方法，该方法利用一种基于面向物联网应用的Web服务并发控制系统，所述的并发控制系统，包含：两个线程池和一个并发控制模型，该并发控制模型包含：重复和冲突检测模块、优先级设定模块和执行模块；所述的重复和冲突检测模块包含：预处理子模块，用于对解析的服务请求消息进行数学表示；重复检测子模块，用于对解析消息的数学表示进行重复性检测；过滤器子模块，用于过滤检测得到的重复的服务请求消息；和冲突监测子模块，将过滤后的所有服务请求消息进行再冲突性检测；所述的优先级设定模块包含：优先级设定子模块，用于对存在冲突的服务请求消息进行优先级排序；所述的执行模块包含：请求消息预处理子模块，用于对标记优先级的服务请求进行排序并分配线程；寻址子模块，使用该子模块通过消息发送模块执行服务请求；其中，上述模块的所有操作基于在SOAP Body中定义了服务设备资源统一描述框架；

所述的方法包含如下步骤：

(5)在解析出SOAP Body中的请求消息后，消息被送到并发控制模块，此时先前的线程释放Web服务请求实例并放回第一线程池；

(6)并发控制模块接收到多线程送来的Web服务请求消息，送至重复和冲突检测模块，该模块根据设定的重复算法和冲突检测算法依次进行服务请求的重复性检测和冲突性检测；

(7)针对检测出的具有资源冲突性的服务请求，优先级设定模块根据设定的优先级算法优化服务请求内容及其执行顺序；

(8)将优化服务请求内容及其执行顺序交给执行模块，该模块的请求消息预处理子模块由第二线程池分配线程，完成相应服务请求。

上述技术方案，所述的重复算法步骤为：通过比较两个服务请求的访问地址URL、OperationName和OperationInput来判断，若全部相同则表示两个服务请求是重复的；若至少有一项不同，则两个服务请求是不同的；所述的冲突检测算法的步骤为：首先服务请求存在冲突的前提条件为即两个服务请求R₁，R₂关联有相同的服务设备资源；其次，服务请求R₁，R₂对其关联的相同服务设备资源的操作类型决定了冲突的存在。

上述技术方案，所述的优先级算法的计算公式为：

p＝αP_static+βP_dynamic，(α+β＝1)，

其中α，β分别为静态和动态优先级的对整个优先级计算的权重。

其中，所述的静态优先级计算公式可表示为：

P_static＝pX+qY，(p+q＝1)

其中，p表示规则预定义优先级数值的权重，而q表示执行时间对静态优先级的计算权重；

所述的动态优先级算法步骤为：

系统通过不断更新服务的等待时间，按从小到大顺序产生一组等待时间序列RW＝{1，2，...M}，RW每隔固定间隔更新的；假设冲突服务请求R_S在RW序列中的序号为Z(1≤Z≤M)，则动态优先级计算公式为：P_dynamic＝Z

其中，1≤S≤M。

本发明的优点在于，克服了传统的Web服务并发控制方法线程的分配没有考虑HTTP消息中封装的服务请求内容，造成的服务请求之间有冲突时造成的线程浪费、资源冲突和错误的发生，提高了物联网系统的资源利用率。

附图说明

图1是目前搭载在HTTP上的Web服务请求；

图2是传统的Web服务并发控制流程；

图3是本发明的服务并发控制原理的流程示意图；

图4是本发明的并发控制模块结构示意图。

具体实施方式

下面结合附图及具体实施例对本发明作进一步的描述。

在传统的Web服务并发控制基础上，本发明将在解析出SOAP Body的内容后，设计新增相应的并发控制模型来实现Web服务并发控制方法。

基于SOAP的服务设备资源统一描述

本发明首先将从SOAP协议入手，在SOAP Body中定义了服务设备资源统一描述框架，从而为下一步的优先级计算和并发控制奠定基础。如表1所示，

表1，服务设备资源属性定义

  属性名  说明  ResourceID  服务设备资源ID  ResourceType  服务设备资源类型  ResourceList  同属一个服务的设备资源列表  ResourceURL  设备资源所属服务的访问地址  OperationName  服务设备资源的操作名称  OperationType  服务设备资源的操作类型  OperationInput  服务设备资源操作的输入变量  OperationOutput  服务设备资源操作的输出变量

我们采用上述八个属性对服务设备资源进行描述。其中，ResourceURL、OperationName和OperationInput、OperationOutput取自SOAP本身，另外定义了ResourceID、ResourceType、ResourceList和OperationType四个属性。物联网Web服务依赖底层传感设备，因此需要唯一的ResourceID来标识服务设备资源，而传感设备的高度互联，同一传感器可能被多个Web服务调用，不同传感器设备也可以协同工作实现同一Web服务。我们采用ResourceList表示Web服务所关联的多个服务设备资源，是一个由各服务设备资源ResourceID组成的集合；ResourceType指明服务设备资源的类型，如摄像头、加湿器等。显然，一个ResourceType可以对应多个ResourceID；OperationType指明可以对服务设备资源进行的操作类型，如查询、操作；OperationInput和OperationOutput分别是服务设备资源操作的输入输出，从服务IO中获取。例如，如下所示，查询摄像头是否空闲的服务请求可以按照服务设备资源属性定义统一刻画。

可以看出，由于SOAP是基于XML描述的，因此只要增加解析处理，自定义的设备属性标签<ResourceList>和<Operation>等可以很容易的嵌入SOAP。

●服务并发控制模型

如图3所示，在解析出SOAP Body内容后，我们建立了一个并发控制模块来实现Web服务的并发控制。

与传统的Web服务并发控制流程不同，该并发控制维护两个线程池。在解析出SOAP Body中的请求消息后，消息即被送到并发控制模块，此时先前的线程释放Web服务请求实例并放回第一线程池。并发控制模块接收到多线程送来的Web服务请求消息，根据一定的策略进行请求服务设备资源的重复和冲突检测，优化服务请求内容及其执行顺序，由第二线程池分配线程通过执行模块完成相应服务请求。通过并发控制模块，避免了线程浪费、资源冲突和错误的发生。并发控制模块内部组成如图4所示：

并发控制模块主要包括重复和冲突检测、优先级设定和执行模块。消息接收模块负责接收解析的SOAP服务请求消息，并将请求消息送到预处理模块。预处理模块用于将解析得到的信息进行数学表示。首先，利用重复检测方法进行重复检测并使用过滤器过滤掉重复的服务请求并送到冲突检测模块进行服务请求的冲突检测。若存在冲突，需要对冲突的服务请求赋予不同的优先级，优先级的设定依靠预先定义的规则及当前的场景。请求消息预处理模块对标记优先级的请求进行排序并分配线程，进一步使用寻址模块通过消息发送模块执行服务请求。

●重复和冲突检测

Web服务并发控制的出发点是避免请求的重复与冲突。若服务请求存在重复，则可以使用相同的线程完成相应请求内容；若服务请求存在冲突，则需要对冲突的服务请求线程赋予不同的优先级。下面首先将重复和冲突检测中用到的服务设备资源进行相应的数学定义和描述，接着给出具体的检测计算方法。

服务器收到SOAP请求后将通过解析获得各个具体属性的取值。S服务的设备资源列表ResourceList可定义为RL(S)＝{RI₁，RI₂，...，RI_N}，其中RI_i为设备编号，且∈自然数集合N。设备资源RI的设备操作类型可定义为OT(RI)＝{OT₁，...，OT_p}。其中OT₁定义的查询操作为客户端发送请求并需要等待服务器端的响应，而OT₂定义的操作则为客户端发送请求后除了确认信息外并不需要服务器端返回其他信息。由于目前支持的仅有查询(query)和操作(do)两种操作类型，因此OT₁＝’query’，OT₂＝’do’，p＝1，2。S服务的访问地址URL可定义为URL(S)＝l，其中l为字符串变量。同理，服务设备资源RI的操作名称OperationName可定义为ON(RI)＝p，其中p为字符串变量。服务设备资源操作的输入OperationInput可定义为OI(RI)＝{OI₁，OI₂，...，OI_M}，其中OI_i为输入变量。

服务请求的重复检测需要通过比较两个服务请求的访问地址URL、OperationName和OperationInput来判断，若全部相同则表示两个服务请求是重复的，若至少有一项不同，则两个服务请求是不同的。假设有两个服务请求R₁和R₂同时到达，通过解析我们可以得到R₁的服务访问地址为R₁.URL(S₁)，服务设备资源的操作名称OperationName为R₁·ON(RI₁)，服务设备资源的操作输入OperationInput为R₁·OI(RI₁)，同样R₂的服务访问地址为R₂·URL(S₂)，OperationName为R₂·ON(RI₂)，OperationInput为R₂·OI(RI₂)，则判断服务请求重复的条件表达式为：

R₁·URL(S₁)＝R₂·URL(S₂)∧R₁·ON(RI₁)＝R₂·ON(RI₂)∧R₁·OI(RI₁)＝R₂·OI(RI₂)

服务请求的冲突检测不仅涉及两个服务请求关联的设备资源是否有重复，而且依赖服务请求对设备资源的操作类型。同样假设有两个服务请求R₁，R₂，关联的设备资源列表分别表示为R₁·RL(S₁)，R₂·RL(S₂)，首先服务请求存在冲突的前提条件为即两个服务请求R₁，R₂关联有相同的服务设备资源，因此存在冲突的可能。其次，服务请求R₁，R₂对其关联的相同服务设备资源的不同操作类型决定了冲突是否存在。判断依据如下：若R₁，R₂对其关联的某一相同设备资源操作类型同为查询，则不存在冲突；若R₁(R₂)为查询、R₂(R₁)为操作或R₁，R₂同为操作则存在冲突，判断条件为：if(！(R₁·OT(RI_i)＝＝R₂·OT(RI_i)＝＝{OT₁}))then conflict＝true，其中RI_i∈RL(S)。

●优先级计算和服务执行

对于检测到服务请求冲突的情况，需要对其进行优先级计算，并对冲突的服务请求赋予不同的优先级。与其他优先级计算方法不同的是，本方法中优先级计算由静态优先级计算和动态优先级计算两部分组成，其中静态优先级的计算又综合考虑了规则和场景两个因素，从而实现了上下文感知和动静结合两大特色功能。

静态优先级是指优先级的计算值将不随时间变化而改变，主要考虑利用预先定义的规则和场景计算服务请求的优先级。我们采用ECA规则(事件-条件-动作)来预先指定部分可能冲突的优先级，其中E刻画触发该规则的冲突事件，C刻画规则条件中包含的服务请求，A设定冲突服务请求的优先级。该规则描述语法和样例如下表所示。

当有两个服务请求R₁，R₂到达，且R₁，R₂均对RI₁表示的摄像头进行了操作，由冲突检测可知服务请求R₁，R₂冲突，由此触发规则r1。规则条件部分表示当R₁的操作名称为“turn to east”，而R₂的操作名称为“turn to south”，且由当前场景获取模块得知当前摄像头的方位为north，出于减少摄像头操作考虑，在规则的动作部分，我们设定R₁的优先级为10，高于R₂的优先级，其中优先级值∈自然数集合N。事实上，在Web服务中，某个服务请求可能在一个场景下优先级较低，但在另一场景下优先级最高。因此，在规则定义中引入当前场景使得优先级的设定更加准确。

前面提到，目前支持的服务设备资源操作类型仅有查询(query)和操作(do)两种，冲突检测依据的也是不同服务请求对服务设备资源的操作类型。假设有两个服务请求R₁，R₂，对于服务请求冲突的一种情况，即对服务设备资源的操作类型R₁(R₂)为查询、R₂(R₁)为操作，表示为：R₁·OT(RI)＝＝{OT₁}，且R₂·OT(RI)＝＝{OT₂}，我们利用规则设定操作的优先级永远高于查询的优先级，即do.Priority＞query.Priority；对于服务请求冲突的另一种情况，即对服务设备资源的操作类型R₁，R₂均为操作，表示为：R₁·OT(RI)＝＝R₂·OT(RI)＝＝{OT₂}，优先级的计算仅使用规则是不够的，还需要综合静态优先级和动态优先级。

从规则中，我们可以直接得到预先设定的优先级取值，表示为X。由于ECA规则和场景是预先定义的，因此无法考虑服务执行时间对静态优先级的影响。若有一组冲突的服务请求R₁，R₂，...，R_N，按执行时间由长到短排序，可以得到一组序列RT＝{1，2，...N}。假设冲突服务请求R_S(1≤S≤N)在RT序列中的序号为Y(1≤Y≤N)，则静态优先级计算公式可表示为：P_static＝pX+qY，(p+q＝1)。其中，p表示规则预定义优先级数值的权重，而q表示执行时间对静态优先级的计算权重。

动态优先级是指优先级随服务请求在队列中的等待时间而动态变化，即随等待时间增加优先级逐渐提升。系统通过不断更新服务的等待时间，按从小到大顺序产生一组等待时间序列RW＝{1，2，...M}。，与执行时间序列不同的是RW是每隔固定间隔更新的。假设冲突服务请求R_S(1≤S≤M)在RW序列中的序号为Z(1≤Z≤M)，则动态优先级计算公式为：P_dynamic＝Z。

综合考虑静态和动态优先级，我们得到统一的优先级计算公式：

p＝αP_static+βP_dynamic，(α+β＝1)，其中α，β分别为静态和动态优先级的对整个优先级计算的权重。

服务请求存在重复和冲突两种情况。并发控制模型需要对这两种情况设定不同的策略。对于服务请求重复的情况，可以通过共用进程来减少不必要的线程使用，具体通过过滤器将重复的服务请求转化为一个服务请求，然后第二线程池分配线程，执行完毕后将响应结果返回给重复服务请求组内的每一个源地址。对于服务请求冲突的情况，按照我们提出的优先级计算公式，对冲突的服务请求赋予不同优先级，按优先级先后顺序执行。总之，并发控制模块收到一系列服务请求后首先将会对其进行排序。排序整体按照先来先服务的原则，但对于存在冲突的服务请求按照优先级高低顺序。之后服务请求被依次放入执行队列，通过寻址模块由第二线程池分配线程执行服务请求。

需要说明的是，以上介绍的本发明的实施方案而并非限制。本领域的技术人员应当理解，任何对本发明技术方案的修改或者等同替代都不脱离本发明技术方案的精神和范围，其均应涵盖在本发明的权利要求范围内。