CN105224296A - 基于独立第三方的Web服务Qos属性评价系统及其评价方法 - Google Patents

Abstract

本发明公开了一种基于独立第三方的Web服务Qos属性评价系统，其包括WSDL解析构件、调用数据生成构件、桩代码生成构件、服务调用构件、服务监测构件、结果收集和计算构件，以及QoS动态更新构件。该系统能够反映出QoS信息的最新变化；为服务双方提供一个客观的、可信的QoS度量数据。

Description

基于独立第三方的Web服务Qos属性评价系统及其评价方法

技术领域

本发明涉及Web服务属性选择领域，尤其涉及一种基于独立第三方的Web服务Qos属性评价系统及其评价方法。

背景技术

当前，Web服务质量属性(QualityofService，QoS)成为了Web服务选择的重要考虑因素。

在传统Web服务属性发布和发现机制中，QoS信息主要由服务提供商来度量和发布。其主要存在以下两个弊端：

一方面服务提供商从服务的运行端对QoS动态参数进行单点监测和度量，但是由于Web服务是面向客户的，服务质量真正的好坏也应该从客户的角度来评价，因此现有服务提供商所发布的QoS数据并不能代表客户端使用服务的真实属性。

另一方面，由于服务提供商之间的竞争激烈，服务提供者为了增加其所提供服务被选择的机会，从而获取更大的利益，往往会发布优于实际值的虚假QoS属性数据。因此，基于QoS的Web服务发布和发现过程中，QoS信息的真实性、客观性、准确性等问题没有保障。

近年来，还有一些研究考虑QoS信息应该由客户端反馈，由服务用户安装监测程序对服务的QoS信息进行主动监测和收集记录，并反馈给服务中心。但是这种方法需要用户紧密地参与到服务质量的度量过程中来，加重了服务请求者的负担，对Web服务客户端应用的自动化程度会造成较大的影响；并且，实际情况更倾向于进行主动反馈的服务消费者很少，且评价频率也很低，这样一来，这些评价就不具有普遍性；另外客户端反馈也是一种主观行为，因此难免存在偏见甚至恶意欺骗，影响服务消费者的决策。

现有技术中还有一些对Web服务的质量属性进行度量的技术和工具，但都存在这样或那样的问题，我们将其列举分析如下：

方法一：基于对SOAP引擎库进行修改的方法来实现对Web服务质量的自动度量。通过修改ApacheAxis的SOAP引擎库，向其中添加监测代码，以便在SOAP请求发送前和接收SOAP响应消息时收集与服务质量相关的数据，并将这些数据通发送给专门的节点以便进行分析和处理，其结果和手工提交的QoS数据一起被用来更新服务注册库中相应Web服务的质量信息。这种方法的缺点是：它与系统平台以及SOAP引擎库的实现紧密相关。其广泛应用需要得到工业界各个厂商的支持，才能将这种修改集成到所有的SOAP引擎库的具体实现中，而且并不是所有的SOAP引擎库都公开源代码。

方法二：基于应用响应度量(ApplicationResponseMeasure,ARM)API对ApacheAxisWeb服务平台上的Web服务执行时间进行度量。通过对ARMAPI调用来指出ARM事务的开始和终止事件，获得Web服务的执行时间。此外，将面向方面编程技术(Aspect-OrientedProgramming,AOP)和ARMAPI结合在一起，用来度量实现具体业务逻辑的后端服务的执行时间。这种方法的优点在于获取活动与系统平台的无关性，但是侧重于在服务端进行度量，该方法需要能访问被度量的Web服务的源代码，一旦度量过程发生改变或者应用程序本身在被度量和独立运行之间进行切换，则整个应用程序都需要进行重新编译和部署。

方法三：基于代理的方法是将Proxy作为Web服务客户端和服务提供端之间通信的桥梁，代理横切服务客户端和服务提供端之间交换的输入输出消息，从而进行服务质量的度量。这个方法要求服务提供端和客户端之间交换的所有SOAP消息对代理来说都是可见的。这个方法的缺点是需要对被监测的Web服务应用程序的源代码进行修改并和配置以便使用Proxy。当面对不开放源代码的Web服务应用程序时，该度量方法就不再体现它的优越性了。

方法四：Web服务质量的度量是通过对底层网络数据包(Packets)进行拦截和捕获来实现的。采用这种方法的核心思想是要捕获含有SOAP请求消息和响应消息的数据包。这种方法优点在于：监测程序与Web服务应用程序的源代码完全分离。缺点就是：监测程序所获取的信息中有很大一部分都是与度量目标无关的数据，需要将它们过滤掉。

