基于需求的服务质量监控

服务质量监控即服务

1 引言

许多公司已经认识到网络上预封装服务的强大功能。这些组件被视为快速系统开发和异构系统互操作性挑战的良好解决方案。因此，Web服务（WS）技术呈现出稳定增长的态势，并被IT企业广泛采用。它们可以作为服务提供者（发布者）在网络上共享和暴露自身功能，和/或作为服务消费者（请求者）复用和调用已发布的服务。

Web服务技术的广泛应用导致互联网上可访问的Web服务数量庞大。如此庞大的数量引发了服务激增，因此有必要采用一种区分标准，从所有已发布的方案中选择合适的服务。这定义了网络服务选择（WSS）过程。

过去，选择主要基于功能属性。换句话说，Web服务的重要性和关注度仅根据其提供的功能来判断。然而，随着可用Web服务数量以指数曲线不断增长，功能上相似的Web服务显然越来越多。因此，仅通过定义“服务应做什么”的功能属性已不足以区分不同提供者所提供的相似服务。我们更应关注“服务应如何表现”，即非功能属性。正因如此，服务质量（QoS）作为功能相似的Web服务之间的重要区分标准，变得愈发关键。同时，与质量相关的信息对Web服务提供者和消费者双方都至关重要且具有实际价值。

一方面，提供者需要评估其Web服务以：
– 将其服务与其他可能提供相同功能的服务进行对比定位。
– 向客户突出并证明其Web服务的能力与性能，并利用这些服务质量信息作为Web服务营销的支持。
– 识别并预测关键性能指标，以提升性能。
– 估算其Web服务的使用率。

另一方面，有关提供质量的信息使客户端能够：
– 选择最佳可用的Web服务。
– 验证该Web服务是否仍然遵守服务水平协议。
– 预测提供的QoS演变情况。
– 对可能使用的Web服务做出适当决策，即比较期望的QoS值与实际提供的QoS值。

1.1 背景与挑战

与Web服务技术相关的服务质量作为一个即用型解决方案，非功能性能引起了众多研究人员的关注。他们主要关注两个问题：其影响因素的定义（重要性、关系和类别）以及将这些因素的值聚合为整体质量值。

为了评估提供的质量，必须通过一组相关且有影响的因素来定义该质量，这些因素能够指示过程和/或输出的质量，即质量指标（QI）。

一些研究（Araban 和 Sterling 2004；Galster 和 Bucherer 2008；Al-Moayed 和 Hollunder 2010；Dong 2010；Becha 和 Amyot 2012；Kaewbanjong 和 Intakosum 2015）关注于定义与Web服务相关的服务质量属性，如合规性、可靠性、可用性和响应时间。他们提出了度量模型，但通常存在不同的解释。

在Galster和Bucherer（2008）中，作者通过一组属性（即响应时间、一致性、可用性、安全性等）定义Web服务的质量。随后，Glaster等人提出了一种分类方法，包括三个主要类别：与过程相关、外部需求和服务相关需求。

Becha和Amyot（2012）的研究人员发布了一项基于面向服务架构（SOA）实验反馈的调查，以确定Web服务场景中最相关的QoS属性。他们最终提出了一组17个属性，分别是价格、响应时间、声誉、认证、可用性、成功率、可用性、准确性、标准合规性、故障模式、事务性服务、安全性、管辖权、服务版本控制、资源需求、可扩展性和服务位置。

Kaewbanjong 和 Intakosum（2015）的作者们介绍了该领域先前研究工作的概述。根据他们的综述，主要不足之处在于他人所提出分类法存在重叠问题。因此，他们提出了一种新的知名QoS属性分类法，该分类法包含六个独立类别：与提供者、消费者、开发者、运行时管理、安全性以及网络管理相关的属性。

Ameller 等人（2016）开展了一项调查，目标受众包括研究人员和从业者。调查结果表明，64.7%的受访者认为质量属性与功能性同等重要。此外，结果证明，在基于服务的系统中，质量属性受到特别关注，因为有65%的受访者会明确考虑它们。

在Oriol等人（2014年）的研究中，作者提出了47种Web服务质量模型。他们比较了这些模型，并确定了其中最重要的19个因素，包括可用性、吞吐量和响应时间。

在Bouasker等（2016）中，我们对Web服务质量属性的现有技术进行了更深入的研究。此外，在之前的工作中，我们根据其可测量性及其可能的位置（从提供者侧/从消费者侧）对这些属性进行了分类。

