度量，针对目前QoS度量普遍缺乏系 统支撑的问题做了有效解决；通过采用本系统可以让各个服务开发者不再需要各自单独开 发和实现自己的QoS度量软件，减少了服务开发者的工作，也避免了从服务提供端度量QoS 的不准确性和不可信性问题；最后，针对服务消费者来说，通过第三方的支持，能够客观的、 准确的获得服务的QoS信息，可以为服务用户更好地选择服务提供支持和保证。
【附图说明】
[0019] 图1为本发明一种基于独立第三方的Web服务Qos属性评价系统的架构示意图； 图2为本发明一种基于独立第三方的Web服务Qos属性评价系统的WSDL动态解析流 程TK意图。
【具体实施方式】
[0020] 如图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的 WSDL2 Java工具来调用远程的Web服务，将WSDL文件中定义的数据类型、消息、端口类型、绑 定协议转换成相应的Java类和接口； 服务调用构件，在Web服务调用的客户端Java桩代码生成后，服务调用构件使用Java的反射机制，获得调用服务的方法名、返回类型、参数类型列表，使用现有的负载测试工具 LoadRunner捕获服务调用场景，并通过模拟上千万用户实施并发负载来进行实时性能的监 测； 服务监测构件，服务监测构件监测服务调用的开始时间和终止时间，服务调用 前和调用后的各种时间和状态信息，服务监测构件采用面向方面的程序设计技术 (Aspect-Oriented Programming, A0P)，将对服务的监测设置为方面代码，并将监测代码植 入服务调用代码执行之前和执行之后，收集服务调用前和调用后的时间、状态信息，监测 Web服务动态参数； 结果收集和计算构件，结果收集和计算构件收集来自于服务监测构件监测到的服务的 调用时间和调用状态信息，并且根据服务属性计算模型，计算出服务属性的各个动态参数 指标值，将计算结果存入数据库；所述服务属性的动态参数指标值包括吞吐量、响应时间、 可靠性、可用性和可访问性； QoS动态更新构件，QoS动态更新构件用于对Web服务属性的各个属性值的动态更新，QoS动态更新构件根据历史数据对当前得到的QoS数据进行定期修正和更新，得到最新的 全局Qos属性数据并实时更新到数据库，实时反映出QoS信息的最新变化。
[0021] 本发明一种基于独立第三方的Web服务Qos属性评价系统的工作过程如下： I、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〉 节点内的复杂类型进行递归分析，最终得到复杂参数成员及类型。为方便用户浏览服务信 息、选择服务操作以及后面调用模块的使用，我们将解析出来的服务信息存放到数据库中。
[0022] WSDL动态分析的具体流程请参阅图2所示，第一步：通过服务的URL读出 WSDL的丰艮兀素Definitions, Definition def = reader. readWSDL(null, serviceinfo. getWsdllocationO);根据Definitions元素获得获取唯一标识了该WSDL的目标名称空间 targetNamespace, targetNamespace = def. getTargetNamespace(),这意味着所有在WSDL 文档中声明的名字都属于这个名称空间。
[0023] 第二步：获得在WSDL文档中定义的所有Service对象，Mapservices=def. getServices()，因为一个WSDL可以包含一个以上的Service元素，在Service元素中又包 含若干个Port元素，从port的属性集中可以解析出服务的URL地址信息。Service元素使 用binding属性和WSDL中的Binding元素进行关联。
[0024] 第三步：获得在WSDL文档中定义的所有PortType对象，Mapports=Def. getPortTypesO,此时可以根据Binding元素下定义的portType属性,选择和当前端口类 型相同的绑定，根据绑定名称可以获取服务名称和端口名称，用户选择服务名称和端口名 称，并选择操作名称。
[0025] 第四步：根据用户选择的操作名称，取出Operation元素下的InputMessage和 OutputMessage信息，判断该message的样式，针对包装的文档/文字样式和RPC/文字样式 分别进行相应的处理。
[0026] 第五步：使用使用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对复杂数据类型解析能力的不足。
[0027] 第六步：针对包装后的文档/文字样式，取出Part下的element属性值，在Schema 中依据关键字匹配找到相应的complexType，逐层分析解析出完整的层次结构，最终得到复 杂参数成员及类型。两种样式下的复杂类型解析实质一样，只是在进入Schema查找的次序 以及匹配机制不同。
[0028] 其中WSDL动态分析的第五步和第六步对操作参数的具体解析流程如下：
2、调用数据生成构件的工作过程：调用数据生成构件根据WSDL文档中的描述分别生 成简单数据类型的调用数据和复杂数据类型的调用数据。简单数据类型的调用数据主要 包括字符串型、数值型和布尔型等数据类型，常见的string类型属于字符串型数据类型， int、float、double、integer等类型则属于数值型数据类型。有些原始数据类型有默认的 刻面约束，默认的刻面约束定义了该数据类型本身所允许的值空间，如：数值型的刻面约束 主要是minN和maxN，分别表示数值型值空间的最小值和最大值，布尔型主要包括True和 False两种取值，字符串型没有默认的刻面约束。因为针对的是Web服务QoS属性的度量， 本发明的系统是假设该Web服务已经通过了功能测试，调用数据只考虑有意义的输入数据 构成的集合，简单数据类型的调用数据主要是通过定义一系列符合刻面约束的随机值来生 成。
[0029] WSDL所描述的复杂数据类型主要有choice、all和sequence三种，并分别用 <choice>、〈all>、〈sequence>个标签表示。〈choice〉标签只允许该元素结构中一个子元素 出现且仅出现一次，在生成choice型