终上所述，如果能够研发出一套基于独立第三方的Web服务Qos属性评价系统及其评价方法，Web服务QoS的度量能够由独立于服务提供者和服务用户的第三方进行，第三方模拟客户实际调用Web服务的情形，发送服务调用请求，由监测代码来收集服务的执行状况和各项数据。那么在这种情况下，监测代码不需要获得Web服务的设计和实现细节，跟普通的用户使用服务一样，只要获得Web服务的接口信息即WSDL（WebServicesDescriptionLanguage）文档即可，在获得WSDL文档的基础上实现服务的自动调用、监测和度量。则就可以实现保证Web服务属性的QoS数据的公正性、可信性和客观性。

发明内容

为了解决现有技术中的问题，本发明的目的是开发出一种基于独立第三方的Web服务Qos属性评价系统及其评价方法，该系统提供的Web服务属性的QoS数据具有公正性、可信性和客观性。

为达到上述目的，本发明提供的一种基于独立第三方的Web服务Qos属性评价系统包括以下构件：

WSDL解析构件，用户输入Web服务WSDL文档的URL地址后，WSDL解析构件从UDDI注册库中获得WSDL的描述文档并负责对WSDL文档进行自动解析，通过对WSDL文档进行解析,可以清楚的了解Web服务使用的绑定协议、端口、实现的操作和输入输出的消息以及用到的数据类型信息，所有这些信息存储在数据库中，提供给用户浏览和选择；

调用数据生成构件，调用数据生成构件根据WSDL文档中定义数据类型的模式文件生成调用数据，包括生成简单数据类型的调用数据和生成复杂数据类型的调用数据；简单数据类型的调用数据是通过WSDL文档中定义的数据类型及刻面约束随机生成默认的调用数据；复杂数据类型的调用数据是根据WSDL解析构件得到的数据类型结构，采用相应的策略，生成简单调用数据的集合；所有调用数据生成构件中生成的调用数据都存储到XML文件当中去；

桩代码生成构件，桩代码生成构件从Web服务的WSDL文件动态的生成用来调用Web服务的客户端Java桩代码，进而使用客户端Java桩代码利用Web服务的工具包Axis的WSDL2Java工具来调用远程的Web服务，将WSDL文件中定义的数据类型、消息、端口类型、绑定协议转换成相应的Java类和接口；

服务调用构件，在Web服务调用的客户端Java桩代码生成后，服务调用构件使用Java的反射机制，获得调用服务的方法名、返回类型、参数类型列表，使用现有的负载测试工具LoadRunner捕获服务调用场景，并通过模拟上千万用户实施并发负载来进行实时性能的监测；

服务监测构件，服务监测构件监测服务调用的开始时间和终止时间，服务调用前和调用后的各种时间和状态信息，服务监测构件采用面向方面的程序设计技术(Aspect-OrientedProgramming，AOP)，将对服务的监测设置为方面代码，并将监测代码植入服务调用代码执行之前和执行之后，收集服务调用前和调用后的时间、状态信息，监测Web服务动态参数；

结果收集和计算构件，结果收集和计算构件收集来自于服务监测构件监测到的服务的调用时间和调用状态信息，并且根据服务属性计算模型，计算出服务属性的各个动态参数指标值，将计算结果存入数据库；所述服务属性的动态参数指标值包括吞吐量、响应时间、可靠性、可用性和可访问性；

QoS动态更新构件，QoS动态更新构件用于对Web服务属性的各个属性值的动态更新，QoS动态更新构件根据历史数据对当前得到的QoS数据进行定期修正和更新，得到最新的全局Qos属性数据并实时更新到数据库，实时反映出QoS信息的最新变化。

优选的方案，所述简单数据类型的调用数据包括字符串型的调用数据、数值型的调用数据和布尔型的调用数据。

进一步的优选方案，所述数值型的调用数据包括int的调用数据、float的调用数据、double的调用数据和integer的调用数据。

更进一步的优选方案，所述布尔型的调用数据包括True取值的调用数据和False取值的调用数据。

所述复杂数据类型的调用数据包括choice型的调用数据、all型的调用数据和sequence型的调用数据。

本发明实现了一个独立的、第三方的QoS动态参数度量系统QoS-M（QoSMeasurementsystem）。该度量系统能够对描述服务的WSDL文档进行自动解析；根据解析出的WSDL文档信息自动生成调用服务的调用数据；自动生成调用服务的客户端桩代码；在此基础上，实现Web服务的自动调用；结合面向方面的编程技术，织入服务监测代码直接到Web服务调用代码处，实现对Web服务调用时间和调用状态的动态采集；完成QoS动态参数的计算和存储；并通过QoS动态更新算法对QoS历史信息做定期的计算和更新，以反映出QoS信息的最新变化；为服务双方提供一个客观的、可信的QoS度量数据。