这种多维度的质量定义带来了新的挑战，即如何计算Web服务的整体质量。早期关于这些非功能性特征的研究提出了不同的方法，将其值聚合为单一评分。通常，通过评估分析来评定每个特征的重要性和显著性。根据所得结果，为每个属性分配一个权重以计算整体质量。在Xiao等（2012）的研究中，Xiao等人采用灰色关联分析来研究对Web服务选择影响最大的因素。研究结果表明，最佳符合度、可用性、成功率和响应时间是最具影响力的关键参数。这些研究的主要不足之处在于忽略了客户上下文。对保证质量的需求取决于客户的偏好以及Web服务应用的领域和上下文（例如，在电子商务场景中的支付环节，安全性则显得尤为重要）。为解决这一缺陷，Al-Masri和Mahmoud（2007）、Youcef（2010）以及Chainbi等（2012）的研究者提出应允许客户表达其偏好，从而为每个关注的质量属性分配相应的权重，以体现其重要程度。

例如，El Masri 等人（Al-Masri 和 Mahmoud 2007）提出了一种Web服务相关性函数，用于根据客户对非功能性质量的偏好，计算每个Web服务的相应评分。在之前的一项研究中（Bouasker 和 Langar 2016），我们证明了该权重不足以准确描述用户对交付质量的偏好，并提出了非功能性需求（NFRs）的新定义以及一种基于NFRs的评分与选择算法。

对QoS属性更深入的研究表明，服务质量因素并非完全相互独立；即其中一些因素相互关联，而另一些则存在冲突。Galster 和 Bucherer（2008）指出，这些因素之间存在许多依赖关系，某些因素的变化会对其他因素的值产生重要影响。

Zulzalil 等人（2008）开展了一项调查以识别这些相互依赖性。所获得的结果证实了此类关系的存在。这些关系根据所涉及的QoS属性之间的相互作用被分为三类：正向、负向和独立。然而，这些不同的依赖关系在文献中尚未得到充分分析和研究。目前尚无明确信息说明这些属性彼此影响的程度。工业界和文献调查均认为，这些依赖关系需要进一步探索和理解。

在Bouasker和Langar（2017）中，我们解决了这一问题，并引入了属性之间的支配关系。这种关系在计算Web服务的效用函数。它被用来减少计算时间并优化评分算法。所获得的整体质量将作为对提供相同功能性的所有Web服务进行排序的标准。因此，Web服务评分与排序在Web服务选择过程中是初步且关键的环节，并已成为许多研究人员关注的问题。

在Anithadevi和Sundarambal（2018）以及Yao等（2013）的研究中，作者们使用协同过滤（CF）技术设计了一个智能QoS感知的Web服务推荐系统。

QoS属性值评估 在电子系统中，QoS接收过程与传统方式不同。事实上，过去一些方法（如协商）适用于表达和提供期望的QoS值。但当前这一过程已转向基于技术的环境，其中面对面的交互受到限制，并被人机交互所取代。因此，获取每个属性值的方法或途径成为一个备受关注的话题，并产生了大量提案。许多研究工作聚焦于将服务质量集成方法应用于不同部分：提供者、消费者和Web服务注册中心。

Tosic 等人（2005）、D’Ambrogio（2006）、Rajendran 等人（2010）、Tewari 等人（2012）以及 Lee（2008）将质量测量操作委托给 Web服务提供者。

Tosic 等人（2005）和 D’Ambrogio（2006）扩展了Web服务描述语言（WSDL）以支持质量 modeling。

Rajendran 的研究（Rajendran 等人，2010）旨在扩展统一描述、发现和集成（UDDI）注册中心，以使用 T模型 和 Web服务代理（WSB）来支持质量信息。后者包含验证器和认证器组件，用于在将Web服务发布到UDDI注册中心之前，验证由提供者指定的QoS值。在 Ran（2003）的研究中，假设服务质量从提供者端进行测量，并最终由第三方进行验证或认证。如果所声明的QoS值正确，则向提供者发送证书，以便将其新服务注册到UDDI注册中心；否则，提供者会收到失败确认（ACK），服务注册将失败。

在 Tewari 等人（2012）中，作者提出了一种框架，以在发现阶段考虑服务质量。为此，服务提供者提供服务质量指标，并通过名为Web服务管理（WSM）的中间件组件使用标准阈值进行验证。

尽管提出了多种解决Web服务选择问题的方案，但几乎所有研究人员都参考已有的质量属性值（使用已发布的数据库）来验证其方法。因此，他们基于预先测量的质量值引入了静态选择。

因此，一些研究人员建议首先测量QoS值，以准备一组包含其功能性和非功能性描述的Web服务，然后利用创建的注册表来选择和组合新服务，而服务所处的环境具有动态性和易变性。因此，最好延迟质量评级，以便使用更准确的QoS信息。

稍后，一些研究人员建议明确包含服务质量属性的评估和评定。因此，学术界以及工业界研究（Martin 等人 2007年；Bartolini 等人 2008年，2009年）设计并实现了用于评估服务质量指标的框架和工具。Parasoft SOAtest（帕拉软 2014年）、SOAP Sonar（交叉检查 2005年）、 soapUI（SmartBear公司 2008年）和 Storm（CodePlex 2006年）是测量工具的示例可能会提供Web服务测试平台。尽管它们允许更快的测试用例生成和报告，但这些工具仅支持对预定义、不可扩展且有限的属性列表进行测量，提供静态评估，并且需要高级脚本知识。

鉴于Web服务环境的易变且不可预测的特性，服务质量值会出现快速波动。因此，静态测量成为QoS控制的主要问题和严重弱点。事实上，消费者将基于未必实时的值做出选择。即使消费者能够在选择前测量并验证服务质量属性值，我们也必须能够持续评估这些值，以确保在特定时间做出的选择仍然有效。

QoS监控方法为了解决这些问题，许多研究人员提出了基于实时QoS信息的精确选择策略。主要可将这些方法分为几种类别：第一类包含理论策略，第二类包含基于测量的方案。

根据统计学，一些研究人员估计所提供服务质量的概率或可能的实际值。

文献 Bin-Bin 等人（2015）将服务质量视为随机变量，使用柯尔莫哥洛夫-斯米尔诺夫（K-S）方法计算其差异，并基于随机占优理论监控服务质量的偏差。在 Hwang 等人（2015）的研究中，QoS预测被定义为Web服务推荐系统的核心任务。作者将服务质量表示为随机变量，并计算关于QoS约束的符合概率。

Hosein 等人（Zadeh 和 Seyyedi 2010）提出了一种基于神经网络技术的预测模型。该方法通过分析时间序列中的历史行为来预测未来值。

其他处理此问题的研究将Web服务信誉作为基本来源。Zheng 和 Lyu（2010）记录当前用户以外的其他用户对某Web服务的以往故障数据，以预测当前用户的可靠性值。Su 等人（2017）和 Qiu 等人（2013）强调了用户贡献的QoS值及其在协同过滤方法中对QoS预测的重要影响。他们提出了一种基于信誉感知预测（RAP）方法，该方法基于可信值计算服务信誉。

在 Xu 等人（2007）的研究中，作者结合服务提供者发布的QoS信息和客户端反馈来计算信誉评分，并将其用于基于QoS的Web服务发现与选择。

所有这些努力都依赖于采样、随机方法或声誉。这类方法的准确性不够，因为它们的结果并不精确，且依赖于统计方法。此外，在客户端提供用户反馈时，我们并不总能验证其可信性和可靠性。而且，即使对于可信用户，用户反馈也不是绝对的；它取决于他如前所述的特定上下文。

进一步的研究（Hanna和Munro 2008；Fu等人 2004；Guangquanet al. 2007）提出了测试方法和工具，以评估特定Web服务的某些服务质量属性。在评估Web服务所提供的质量时，考虑到时间方面是最重要的，Asadollah和Chiew（ 2011）中描述了一种理论架构，该架构通过代理测量响应时间。

Pegoraro等人（2008）提出了一种基于拦截器的自愈架构，该拦截器可拦截请求和响应消息，以测量每次执行的QoS值。

在Saxena等人（2009）中，Saxena等人提出了一种基于探针的可观测机制。该机制基于在Web服务中的探针插入，可提供有关连接、用户和请求者位置的不同信息。然而，它需要访问Web服务代码，而这并不总是可行的。

这些基于代理的方法的主要缺点有两方面：一方面，它们会带来开销，并极有可能形成瓶颈；另一方面，在发生故障时，它们会成为单点故障。

Artaiam 和 Senivongse（2008）以及 Becker 等人（2009）提出提供者端监控工具，以增强对服务质量值的服务器端测量。Michlmayr 等人（2009）结合了客户端和服务器端服务质量监控方法。他们采用基于事件的处理来获取当前的服务质量值。

客户偏好感知Web服务用户通常对关键业务指标和非功能性属性值有不同的偏好。因此，非功能性需求集可能针对特定客户端或上下文而定。例如， Rajalakshemy等人在Sha等（2013）中提到，一个客户端可能要求提供最快响应时间的Web服务，而另一个消费者可能将可靠性或持续可用性作为选择标准，而对另一个用户而言，安全性是最重要的参数。

这激发了在评估Web服务的质量时，集成和考虑用户偏好重要性。

为应对这一挑战，许多研究人员建议监控Web服务质量偏差与服务水平协议的对比情况。Yeom 等人（2009）；？；Ameller 和 Franch（2008）提出了监控提供质量与合同符合性并报告变化的方法。

达维什等人使用Web服务等级协议（WSLA）语言提出了一种基于事件的 SLA（服务等级协议）服务质量监控方法，以检测其变化。他们提取服务级别目标，并将其与服务质量指标的实际值进行比较（达维什等人 2015）。但关于这些数值评估的过程和策略等详细或明确的信息并未给出，尽管已有大量研究致力于定义监控网络服务质量的方法论，这仍是一项“重大”任务。

1.2 主要贡献