另外，本方发明实现了第三方的QoS动态参数度量，针对目前QoS度量普遍缺乏系统支撑的问题做了有效解决；通过采用本系统可以让各个服务开发者不再需要各自单独开发和实现自己的QoS度量软件，减少了服务开发者的工作，也避免了从服务提供端度量QoS的不准确性和不可信性问题；最后，针对服务消费者来说，通过第三方的支持，能够客观的、准确的获得服务的QoS信息，可以为服务用户更好地选择服务提供支持和保证。

附图说明

图1为本发明一种基于独立第三方的Web服务Qos属性评价系统的架构示意图；

图2为本发明一种基于独立第三方的Web服务Qos属性评价系统的WSDL动态解析流程示意图。

具体实施方式

如图1或图2之一所示，本发明提供的一种基于独立第三方的Web服务Qos属性评价系统包括以下构件：

WSDL解析构件，用户输入Web服务WSDL文档的URL地址后，WSDL解析构件从UDDI注册库中获得WSDL的描述文档并负责对WSDL文档进行自动解析，通过对WSDL文档进行解析,可以清楚的了解Web服务使用的绑定协议、端口、实现的操作和输入输出的消息以及用到的数据类型信息，所有这些信息存储在数据库中，提供给用户浏览和选择；

调用数据生成构件，调用数据生成构件根据WSDL文档中定义数据类型的模式文件生成调用数据，包括生成简单数据类型的调用数据和生成复杂数据类型的调用数据；简单数据类型的调用数据是通过WSDL文档中定义的数据类型及刻面约束随机生成默认的调用数据；复杂数据类型的调用数据是根据WSDL解析构件得到的数据类型结构，采用相应的策略，生成简单调用数据的集合；所有调用数据生成构件中生成的调用数据都存储到XML文件当中去；

桩代码生成构件，桩代码生成构件从Web服务的WSDL文件动态的生成用来调用Web服务的客户端Java桩代码，进而使用客户端Java桩代码利用Web服务的工具包Axis的WSDL2Java工具来调用远程的Web服务，将WSDL文件中定义的数据类型、消息、端口类型、绑定协议转换成相应的Java类和接口；

服务调用构件，在Web服务调用的客户端Java桩代码生成后，服务调用构件使用Java的反射机制，获得调用服务的方法名、返回类型、参数类型列表，使用现有的负载测试工具LoadRunner捕获服务调用场景，并通过模拟上千万用户实施并发负载来进行实时性能的监测；

服务监测构件，服务监测构件监测服务调用的开始时间和终止时间，服务调用前和调用后的各种时间和状态信息，服务监测构件采用面向方面的程序设计技术(Aspect-OrientedProgramming，AOP)，将对服务的监测设置为方面代码，并将监测代码植入服务调用代码执行之前和执行之后，收集服务调用前和调用后的时间、状态信息，监测Web服务动态参数；

结果收集和计算构件，结果收集和计算构件收集来自于服务监测构件监测到的服务的调用时间和调用状态信息，并且根据服务属性计算模型，计算出服务属性的各个动态参数指标值，将计算结果存入数据库；所述服务属性的动态参数指标值包括吞吐量、响应时间、可靠性、可用性和可访问性；

QoS动态更新构件，QoS动态更新构件用于对Web服务属性的各个属性值的动态更新，QoS动态更新构件根据历史数据对当前得到的QoS数据进行定期修正和更新，得到最新的全局Qos属性数据并实时更新到数据库，实时反映出QoS信息的最新变化。

本发明一种基于独立第三方的Web服务Qos属性评价系统的工作过程如下：

1、WSDL解析构件的工作过程：在Web服务自动调用之前，需要使用WSDL解析构件对该Web服务的WSDL文档进行详细分析，找到所需要的具体的操作以及该操作的输入和输出参数的详细数据类型。本发明利用IBM的Wsdl4j来实现WSDL动态分析，WSDL的解析主要针对包装的文档/文字和RPC/文字样式展开。Wsdl4j能生成服务接口对象Definitions，从中可方便地获取所有服务及相应的操作方法信息，这种方法的不足在于面对每一个操作方法的输入输出参数的析取则比较麻烦，因为此时必须考虑参数是复杂类型的情况，必须对其结构成员进行分析。为了弥补Wsdl4j在复杂类型上解析能力的不足，本系统综合了两种方法，首先使用Wsdl4j解析出WSDL文档中的Service、Binding、portType、Message等元素的信息；再使用Castor.jar类包来处理复杂类型结构的解析，此时要使用Castor.jar类包将WSDL根元素下的<types>节点转换成Schema对象，再用Castor.jar包下的类对<types>节点内的复杂类型进行递归分析，最终得到复杂参数成员及类型。为方便用户浏览服务信息、选择服务操作以及后面调用模块的使用，我们将解析出来的服务信息存放到数据库中。