本文提出了一种监控器，其作用是评估并跟踪Web服务的质量值，以确保提供实时的QoS信息。与现有的Web服务监控质量方面的研究相比，本工作的主要贡献在于：
– 将QoS属性技术定义为一组可配置参数。
– 作为服务的测量工具：针对我们服务质量模型中的每个质量属性，实现了一个基于场景的监控器作为Web服务，旨在持续评估相应的属性值。
– 基于非功能性需求的监控过程：设计了一种组合过程，考虑客户端指定的非功能性需求，其执行基于前述描述的Web服务。
– 通过考虑QoS属性之间的支配关系以及技术参数之间的相互依赖性，对非功能需求驱动的监控进行优化。
– 恢复动作：我们的监控器不仅会控制正在使用的Web服务所提供的质量，还将在发生需求违反时提名一个替代方案。

1.3 论文结构

在引言部分，我们介绍了总体背景以及基于服务质量感知的Web服务选择领域已有研究和挑战性问题的综述。本文其余部分组织如下：在第2节中，我们给出后续工作中将使用的一些定义；第3节将介绍所提出的监控架构及其组件；第4节致力于对我们的方案进行验证；最后，我们讨论结论和未来工作。

2 预备知识

在本节中，我们将简要回顾将在本工作中使用的前期贡献。

2.1 服务质量模型

与Web服务技术相关的服务质量属性一直是许多研究人员关注的焦点。他们对这些参数进行定义、分类，并研究每个参数的意义和影响。在本研究中，我们将仅考虑 Bouasker和Langar（2016）所选的属性列表。这些属性的特点是从用户端具有可测量性。该服务质量模型包括：

2.1.1 响应时间

这是从发送请求到接收到响应的持续时间。它取决于客户端延迟、服务器延迟和网络延迟（Kim 等人，2011）。

2.1.2 最大吞吐量

它由测量时间内的已处理请求数量与测量时间的比值来描述（1）。

$$
Throughput = \frac{ProcessedRequestsInTimeUnit}{TimeUnit} \tag{1}
$$

2.1.3 可用性

此属性计算Web服务处于工作状态的可用性概率，计算方法如(2)所示。

$$
availability = \frac{TimeServiceAvailable}{MeasuringTime} \tag{2}
$$

2.1.4 可访问性

该准则评估系统可用时Web服务可访问的概率，计算方法如(3)所示。

$$
accessibility = \frac{NumberOfAckMessages}{NumberOfRequests} \tag{3}
$$

2.1.5 成功率

根据OASIS的定义，它表示Web服务成功处理后返回响应的概率，并按（4）所示进行计算。

$$
successability = \frac{NumberOfResponses}{NumberOfRequests} \tag{4}
$$

对于每个属性，我们将使用表 1 中所示的相应名称。

缩写	质量属性
RT	响应时间
Th	吞吐量
AV	可用性
Acc	可访问性
Succ	成功率

2.2 非功能性需求

如前所述，Web服务的使用环境对其所需的质量有重要影响，从而影响该服务满足非功能偏好的程度。

考虑到这一点，一些研究人员（Al-Masri 和 Mahmoud 2007；Patro 等人。2015； Vadivel 等人. 2014年；Susila 和 Vadivel 2011）使用为每个属性分配的权重来反映客户偏好。

在 Bouasker 和 Langar（2016）中，我们指出了该方法的不足之处，并提出了一种新方法，以支持客户端准确地指定其需求。

我们通过一组五个参数定义了一个非功能性需求：
– 类别（C）：可以取以下值之一：必要（N）、期望但非必要（DNN）或可选（O）。
– 权重（W）：表示当前需求相对于其他需求的相对重要性。
– QoS属性（Q）：需要测量的相应质量属性。
– 最佳值（BV）：客户端完全满意的值。
– 最差值（WV）：客户端完全不满意的值。

2.3 服务质量属性支配关系

在Bouasker和Langar（2017）中，我们研究了QoS属性之间的关系，并定义了它们之间的一些支配关系。例如，可用性支配可访问性。换句话说，一个Web服务如果不可用，则无法被访问。

该支配关系被用于验证用户非功能性需求规格的一致性，并优化评分与排序算法。

这种关系也将支配本文中的监控过程。

2.4 基于非功能性需求的Web服务评分算法

为了从一组能够提供所需功能性的候选Web服务中选择一个Web服务，需要计算它们提供的质量水平。这种质量会根据客户端上下文和偏好进行不同的评估。因此，其计算必须由用户非功能性需求来指导。

作为这一领域的贡献，我们在Bouasker和Langar（2016）中提出了一组算法，用于在计算候选Web服务评分时整合用户的约束。这些算法在Bouasker和 Langar（2017）中得到了改进，其中引入了支配关系结果。

首先，针对每个非功能性需求，通过测量值（MV）与可接受值范围之间的距离计算局部评分scorer（参见算法1）。

第1‐2行描述了最佳情况，即测量值MV达到最佳值BV。在这种情况下，局部评分为 1。第3‐4行对应最差情况，即测量值MV达到最差值WV。因此，局部评分为零。第 5‐8行处理中间情况。我们区分两种情形：第5‐6行描述正向质量属性的情况，第 7‐8行定义负向质量属性的局部评分公式。

此外，计算新的相对权重以考虑整个规格。最后，全局评分WSScore的计算如算法 2所示。

为了获得初始为空值的全局评分，我们将每个指定非功能性需求属性的局部评分与其相对权重的乘积相加。

3 面向场景的QoS监控方法

通常，Web服务应用于易变、不稳定和动态的环境中。此外，Web服务特性时刻发生变化，并依赖于某些运行时环境；例如，响应时间会受到用户数量的影响。因此，静态评估QoS属性已不再具有重要意义。我们更需要对Web服务提供的质量进行监控。为此，我们提出一种QoS监控器，用于控制Web服务，以保证实时QoS信息，并确保其满足性能目标。

通常，Web服务的质量不仅限于单个属性，而是多个属性值的聚合。因此，我们必须监控这些属性中的每一个。

我们采用“每个属性一个监控器”的策略。该监控器被设计为一个特定Web服务，其作用是监控该质量属性的值。

除了其经验定义外，每个质量属性还通过一组参数（如测试周期和频率）进行技术描述。对于每个属性Q，可以指定这些参数以配置其监控场景。

此自定义配置作为输入引入到对应监控器中。

第2.1节列出的服务质量属性均在本文中予以考虑；然而，我们的开放监控系统可扩展以支持新的服务质量属性。

为了监控Web服务的整体质量，我们建议在组合Web服务中组合涉及属性的监控器。

该过程将评估并持续监控所考虑的非功能性因素 为了降低任务复杂度并优化监控性能，我们采用了一种按需且基于事件的策略。

使用这种混合策略，我们假设：
1. 仅监控由用户非功能性需求（NFRs）规定的属性
2. 控制正在使用的唯一Web服务的质量值
3. 仅在特定事件（即阈值）发生时，对替代Web服务执行监控过程。

此外，服务质量因素的经验相互依赖性及其技术参数之间的关系被纳入全局监控过程中。

这种对依赖关系的认知可能通过授权某些子流程的并行执行，从而减少计算时间。

3.1 QoS属性的技术定义

量化该属性的技术过程与其公式密切相关或由其公式推导得出。

例如，为了评估（2）中定义的可用性值，我们必须回答以下问题：从技术上讲，何时认为服务是可用的？通过使用超文本传输协议状态码，当Web服务返回200 OK HTTP响应码时，该服务被视为可用。

上述提到的理论方程可能有助于相关QoS属性的静态测量。然而，对于动态评估，我们必须明确测量过程，并了解对每个服务质量属性产生影响的因素，例如测试周期、迭代和频率。

因此，每个因素（可用性、响应时间、成功率、最大吞吐量和可访问性）在技术上都由其计算过程和一组影响指标定义。

我们将举例说明几个指标，例如超时和线程数，定义如下：

– 超时：表示在判定测试失败前等待响应的最长时间。该参数是必要的，以避免无限循环。
– 线程数：要启动的线程数量。这将模拟Web服务的并发使用。

超时是所有属性的通用度量。事实上，为了评估一个质量属性，我们将调用 Web服务，但在失败的情况下必须为此调用指定一个终点。这可以避免无限等待。

响应时间和吞吐量属性的评估取决于队列中的现有任务以及Web服务的并发使用情况；因此，需指定线程数以考虑此上下文。

在表 2中，我们展示了所有定义的参数的分布情况。列表示参数，行列出服务质量因素。

服务质量因素	超时	迭代	测试周期	线程数	测试规划
响应时间（RT）	√	√	√	√	√
可用性（AV）	√	√	√
可访问性（ACC）	√	√	√
最大吞吐量（TH）	√	√	√	√	√
成功率（Succ）	√	√	√

对于可用性、可访问性和成功率，测试规划的特点是开始日期、结束日期和频率。

对于响应时间和吞吐量，我们仅有开始日期和线程数，因为测试已经受到测试周期参数的限制。

由于影响指标并非完全相互独立，下一节将专门进行相互依赖性分析。

Metrics interdependencies study 对于每个属性，客户端可以指定自定义配置。在将所有关注属性的配置聚合到一个基于场景的监控器时，某些值可能会发生冲突或无法准确执行。

为了遵守用户指定的场景配置，已验证了不同情况（测试区间重叠、频率、并行调用、嵌套调用等）。

我们在示例1中给出了一个例子。

示例1 我们假设客户端希望使用以下配置来监控响应时间和吞吐量值。

属性	超时	线程数	开始时间	结束时间
响应时间	2s	5	12时34分	12时40分
吞吐量	3s	20	12时38分	13时

每个属性指定了不同的超时时间。由于所有服务质量因素的超时定义方式相似，因此该配置可能不一致。

在此配置中，测试间隔并非互不重叠。我们有一个重叠区间[12h38, 12h40]。