WSDL动态分析的具体流程请参阅图2所示，第一步：通过服务的URL读出WSDL的根元素Definitions，Definitiondef=reader.readWSDL(null,serviceinfo.getWsdllocation())；根据Definitions元素获得获取唯一标识了该WSDL的目标名称空间targetNamespace，targetNamespace=def.getTargetNamespace()，这意味着所有在WSDL文档中声明的名字都属于这个名称空间。

第二步：获得在WSDL文档中定义的所有Service对象，Mapservices=def.getServices()，因为一个WSDL可以包含一个以上的Service元素，在Service元素中又包含若干个Port元素，从port的属性集中可以解析出服务的URL地址信息。Service元素使用binding属性和WSDL中的Binding元素进行关联。

第三步：获得在WSDL文档中定义的所有PortType对象，Mapports=Def.getPortTypes()，此时可以根据Binding元素下定义的portType属性，选择和当前端口类型相同的绑定，根据绑定名称可以获取服务名称和端口名称，用户选择服务名称和端口名称，并选择操作名称。

第四步：根据用户选择的操作名称，取出Operation元素下的InputMessage和OutputMessage信息，判断该message的样式，针对包装的文档/文字样式和RPC/文字样式分别进行相应的处理。

第五步：使用使用Castor.jar类包根据第一步生成的def对象，获得Definition的子元素Types元素的schema集合并获得Schema集合中的每一个Schema，根据当前Schema所对应的对象(org.w3c.dom.Element)：schemaElementt，返回一个标准的Java对象schema。具体过程为：首先通过ExtensilityElement匹配找出types元素下所有含“schema”关键字的元素，此时的元素类型为ExtensilityElement；接下来使用Jdom的DomBuild重新构建ExtensilityElement，同时取出definition下所有的命名空间加入到Element的属性中，此时的元素是Jdom可识别的；最后使用Castor对Jdom可识别的Element进行数据绑定，把Jdom可识别的Element转换成Castor可识别的Element。该第五步的方法避免了由于Wsdl4j对复杂数据类型解析能力的不足。

第六步：针对包装后的文档/文字样式，取出Part下的element属性值，在Schema中依据关键字匹配找到相应的complexType，逐层分析解析出完整的层次结构，最终得到复杂参数成员及类型。两种样式下的复杂类型解析实质一样，只是在进入Schema查找的次序以及匹配机制不同。

其中WSDL动态分析的第五步和第六步对操作参数的具体解析流程如下：

2、调用数据生成构件的工作过程：调用数据生成构件根据WSDL文档中的描述分别生成简单数据类型的调用数据和复杂数据类型的调用数据。简单数据类型的调用数据主要包括字符串型、数值型和布尔型等数据类型，常见的string类型属于字符串型数据类型，int、float、double、integer等类型则属于数值型数据类型。有些原始数据类型有默认的刻面约束，默认的刻面约束定义了该数据类型本身所允许的值空间，如：数值型的刻面约束主要是minN和maxN，分别表示数值型值空间的最小值和最大值，布尔型主要包括True和False两种取值，字符串型没有默认的刻面约束。因为针对的是Web服务QoS属性的度量，本发明的系统是假设该Web服务已经通过了功能测试，调用数据只考虑有意义的输入数据构成的集合，简单数据类型的调用数据主要是通过定义一系列符合刻面约束的随机值来生成。

WSDL所描述的复杂数据类型主要有choice、all和sequence三种，并分别用<choice>、<all>、<sequence>个标签表示。<choice>标签只允许该元素结构中一个子元素出现且仅出现一次，在生成choice型调用数据时，从该元素结构生成的简单调用数据中选取任意一个子元素的任意一个数据作为一个复杂调用数据。<all>标签时允许该元素结构中任意—个子元素以任意的顺序出现一次或不出现。在生成all型调用数据时，先通过随机法决定该元素结构的子元素的出现顺序或不出现，然后再通过随机法选择应当出现子元素的一个简单调用数据。<sequence>标签要求该元素结构中任意一个子元素必须按照规定的顺序出现且仅出现一次，生成sequence型调用数据时，就按照对应子元素的相应顺序生成简单调用数据的有序组合。其中调用数据生成流程如下：

3、桩代码生成构件的工作过程：桩代码生成构件主要是在对WSDL进行自动解析的基础上，通过一定的转换规则完成WSDL文档到相应的JAVA类和接口的映射工作，这样调用Web服务时就可以通过一套标准的应用程序开发接口来实现，调用者不需要考虑Web服务是怎样实现和被访问的，可以摆脱繁琐的具体绑定协议和编程接口，实现对Web服务的透明调用。

桩代码生成构件主要由数据类型映射、端口类型映射、消息映射、绑定协议映射四个部分构成。数据类型映射模块负责生成WSDL文档中输入输出消息部分的数据类型Java类；消息映射模块负责生成封装每个Web服务支持的消息格式的输入和输出消息的Java类，放在相应的包中；端口类型映射负责生成一个Java接口，应用程序通过这个接口访问实际的Web服务；绑定协议映射负责生成一个绑定协议Java类,它定义了一个Web服务的信息格式和协议细节，绑定元素有名称和端口类型属性，名称定义服务的名字，而绑定的端口由端口类型属性定义。WSDL2Java工具是ApacheAxis项目开发的，用于由WSDL文档自动生成Web服务桩代码的工具。它根据WSDL对Web服务的描述，来产生一系列的Java接口和Java类。

WSDL文档中所提供的元素与通过WSDL2Java工具转换后所生成的Java类和接口的对应关系请参阅如下表格：

4、服务调用构件的工作过程：服务调用构件实现对桩代码的调用，调用时需要处理若干个未知项，包括未知的方法名、未知的方法返回类型、未知的参数类型列表、未知的传输协议等。基于以上的动态要求，服务调用构件主要使用Java的反射机制实现。反射使程序代码能够访问装载到Java虚拟机中的类的内部信息，获取已装载类的字段、方法和构造函数的信息，编写处理类的代码，这些类由程序运行时临时确定，而非源代码中事先选定。这使反射成为构建灵活应用的主要工具。

实现时，服务调用构件首先使用Java的反射机制获得一个所需要调用的服务对象实例，包括动态的方法名，动态的参数列表等，接下来从生成的调用数据XML文件中读取参数值为调用参数赋值，实现对Web服务的动态调用。服务调用的主要算法如下表：

服务调用构件实现了对服务的多次调用后，通过收集服务的响应状态，计算可得服务的可访问性、可用性、可靠性、健壮性等非性能QoS数据。对于服务在一定负载下的响应时间、吞吐量、容量等性能相关的QoS数据的获取离不开负载测试工具的支持，负载测试工具首先将一个完整的服务操作调用过程录制下来，自动生成测试脚本，然后通过配置和设计执行场景产生负载，运用数据报回放，模拟多个用户对服务的并发调用，监测服务执行的状态、响应时间、最大负载、吞吐率等。LoadRunner是一种能预测系统行为和性能的负载测试工具，通过模拟上千万用户实施并发，实现对系统的性能测试，LoadRunner由三个部分组成：(1)虚拟用户脚本产生器，(2)压力调度和监控系统，(3)结果分析器。本系统借助于LoadRunner工具，通过创建不同的调用场景，实现对服务的调用和QoS性能数据的收集。基于负载的服务调用的流程如下：

5、服务监测构件的工作流程：服务监测构件采用面向方面的编程技术实现，因为服务监测代码分布在不同的Web服务调用处，为了增加服务监测代码编写的灵活性和可重用性，降低服务监测代码与服务调用代码之间的耦合度，服务监测构件采用AOP技术可以更好的实现关注点的分离，同时监测方面可以根据需要很方便地增加或删除，而无需更改原有的代码，实现系统的灵活部署。服务监测代码是一个个Aspect，这些Aspect内部定义了捕获服务运行信息的advice代码。Aspect内指定了触发代码的切点(Pointcut)，切点匹配服务调用代码内部的各种关键部分，这些部分就是连接点(join-point)。连接点起到在服务执行代码与监控代码间的连接作用。正是这些与某个切入点关联的连接点的启动促使与切入点匹配的advice代码的执行，从而动态地编织起Web服务监测代码和服务调用代码，实现监测目的。对于Web服务调用来说，连接点是监控代码实施的上下文运行环境(context)，即在什么情况下触发编织监控代码的执行，这些情况对应于一个服务操作的调用连接发生，调用活动结束或错误终止。