在12时38分，我们不需要启动20个线程，因为我们可能已经有5个正在运行的线程。

因此，需要启动的线程数量取决于已经运行的线程数，以确保仍然符合客户端配置。

这种相互依赖性验证过程被转化为基于规则的算法，以确保配置的一致性。

因此，根据用户的设置，Web服务将根据指定的配置调用相应质量属性的监控器。

3.2 作为复合Web服务的QoS监控器

如上所述，Web服务的质量是多维度的，即涉及许多服务质量属性。因此，监控Web服务质量意味着跟踪所有相关服务质量因素的值。

为此，我们建议从已设计的简单监控器创建组合监控过程。

这种组合将受到客户端的非功能性需求及其相应的服务质量属性之间的关系的强烈影响和制约，另一方面也受到技术参数配置之间的相互依赖性和可能干扰的影响和制约。

Client’s NFRs-driven monitoring

通常，Web服务的用户有一组特定的非功能性需求，这些需求必须同时得到满足。

由于监控一个客户端不感兴趣的属性值是没有意义的，我们建议从客户偏好的规格中提取出感兴趣的服务质量因素。

此外，每个非功能需求（NFR）都通过第2.2节中所述的类别C进行描述。这意味着某些属性相对于其他属性具有优先级。

事实上，更重要的是控制属于必要非功能性需求类别的属性值，并验证其保持在可接受值范围内。

此外，用户可能对具有一种支配关系的若干服务质量因素感兴趣，这种关系在第2.3节中定义。这种关系可能意味着调用相关监控器时的某种顺序。

局部和全局技术干扰

如前所述，某些参数在技术上是相互依赖的（参见第3.1节）。

除了这种局部依赖关系外，被监控属性的公共参数之间也可能存在全局技术干扰。

因此，在调用这些监控器时忽略它们的相互依赖性是毫无意义的。

所指定需求的影响，以及技术干扰的影响，将在参与监控器的协调过程中得到进一步说明并变得更加明显。

为了合成这些监控Web服务并生成所需的复合监控器，我们将执行图1中所示的整个过程。

本节其余部分将详细解释每个步骤。

3.2.1 非功能性需求一致性验证

可用性比率是国际标准ISO/IEC 25010列出的软件质量要求之一，它包含多个子特性，其中包括用户错误防护准则。后者在iso25000（2017）中定义为“系统保护用户避免出错的程度”。

同样，在我们的情况下，客户端可能尚未成熟到能够恰当地明确其需求，这显然可能导致不一致。

例如，如果客户端提出了以下两个需求：

– (N, 0.6, 可用性, 90, 60, MVAv)
– (N, 0.6, 可访问性, 80, 70, MVAcc)

这意味着客户端无法接受低于70%的可访问率，而当可用率为 ≥60%时，客户端是可以接受的。然而，having MVAv = 60%意味着 MVAcc ≤ 60%。因此，对于一个可访问率为65%的Web服务（即其可用性为 ≥）

65%），客户端对可访问性完全不满意，但他并未考虑可用性！

为了在可用性方面保持一定的性能水平，我们建议协助用户更好地引入其偏好。

事实上，会分析客户端的规格以检测不一致问题，并提出纠正措施。

该故障管理过程由算法3描述。

如图所示，我们发现了一些不一致的情况，并为每种情况提出了若干纠正措施。

这些改进方案将在客户同意后执行。

在吞吐量

在此阶段，我们得出了一组一致的非功能性需求以及相关的服务质量属性。

3.2.2 本地配置分析

对于每个关注的属性，客户端将配置监控场景并分配每个技术参数的值。

在参数相互干扰的情况下，可能会发生冲突，如示例1中所述。

为了避免此类情况，此步骤会分析所有引入的设置，并生成一个新的一致配置，以调整某些指标值，同时仍然忠实遵守客户偏好。

此分析步骤包括检测重叠区间、调整频率和线程数等。

此外，根据其结果，一组Web服务调用可能会在高层抽象活动上被减少，该高层抽象活动的输出将由监控器进行不同的分析。

例如，在测试间隔重叠的情况下，交集时间段内的Web服务调用仅以最小线程数执行一次。从每次调用中，所有相关的属性值将被同时计算。这些属性值将由其对应的监控器分别使用。

3.2.3 监控器调用调度

一旦完成整个配置，将创建监控过程。该过程由用于监控Web服务的QoS属性组合定义。

这种组合以及更精确的监控器调用调度由非功能性需求驱动。

在算法4中，我们提出了一组作为嵌套条件的规则，其左侧对应于监控器调用的执行顺序。

该算法强调了支配关系和非功能性需求类别两方面的影响。在支配关系的情况下，我们有两种情形。