监测代码主要收集到以下一些服务执行时间和状态信息：①服务实例成功调用（SuccessInvoke），表示服务调用程序启动，服务实例被成功调用。②服务实例失败调用（FailInvoke），表示服务调用程序启动，服务实例没有被成功调用。③服务实例成功完成（SuccessTerminate），表示服务实例被成功调用并执行，执行完毕，返回结果。④服务实例失败（FailTerminate），表示服务实例被成功调用并执行，但是执行中发生错误，未返回执行结果。⑤服务实例正确执行（TrueExecute），表示服务实例被成功调用并执行，执行后返回正确结果。⑥服务实例错误执行(ErrorExecute)，表示服务实例被成功调用并执行，开始执行，执行后返回错误结果。⑦发生服务调用请求的时间(startTime)，表示服务调用事件开始的时刻。⑧服务调用结束的时间(endTime)，表示接收到服务响应的时刻。其中③是⑤与⑥的组合。

服务监测方面的主要代码请参阅如下表格：

6、结果收集和计算构件的工作流程：结果收集构件首先将服务监测构件监测到的服务执行状态和时间信息的最新数据存放到到数据库中；计算构件则根据这些历史监测数据来计算得到该Web服务的QoS动态指标。QoS动态参数的计算方法如下：

响应时间：Web服务响应时间是评估Web服务性能最直观的一个参数指标，它是服务消费者从发出服务调用请求到收到返回的结果或异常所需的时间，一般以毫秒（ms）作为度量单位。对于服务消费者来说，服务消费者只关心它的整体响应时间是快还是慢，而不会关心到底响应时间的哪部份出了问题。因此，本系统把响应时间作为一个整体来计算，不具体考虑其每个组成部分。假设，tb(s)表示服务使用者开始发出调用请求的时刻，te(s)表示外部服务执行完成，返回响应结果到服务使用者端的时刻。则第k次调用服务的响应时间tk(s)可以从发生服务请求到接收服务响应的时间差计算得到，其计算公式为：t _k (s)=t _e (s)-t _b (s)

评估一次web服务调用的响应时间并不能很好的反映服务的性能状况，因此，本系统中反映Web服务响应时间的主要指标包括最大响应时间、最小响应时间和平均响应时间，分别表示在第i个时段中t _i =t _l -t _k >0，Web服务累计调用n次，n次响应时间中的最大值、最小值和平均值。令t _i1 (s),t _i2 (s),….t _in (s)为Web服务在第i个时段中的n次响应时间，则此服务的最大响应时间Rt _max (s,t _i ,n)、最小响应时间Rt _min (s,t _i ,n)和平均响应时间Rt _avg (s,t _i ,n)的计算公式为：

Rt _max (s,t _i ,n)=max(t _in (s)

Rt _min (s,t _i ,n)=min(t _in (s))

可靠性：表示到某时间段内，Web服务被成功调用并执行，执行后返回正确结果的概率。可靠性是通过计算在每过一段时间内服务正确执行的次数与该服务总共被调用的次数两者之间的比率得到。因此，假设在第i个时段中t _i =t _l -t _k >0，Web服务累计调用n次，其中服务实例正确执行的次数为p次，则该Web服务在t _i 时间段内的可靠性的计算公式为：执行结果通常用百分数表示。

Re(s,t _i ,n)=p/n

可用性：表示一个Web服务是否存在或是否已就绪可供立即使用，它表示了服务正常运转的概率。如果一个Web服务可用，则调用该Web服务必定会返回一定结果，不管结果是否正确。可用性通过计算服务在每过一段时间内，请求者收到Web服务响应消息与该服务总共被调用的次数两者之间的比率得到。因此，假设在第i个时段中t _i =t _l -t _k >0，Web服务累计调用n次，其中服务实例成功完成的次数为m次，执行结果通常用百分数表示，则该Web服务在t _i 时间段内的可用性的计算公式为：

Av(s,t _i ,n)==m/n，

可访问性：表示Web服务请求能够被访问的程度，它表示了一个时间点上服务能够被成功的实例化的概率。可用性通过计算服务在每过一段时间内，请求者成功调用Web服务的次数与该服务总共被调用的次数两者之间的比率得到。因此，假设在第i个时段中t _i =t _l -t _k >0，Web服务累计调用n次，其中服务实例被成功调用的次数为q次，执行结果通常用百分数表示，则该Web服务在t _i 时间段内可访问性的计算公式为：

Ac(s,t _i ,n)==q/n

吞吐量：表示Web服务所在的服务器在单位时间内能够处理某个请求的总次数。根据Web服务调用执行相关数据计算吞吐量需要考虑的因素是服务实例成功完成和服务实例失败的次数，因此，假设在第i个时段中t _i =t _l -t _k >0，Web服务累计调用n次，其中服务实例被成功完成的次数为m次，服务实例失败的次数为y次，则该Web服务在t _i 时间段内的吞吐量的计算公式为：

T _r (s,t _i ,n)=(m+y)/(t _l -t _k )。

容量：也称为并发用户数，是指可以同时承载的正常使用服务的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标，因为正常使用服务可以理解为服务可以被正常调用也可以理解指服务服务实例被成功完成。相比而言，服务可以被正常调用作为衡量指标更直观些，而以服务服务实例成功完成作为衡量指标更准确些，因此本系统以并发访问服务，服务实例被成功完成的最大用户数作为容量的计算指标，假设在某个极小的时间段中t _u =t _l -t _k >0，并发调用服务n次，该服务实例成功完成的最大次数为m(m<n)次，则该Web服务的容量的计算公式为：

Cp(s,t _u ,n)=m。

7、QoS动态更新构件的工作流程：随着监测次数的增多和监测时间的推移，QoS数据库中会存入大量的历史QoS动态指标数据，，这些历史QoS数据只代表某个时间段内的QoS信息，要想客观准确的给出当前最新的QoS数据，以反映出QoS信息的最新变化，QoS动态更新构件就需要根据这些历史QoS数据对Web服务的当前QoS信息做定期的计算和更新。

显然使用所有历史数据来计算当前QoS并不合理，因为有些服务可能在历史上很长一段时间性能较差却在近阶段有了长足的进步，在这种情况下，使用所有历史数据会计算出较低的性能，并不能反映服务的真实情况，同时维护所有的历史数据，也会造成巨大的存储与计算负担，而如果仅仅使用很短一段时间内的历史数据，又会出现数据量不足的问题，从而导致计算不够准确。因此QoS动态更新构件对Web服务的QoS当前信息做更新时有两种策略使用，一种是实现可自调节机制，根据实际运行的情况不停修正时间段的选取，从而得到一个较好的计算结果。还有一种是对历史度量信息根据其时间戳进行加权平均值的计算，越新的信息权值越大，越久的信息权值越小，从而突出近期的QoS度量信息对最终结果的影响。本系统综合使用这两种机制，首先只保留一定时间内的度量信息，其次对这些度量信息做加权平均值。这样一来，计算结果就比较准确，而且也无需过分保留历史数据，造成不必要的存储与计算负担。计算时需要考虑三个问题：时间段的选取、需要保留的历史数据量以及加权函数。

首先考虑时间段的选取，每条历史QoS信息都是基于不同的时间段计算得到并被存入数据库的，但是如果仅仅根据定长时间段的监测信息来进行历史QoS信息的计算是不合理的，因为某个时间段内服务调用次数可能很密集，某个时间段内可能没有一次服务调用，因此历史QoS信息的计算在考虑选择时间段的同时还要考虑服务调用次数。因此，选择时间段是主要采用的策略为：

计算时先设置一个固定的时间段t _a =t _l -t _k ，本系统设置为24小时，取出该时间段内服务的调用次数n _i ，判断调用次数n _a 是否大于100，如果n _a ≥100，则在该时间内算出QoS信息，并存储，如果n _a ＜100，则取下一个24小时时间段，t _b =t _m -t _l =24，取出该时间段内服务的调用次数n _b ，判断n _a +n _b 是否大于100,如果n _a +n _b ≥100，则计算出t _k 到t _m 时间内的QoS信息，并作为一个时间段存储，如果n _a +n _b ＜100，则继续取下一个24小时时间段，以此类推，直到累计调用次数大于等于100为止。

接着考虑需要保留的历史数据量，保留所有的数据显然不是合适的选择，因为随着时间的推移，累积数据量会越来越大，而且在加权函数的作用下，久远的数据对最终结果的影响会变得微乎其微，所以保留所有数据并不会提高计算的精确性。本系统在具体实现中，只保留了10个时间段的数据。再久远的数据对最终结果产生的影响忽略不记。

最后考虑加权函数，因为随着时间的推移，离当前时间越久远的时间段计算出的QoS数据反映最新QoS信息的能力越弱，因此本系统使用加权平均的方法计算最新的QoS数据。本系统使用的加权函数如下所示：其中k表示正在被加权的QoS数据与当前最新一条QoS数据的所差的时间段数。选择这一函数的理由有二：一是该函数的值域之和的极限值恰好为1，从而该函数的每个取值都可以直接代表当前时间段的QoS信息对最终结果的影响；二是该函数陡峭的下降曲线比较能反映出较新的数据对最终结果的影响很大，而较为久远的历史数据对最终结果几乎没有影响。这样一来，原型系统就不需要保存很多的历史信息。

根据上面的分析，服务当前QoS信息的计算公式如下：

Rt _max (s)=max(Rt _max (s,t _i ,n)),1≤t _i ≤10

Rt _min (s)=min(Rt _min (s,t _i ,n)),0≤t _i ≤10

其中Rt _max (s),Rt _min (s),Rt_avg (s)分别表示服务当前的最大、最小和平均响应时间，w(k)为加权函数，Re(s)，Av(s),Ac(s),Tr(s),Cp(s)分别表示服务当前的可靠性、可用性、可访问性、吞吐量和容量，t _i 表示存储数据的第i个时间段,t _u 表示第u个极小的时间段。

Claims (6)

1.一种基于独立第三方的Web服务Qos属性评价系统，其特征在于：其包括以下构件：

WSDL解析构件，用户输入Web服务WSDL文档的URL地址后，WSDL解析构件从UDDI注册库中获得WSDL的描述文档并负责对WSDL文档进行自动解析，通过对WSDL文档进行解析,可以清楚的了解Web服务使用的绑定协议、端口、实现的操作和输入输出的消息以及用到的数据类型信息，所有这些信息存储在数据库中，提供给用户浏览和选择；

调用数据生成构件，调用数据生成构件根据WSDL文档中定义数据类型的模式文件生成调用数据，包括生成简单数据类型的调用数据和生成复杂数据类型的调用数据；简单数据类型的调用数据是通过WSDL文档中定义的数据类型及刻面约束随机生成默认的调用数据；复杂数据类型的调用数据是根据WSDL解析构件得到的数据类型结构，采用相应的策略，生成简单调用数据的集合；所有调用数据生成构件中生成的调用数据都存储到XML文件当中去；

桩代码生成构件，桩代码生成构件从Web服务的WSDL文件动态的生成用来调用Web服务的客户端Java桩代码，进而使用客户端Java桩代码利用Web服务的工具包Axis的WSDL2Java工具来调用远程的Web服务，将WSDL文件中定义的数据类型、消息、端口类型、绑定协议转换成相应的Java类和接口；

服务调用构件，在Web服务调用的客户端Java桩代码生成后，服务调用构件使用Java的反射机制，获得调用服务的方法名、返回类型、参数类型列表，使用现有的负载测试工具LoadRunner捕获服务调用场景，并通过模拟上千万用户实施并发负载来进行实时性能的监测；

服务监测构件，服务监测构件监测服务调用的开始时间和终止时间，服务调用前和调用后的各种时间和状态信息，服务监测构件采用面向方面的程序设计技术，将对服务的监测设置为方面代码，并将监测代码植入服务调用代码执行之前和执行之后，收集服务调用前和调用后的时间、状态信息，监测Web服务动态参数；

结果收集和计算构件，结果收集和计算构件收集来自于服务监测构件监测到的服务的调用时间和调用状态信息，并且根据服务属性计算模型，计算出服务属性的各个动态参数指标值，将计算结果存入数据库；所述服务属性的动态参数指标值包括吞吐量、响应时间、可靠性、可用性和可访问性；

QoS动态更新构件，QoS动态更新构件用于对Web服务属性的各个属性值的动态更新，QoS动态更新构件根据历史数据对当前得到的QoS数据进行定期修正和更新，得到最新的全局Qos属性数据并实时更新到数据库，实时反映出QoS信息的最新变化。

2.根据权利要求1所述的一种基于独立第三方的Web服务Qos属性评价系统，其特征在于：所述简单数据类型的调用数据包括字符串型的调用数据、数值型的调用数据和布尔型的调用数据。

3.根据权利要求2所述的一种基于独立第三方的Web服务Qos属性评价系统，其特征在于：所述数值型的调用数据包括int的调用数据、float的调用数据、double的调用数据和integer的调用数据。

4.根据权利要求2所述的一种基于独立第三方的Web服务Qos属性评价系统，其特征在于：所述布尔型的调用数据包括True取值的调用数据和False取值的调用数据。

5.根据权利要求1所述的一种基于独立第三方的Web服务Qos属性评价系统，其特征在于：所述复杂数据类型的调用数据包括choice型的调用数据、all型的调用数据和sequence型的调用数据。

6.根据权利要求1所述的一种基于独立第三方的Web服务Qos属性评价系统，其特征在于：所述桩代码生成构件包括数据类型映射构成、端口类型映射构成、消息映射构成和绑定协议映射构成。