– 在前一种情况中（第3‐7行），至少有一个非功能性需求是必要的；首先通过调用其监控器来监控相应属性中最占优的那个。然后，根据该类别需求验证的结果，决定是调用下一个属性的监控器，还是停止对当前Web服务的监控过程（即发生C类约束违反）。
– 第二种情况描述了当指定非必要非功能性需求时的情形（第8‐14行）。首先监控被支配的属性，并根据其测量结果决定是调用下一个属性的监控器，还是自动地结束其测量。

关键思想是仅在必要时调用监控Web服务，以减少监控开销。

例如，由于可用性主导可访问性，如果与可访问性对应的非功能性需求为N类，并且用户规格说明中列出了与可用性相关的非功能性需求，则监控器将从可用性开始有条件地调用。

事实上，如果提供的可用率低于客户端指定的最差值，则监控可访问性值是没有意义的。

3.2.4 恢复动作包含

如上所述，并根据调度算法，当被监控服务不再符合客户端要求时，将执行停止指令。例如，N类非功能性需求违反意味着当前网络服务的所有监控过程都将停止。

然而，更有趣的是在早期阶段预测此类需求违规，并提供一个Web服务作为最终不令人满意的替代方案。

为此，我们定义了警报指令以警示预期的违规情况。主要挑战在于何时发送此类警报？必须在风险情况下发送，但不能过多。

为了解决此问题，我们假设从可接受值变为完全不满意值并非瞬时事件。换句话说，在达到这些值的过程中必然存在一些中间状态。因此，即使属性值的变化在整个时间段内并非单调变化，但在部分时间段内是单调的。

基于这一假设并运用定理1和2，我们可以得出结论：属性值（如果存在）将逐渐达到一个临界点。

定理1 设f是定义在区间I上的实值单调函数。那么f的第一类间断点的集合至多是可数的。

定理2 如果一个连续函数 f，以区间 [a, b] 作为其领域，在区间的两个端点处取值为 f(a) 和 f(b)，那么在区间内的某一点上，它也会取到 f(a) 和 f(b) 之间的任何值。

因此，我们可以在临界点附近发出警报。我们建议允许客户端指定一个阈值来触发警报。

然而，该阈值可能会暂时达到，随后恢复到可接受值范围内。在这种情况下，发送警报是无用且具有干扰性的。

为了避免此类无意义的警报，我们在向客户端发出警报之前，会根据算法5中所述，验证属性值在该阈值附近的稳定性。

客户端可以自行更改Web服务，或请求建议。

在前一种情况下，将监控手动选择的Web服务合规性。而如果任务交由系统处理，则会推荐替代Web服务，并在被接受后进行监控。

替代Web服务选择在本研究中，我们不仅提议监控正在使用的Web服务，还建议在发生非功能性需求违规时，推荐一个替代Web服务作为恢复措施。

为此，将在给定时间基于服务质量属性的度量来评估可用的候选Web服务。

这些服务质量属性的测量作为守护进程执行。对于每个Web服务，使用第2.4节中指定的算法来计算其评分。

在风险情况（即过于接近指定阈值）下，将对评分最高的Web服务进行监控，以获取实时 QoS信息，并验证其是否仍是最适合选择的服务。如果用户请求替代方案，则推荐此Web服务。

下一个部分将解释一个具体的案例研究。

服务质量监控即服务

4 讨论和验证

4.1 案例研究

为了进一步说明和验证我们的方法，本文提出了一个案例研究。我们假设一位用户为其客户提供了基于服务的预订系统。该系统涉及内部服务以及一些外部服务。假设该系统使用外部的货币转换Web服务来计算客户货币中的预订费用。为了保证整个系统的质量，该用户必须验证所有参与的Web服务（尤其是付费服务）所提供的质量。特别是，他将监控货币转换Web服务的服务质量。

假设该用户的偏好如表 3 所示。

类别	属性	权重	BV	WV	阈值
DNN	可成功性（%）	0.9	70	60	63
DNN	可用率(%)	0.85	90	50	68
O	响应时间 (毫秒)	0.6	10	25	20

该用户为其监控器的每个属性指定场景设置。图2中展示了用户对可用性监控的配置截图。

为简便起见，我们假设每个属性的测试规划简化为一行，指定的开始和结束时间可如图3所示呈现在时间线中： t1Av、t1RT、t1Succ 分别是可用性、响应时间和成功率测试的开始时间， t2Av、t2RT、t2 Succ 分别是可用性、响应时间和成功率测试的结束时间。

所有关于感兴趣属性的监控器配置都将根据本地一致性规则进行分析和验证。

特别是，算法3是适用的，因为可用性和可达性属性（均包含在指定的偏好中）之间存在支配关系。这种一致性验证引入了一些修正，如表4所示。

类别	属性	权重	BV	WV	阈值
DNN	可成功性（%）	0.9	70	60	63
DNN	可用性（%）	0.85	90	60	68
O	响应时间 (毫秒)	0.6	10	25	20

可用性和成功率的指定测试周期包含一个干扰间隔，在此期间同时监控各项属性。在此时间段内，通过通用配置（即迭代次数和频率的最小值）生成一个具有不同输出的单一测试。因此，在每次调用时，都会测量可用性和可访问性。此外，这些属性之间的支配关系（即可用性支配成功性）意味着对可用性测试的条件访问，从而在发生故障时减少监控开销。

在没有非分类非功能需求（N-Class NFR）的情况下，应用监控器调度算法的第二部分（算法4）。首先验证成功性属性（Succ attribute）。如果Web服务满足所需成功性值（≥ 60），则可以直接推断其可用性值（Av value）为（≥ 60），这意味着该Web服务提供了所需的可用性，因此无需调用其监控器进行验证。而在验证失败的情况下，无法对可用性做出结论，因此需要调用可用性（Av）属性监控器。

在该时间交集段结束时，可用性和成功率的计算得到的比率将被其对应的监控器利用。

4.2 讨论

得益于所提出的监控策略，该基于服务的预订系统的提供者可以持续验证货币转换Web服务的提供质量是否符合其非功能性约束。

他可以配置监控场景，使其自动地并定期地被调用（每天、每小时等）。

作为货币转换Web服务的客户端，他能够跟踪所提供服务质量的波动，并验证SLA合同声明是否得到完全遵守。

此外，此跟踪由他的需求驱动，因此仅在需要时执行。这减少了监控时间及其对评估值的可能影响。

为了更好地处理可能导致监控过程延迟的这些问题，我们引入并考虑了QoS属性之间的现有关系。这将使得某些监控任务可以跳过。

作为预订系统的提供者，他将在可能发生所需质量违规之前收到通知。

这样，他可以切换到另一个Web服务并避开这个临界点。

这种快速且提前的故障排除在以下使用情况下尤为重要：即该Web服务作为组件用于Web服务组合中，以提供更高附加值的功能性。

事实上，质量约束的违反可能会扩散到整个预订系统，可能导致已签署的SLA合同中的某些条款被打破，从而引发额外费用（即赔偿）并损害该提供者的声誉。

与之前提出的监控服务质量相关信息的方法相比，所提出的方法提供了更新的值，并优化了计算时间和恢复动作。

5 结论

本文提出了一种针对Web服务技术的服务质量监控新方法。主要目标是克服研究人员所提方案的不足之处。

为了弥补质量属性描述的不足，我们采用了对非功能性需求的扩展定义以及一组属性，这些构成了我们的服务质量模型。随后，我们从技术上研究每个属性，以确定评估其值的关键参数。某个属性的参数定义了其对应监控器所要执行的场景。

鉴于质量属性之间的关系，它们的监控器并非完全孤立。这些监控器相互协作，以持续提供实时QoS信息。

服务质量属性值被引入评分算法中。候选服务根据其得分进行排序。

正在使用的Web服务会持续受到监控。如果预测到非功能性需求将被违反，则会触发警报。因此，监控过程将被调用，以评估其他服务提供者的QoS值，从而准备最合适的Web服务来替代当前正在使用的服务。

从架构的角度来看，它依赖于“作为一种服务”的范式。事实上，针对每个服务质量属性设计了基于场景的监控器作为一种服务。这些测量场景是可定制的，能够更好地反映客户需求和上下文特定性。

（即设备内存、网络速度等）。此外，它们在模板创建和复用方面对用户也有益处。

例如，用户可以为每个属性保存一个固定的配置（测量场景），以便在所有Web服务监控活动中稍作修改后应用。然后，Web服务的质量跟踪包括将涉及的服务质量因素的监控器合成为一个组合的Web服务。

得益于这种“作为一种服务”的范式，所提出的基于服务的监控系统具有模块化和可扩展性，能够支持新的服务质量属性跟踪。

从战略角度来看，这是一种按需监控。实际上，仅监控用户非功能性需求规格中包含的服务质量属性。客户端不关心其值的属性将不会被监控。此外，这种非功能性需求驱动的监控减少了无用的监控开销（即，如果一个必要需求被违反，则继续监控过程执行将变得毫无意义）。

通常，检测到故障点是有用的，但更重要且更有意义的是在问题发生之前进行检测。因此，建议使用预警系统，在风险情况下立即通知用户。当质量属性值达到指定阈值时，用户将收到通知，并可迅速处理该情况。

此外，提出了一种基于事件的评分策略。换句话说，评分算法仅在风险情况下被调用，即仅当未来可能需要替代Web服务时才触发，这在计算时间方面具有优势，并且与服务质量信息的新鲜度密切相关。同样，在对候选Web服务进行评分时，还结合了用户对服务质量的需求，从而能够提供更准确的结果，并推荐最合适的替代Web服务。

在本研究中，我们将Web服务质量的监控视为基于非功能性需求选择Web服务的一个重要问题。在未来的工作中，将提出一种监控整个组合服务质量的方法。该方法旨在持续确保与最终用户偏好一致的最佳可能组合。