一种可扩展的Web Service QoS管理框架

1、一种可扩展的Web Service QoS管理框架邵凌霜1, 2, 李田1, 2, 赵俊峰1, 2,+, 王亚沙1, 2, 谢冰1, 2, 梅 宏1, 21(北京大学 信息科学技术学院, 北京 100871)2(高可信软件技术教育部重点实验室, 北京 100871)摘 要 Web Service是目前研究界和产业界广泛关注的技术之一。随着Web Service的广泛应用，研究者们普遍认识到,服务的非功能属性,即服务质量(Quality of Service, QoS)是面向服务的应用能否成功的关键因素之一。因此，研究者们尝试从多个角度对QoS相关问题开展研究。然而，现有工作普遍关注考虑QoS的

2、动态服务选择和组装等上层应用技术，而对于如何获取、存储、度量QoS等基础支持技术研究较少，而这些基础性工作对QoS相关的研究工作具有相当明显的重要性。此外，不同应用领域对Web Service QoS的需求不尽相同，因此，需要有一套灵活的机制支持在QoS模型定义、QoS度量方法、QoS信息采集等方面体现出的领域特性。针对这个问题，本文提出了一个可扩展的Web Service QoS信息管理框架，详细分析了该框架涉及到的重要方法与核心技术，并给出了该框架在北京大学软件构件库系统中的设计决策和方案。最后，本文介绍了本框架在一个863计划项目中的应用实例，该实例展示了用户根据其应用的领域需求对本框架

3、进行扩展并进行Web Service QoS管理的方法，从而验证了本管理框架的可扩展性及实用性。 关键词 Web Service，QoS (Quality of Service)中图法分类号 TP311An Extensible Management Framework for Web Service QoS Lingshuang Shao1,2, Tian Li1,2,Junfeng Zhao1,2, Yasha Wang1,2, Bing Xie1,2, Hong Mei1,21(Software Institute, School of Electronics Engineering a

4、nd Computer Science, Peking University, Beijing 100871, China)2(Key Laboratory of High Confidence Software Technologies, Ministry of Education, Beijing 100871, China)+ Corresponding author: Phn: +86-10-62751794, Fax: +86-10-62751792, E-mail: zhaojf, Abstract Web service is emerging as a promising te

5、chnology and attracts many attentions from industry and research domains. With the popularity of service technology, many researchers propose that not only functional but also non-functional properties, also known as quality of service (QoS), should be taken into consideration. Researches have inten

6、sively explored many QoS related problems, such as QoS-aware dynamic service selection and composition, etc. However, existing approaches emphasize on how to make use of QoS information, the technologies on collecting, storing, measuring web service QoS information are not intensively explored. Its

7、obvious that these fundamental technologies are also very important for the successful application of QoS related applications. To address this problem, this paper proposes an extensible QoS information management framework, analyzes the technologies included in this framework, and presents the desi

8、gn decisions and solutions in Software Component Library Project of Peking University. Finally, this paper describes a real case study of applying this management framework in a project of 863 Program. The case study shows that users can extend the management framework and manage Web Service QoS acc

9、ording to their domain-specific requirements, which evaluates the extensibility and practicability of this QoS information management framework. Keywords web service composition; quality of service (QoS); 1引言Web Service是目前研究界和产业界广泛关注的技术之一。随着Web Service的广泛应用，研究者们普遍认识到，服务的非功能属性，即服务质量 (Quality of Servi

10、ce， QoS)是面向服务的应用能否成功的关键因素之一。目前，Web Service QoS方面的研究工作主要分为几个方面：QoS模型定制、QoS属性度量方法的研究、QoS信息获取以及基于QoS的服务选择和组装方法的研究等。在QoS模型及其属性计算方法的研究主要有： Zeng1提出了一个包括执行时间、价格、信誉等在内的五元QoS模型，张静2总结了现有研究中提到的Web Services的QoS属性，如性能、可靠性、可用性、可访问性、兼容性等，提炼出一个Web Service QoS描述模型；Siram等3提出的UniFrame框架给出了描述构件QoS的元模型；杨胜文等4提出的QoS模型则是定义

11、了一组描述Web 服务QoS 属性和信誉度的分类tModel，支持携带QoS 描述信息的服务发布以及基于QoS 约束的服务发现；杨文军等提出了一种领域自适应的Web服务质量评价模型5。郭得科等6提出了宿主结点维、服务维及方法维3维QoS模型，用以支持基于QoS的服务发现。徐明伟等以服务响应时间为QoS参数，验证了一种基于Web Service 的分级QoS方法，提出了目标时间预设模型7。在QoS属性度量方面的研究工作较多,针对某一单个的QoS属性，研究人员就其所处的领域不同提出了多种不同的度量方法。仅就服务可用性（Availability）而言，就有Medvidovic8等提出了基于访问次数度

12、量服务可用性的方法，Zeng等提出了基于时间段度量方法1，Xiong等提出了基于性能指标的度量方法9等。在QoS信息获取方面，Rosenberg等总结了对Web Service进行自动化QoS信息采集的基本方法和技术10，复旦大学的郑奕提出了一种基于API Hook技术的服QoS信息采集方法11，Zeng等提出了监听服务流程并获取QoS信息的方法12。基于QoS的服务选择和组装方法研究方面：陈彦萍等提出了一种在Web 服务组合中基于服务质量的服务选择算法13； Zeng等提出了一种基于线性规划的服务组装方法1；赵俊峰等提出了一种支持领域特性的Web 服务组装方法14；陈彦萍等15提出了一种满足

13、马尔可夫性质的不完全信息下的 Web 服务组合方法等。在上述研究中，研究者们提出了如响应时间（response time）、可靠性（reliability）、可用性（availability）、可访问性（accessibility）、吞吐量（throughput）等众多质量属性，用于度量Web Service的服务质量。在总结这些不同的研究工作中我们发现，针对其特定应用领域，研究者们所关注的QoS属性不尽相同，因而需要建立不同的QoS模型；此外，在不同的应用背景下，研究者们会提出有针对性的QoS属性及其度量方法，如在工作流领域，研究者们就提出应该将流程引擎运行时间和服务执行时间作为两个单独的Q

14、oS属性分开进行度量。上述的研究工作均有一个假设前提，即有一个应用系统（如服务注册中心、服务部署平台或流程引擎）来帮助这些上层应用制定QoS模型、采集并存储QoS信息、并基于这些QoS信息为基础度量Web Service QoS。我们将上述用以支持QoS应用的基础性工作统称作Web Service QoS信息管理。Web Service QoS信息管理的重要性不言而喻。同时，上述这些基础性管理工作之间存在紧密的关联性比如QoS模型的定制，直接决定了QoS信息需要采集的内容；采集到的QoS信息的内容又直接决定了我们可以采用什么样的方式进行QoS属性的度量。同时，我们在实际的开发工作中，又发现We

15、b Service QoS信息管理涉及到大量的技术问题：比如在QoS信息的采集过程中，如何保证采集工具的扩展性与性能；又比如在QoS度量系统中，如何针对Web Service本身的特性选取合理的度量方法。这些问题的合理解决，是成功应用面向服务技术的基础。由此可见，对于QoS信息管理而言，单独考虑一方面的问题容易忽略其它方面，导致整体应用受到影响。我们认为，在上述各方面基础性工作已有一定积累的基础上，我们应该强调QoS信息管理的整体性，综合、全面的考虑QoS信息管理所涉及到的各方面问题。同时，对于QoS信息的管理必须保证一定的可扩展性，方便用户针对其各自领域的不同特点进行扩展。基于这样的思路，本

16、文提出了一个可扩展的Web Service QoS管理框架。该框架包含四各方面研究内容：1） QoS模型的定制，研究如何根据特定领域的需求定义相关的QoS属性、如何描述QoS属性之间的关系、如何定义QoS属性度量方法，2） QoS信息的采集，研究如何全面获取Web Service的运行时QoS相关信息，3） QoS信息的存储，研究如何将获取的Web Service的运行时QoS相关信息进行有效的存储，支持高层应用对这些信息的高效访问，4） QoS度量，解决如何根据已经获得的Web Service运行态数据对Web Service QoS进行度量。文章的整体结构如下：第二节给出了QoS管理框架的

17、整体框架，以及该框架与基于QoS的典型应用（如服务选择和组装）的关系；在后续的三、四、五、六节中，我们分别介绍了QoS管理框架中的几个重要组成部分QoS模型定制、QoS信息采集、QoS信息汇聚和存储、以及QoS信息属性度量。在第七节中，我们给出了该框架在北京大学资源库系统的具体实现，并通过一个实际案例描述该框架在实际系统中应用情况；第八节总结全文并展望下一步的工作。2 Web Service QoS管理框架图表 1给出了一种可扩展的Web Service QoS管理框架，该框架反映了进行QoS管理的系统应具有的通用系统结构。其中，实线框所示的管理框架对由虚线框所示的应用层的相关应用进行支持，应

18、用层则是利用管理层提供的QoS信息进行基于QoS信息的相关应用，如基于QoS的服务选择等。管理框架包括了以下4个部分：QoS模型定制用于定义适应于不同领域需求的QoS模型，该模型可以基于已有的质量模型和特定于领域的质量需求进行定制，同时，模型定制的方法需要考虑良好的可扩展性，以支持不同领域的应用。QoS模型是整个管理框架的基础性工作，因此，需要提供可扩展的QoS模型的定制方法，以支持后继的工作；QoS信息的采集用于采集Web Service在运行时与QoS相关的信息，QoS信息的采集分为请求端QoS信息采集和运行端QoS信息采集。请求端QoS信息采集是指在使用Web Service的用户端进行

19、QoS信息的采集，而运行端QoS信息采集是指在运行Web Service的应用服务器平台上进行QoS信息采集。在请求端与运行端进行QoS信息采集有利于全面获得Web Service运行状态信息。QoS信息的汇聚与存储用于将采集而来的数据进行汇总处理并按某种方式进行存储。QoS信息的汇聚需要考虑使用何种技术接收从采集端发送过来的数据，主要强调性能方面的考虑；QoS信息的存储则是是考虑如何对采集而来的数据进行存储，需要对存储形式、访问效率、开发复杂度等各方面因素做出决策。QoS信息的分析与计算用于根据某种QoS模型和采集而来的QoS信息进行QoS属性的度量与评估。该部分需要根据用户的需求（如时间、

20、范围、度量方法等），从QoS信息存储模块取得相应QoS信息进行分析计算，最终得到Web Service QoS属性的度量结果。图表 1 Web Service QoS管理框架上述四个部分构成了Web Service QoS管理框，下面对于这四个部分进行详述。3 QoS模型定制建立QoS模型是进行Web Service QoS各项研究的基础工作之一。目前有关QoS模型的研究主要集中在如何定义QoS模型的组成，即该模型应该由哪些QoS属性构成，以及相应属性是如何组织的。研究者们提出了大量属性用于度量服务质量，例如响应时间（response time）、可靠性（reliability）、可用性（av

21、ailability）、吞吐量（throughput）等等。在不同的应用背景下，研究者们会提出针对其应用领域的特性，提出有针对性的QoS属性：如在工作流领域，研究者们就提出应该将流程引擎运行时间和服务执行时间作为两个单独的QoS属性分开进行度量16。根据我们以往的总结2，目前已经提出的QoS属性可以分为性能、健壮性、安全性、声誉等几个方面，共计三十多个属性。并且，随着Web Service应用领域的不断深入与扩大，不断会出现新的QoS属性，这就需要QoS模型定制时需要考虑此类扩展需求。面对众多的QoS属性，我们需要有一种较好的方式将它们组织起来。同时，这种组织方式必须有一定的可扩展性，以保证在

22、有新的QoS属性时可以灵活地在模型中对其进行定义。这是定制QoS模型的第一个需求。此外，对于同一个QoS属性而言，其度量方法可能有多种（关于度量方法的多样性，在QoS属性度量小节有更详细的讨论）。以服务可用性（Availability）为例，已有的度量方法包括：1. 基于调用次数的度量方法8Ava = Ns / Na（1）（1）式中Ava表示可用性的计算结果，Ns表示服务调用成功次数，Na表示服务总共被调用次数。2. 基于时间区间的度量方法1，这种方法较为通用，一般用在Web Service在服务器上运行时使用：Ava = Ts / Ta(2)（2）式中Ava表示可用性的计算结果，Ta表示服务

23、被度量可用性的时间段长度，Ts表示服务在Ta这段时间内可用的时间长度。3. 介于上述两者之间的一种方法：该方法假设有一个服务监控设备对服务进行（不确定时间间隔）的调用。若一分钟内若干次调用中有一次调用失败，则将这次调用所在的一分钟视为服务失效时间段；若一分钟内的所有调用均不发生调用失败，则将该分钟均视为服务可用10。其公式如下：Ava = Ts / Tall(3)（3）式中Ava表示可用性的计算结果，Ts表示服务可用的时间段长度，Tall表示监控设备运行的总时间长度。这三种方法各有合理之处，有各自不同的适用场景。因此，用户很可能希望对服务可用性采用多种不同的度量方法进行度量，综合比较其在不同度

24、量方法下的度量结果。也就是说，在用户进行QoS模型定制时，需要在一个特定的QoS属性上绑定多种度量方法。这是定制QoS模型的第二个需求。在我们的以往工作中，我们提出了一种构件服务质量模型（CQSM）。该模型，CQSM是由一组描述构件服务质量的构件服务质量维构成，维是可嵌套的，即可以由下层子维对上层维进行更详细的描述而一个服务质量维最终是由一组服务质量属性构成，服务质量属性是刻画构件服务质量的原子属性，该属性不可再分，即服务质量属性是叶结点，而质量维是分支结点。本文在CQSM基础之上进行扩展，给出一种可扩展的Web Service的QoS模型（WSQM，Web Service QoS Model

25、），扩展后的QoS模型形式如图表 2所示。在该图中，每一个QoS属性可以绑定多种度量方法。在用户需要查看某项QoS属性时，可以任选一种已经绑定的方法并查看在此方法下度量的结果。图表 2可扩展的QoS模型我们采用五元组对这个QoS模型进行描述，WSQM=<CharacterSet,SubCharacterSet,AttributeSet,ValueSet,ComputingRules>其中： CharacterSet是由二元组<CharacterName,CharacterID>构成的集合，其中CharacterName代表WSQM模型最顶层特性的名称，Character

26、ID为该特性的ID号。该ID号是为了便于描述与管理而设定的，每一特性、子特性或属性均有唯一的ID号。 SubCharacterSet是由二元组<CharacterID,SubCharacters>构成的集合，其中CharacterID代表该组子特性所对应的直接父特性名称，SubCharacters则是由二元组<SubCharacterID,SubCharacterName>构成的集合，其中SubCharacterID为该子特性的ID号，SubCharacterName代表子特性的名称。 AttributeSet是由三元组<SubCharacterID,Attrib

27、utes,MetricSet>构成的集合，其中SubCharacterID代表该组属性所对应的直接父特性名称，Attributes则是由二元组<AttributeID,AttributeName>构成的集合，其中AttributeID为该属性的ID号，AttributeName为该属性的名称。这样，CharacterSet、SubCharacterSet和AttributeSet共同定义了WSQM的构成结构。MetricSet则是描述属性绑定了那些度量方法，由二元组< Metric ID,Context >,其中Metric ID 为该度量方法的ID号，Conte

28、xt是描述与特定度量方式相对应的场景信息。 ValueSet是由<ID, Metric ID,Unit,Value >构成的四元组的集合，用以说明属性的具体取值。其中，ID为该WSQM模型中属性的ID号，Metric ID为度量方法的ID号，Unit代表取值的单位，Value代表由ID号所对应的属性具体取值。 ComputingRules是由<Name, Metric_id, AttrbuteName, Description, ClassName, OperationName>构成的五元组的集合，是管理框架中可用的度量方法的集合。在这个五元组中，Name表示该度量方法

29、的名称，Metric_id是这个度量方法的ID号（每一个度量方法都有其唯一的ID号）；Description是对该度量方法的描述；ClassName和 OperationName记录其度量方法对应的类名和操作名。记录度量方法对应的ClassName和OperationName是为了能够使用编程语言的反射机制对度量方法进行调用，从而提高系统的灵活性。 由此，我们给出了一种可扩展的Web Service QoS模型WSQM。基于WSQM，可以根据不同的领域特性进行模型的定制。并且，该模型可以指导QoS信息采集、评估与度量的相关内容。4 QoS信息采集QoS信息的采集机制是面向服务计算的基础技术：只

30、有在全面、准确的获取QoS信息的基础上，才能从根本上保证面向服务的应用系统的质量。QoS属性分为客观QoS属性与主观QoS属性两种。客观QoS属性指可以根据服务运行时数据计算得到数值的属性（如响应时间、可用性等），主观QoS属性指需要用户根据其主观感受进行评定的QoS属性，如服务信誉等。在我们的以往工作中17，我们提出了一种在构件库中，由用户提交与主观QoS属性相关的反馈信息的机制，并给出了相应的反馈管理机制。相对于主观QoS属性，客观QoS属性相关信息的采集、计算、评估等机制更为复杂，因此本文主要关注客观QoS属性。文中如无特别说明，所述QoS信息均针对客观QoS属性。一个具体的QoS信息采

31、集方案必须达到以下几个目标：1. 采集属性的可扩展性：描述服务质量的属性众多，目前国内外学者提出的服务质量属性约有数十个，并且新的质量属性不断的被提出。如何尽可能完整的获取描述这些已经提出的QoS属性所需要的信息，并保持一定的可扩展性，使之能使用未来的需要，采集机制需要完成的第一个目标。2. 采集机制的透明性：因为QoS信息的采集不可避免的要增加Web Service交互各方的负担，因此，首先需要保证的是采集机制必须独立于交互各方的实现机制，不会妨碍这些交互方本身的运行，并可以按照其要求加载/卸载；其次，采集机制应尽可能保持高性能，避免造成交互各方的性能负担。这两点总体来说就是不要影响交互各方

32、的运行，对运行各方透明，这是采集机制的第二个目标。一个完整的服务请求端与服务提供端交互过程大概包括一下几个步骤：1 请求端打包生成请求SOAP消息2 通过网络将SOAP消息发送到服务运行端3 运行端解析SOAP消息4 运行端对SOAP消息进行处理5 运行端生成返回SOAP消息6 运行端将SOAP消息发送回请求端QoS信息采集的基本思路是在上述交互过程中选取合适的位置插装代码，这些代码能够自动采集预先定义好的、交互过程中产生的QoS信息，并将这些信息发送回QoS信息接收服务器进行存储（见第5节）。因此，QoS信息采集的问题可以归结为：1）在何处插桩代码；2）如何插桩这些采集代码；以及3）如何对用

33、户指定的需要采集的信息提供扩展性支持。以下我们根据获取来源的不同，分别讨论在服务运行端和服务请求端的QoS信息获取方法。4.1服务运行端进行的QoS信息采集服务运行端即服务部署的平台。一般而言，这种部署平台会符合一定的规范。本文描述服务运行端QoS信息采集方法基于JAX-RPC 和JAX-WS 规范所提供的“截取器”（Handler）机制。JAX-RPC规定，从服务部署平台收到一条从请求端来的请求，到服务部署平台处理完请求并将返回结果发送出去的过程可以划分为多个“活动”，每个活动的开始和结束时可以定义出多个“时间点”，用户可以自行定义“截取器”并插入到一个确定的时间点上，对服务部署平台的执行情

34、况进行“截取”。举例而言，假设“开始解析请求消息”与“解析请求消息完毕，开始处理请求”为两个时间，那么我们在这两个时间点上分别插入两个截取器，则可以得到服务部署平台解析一条请求消息所花费的时间。“截取器”是服务部署平台上定义用来扩展的、能够在运行时访问服务调用消息（SOAP）的机制。定义这种机制的JAX-RPC规范目前是SOAP服务器所广泛采纳的机制，被Axis、Weblogic等支持。因此本文使用截取器进行QoS信息采集具有适应面广、实现简单的优点。4.2服务请求端进行的QoS信息采集与服务运行端类似，服务请求端的一次Web Service调用过程也可以划分出多个活动，对于请求端的QoS信息

35、采集，我们同样是在这些活动之间进行插桩代码进行的。请求端采集机制的框架如下图所示：图表 3 请求端QoS信息采集图中每一个活动是请求端处理SOAP消息的一个动作，这些动作之间可以定义一些“QoS采集插入点”，每一个插入点上可以加入一些采集的代码。我们使用了类似Eclipse的“扩展点”机制对这些插入点进行维护，并可以在启动时加载这些插入点。为了提供良好的扩展性支持，在插入点的代码插桩可以使用Aspect-Oriented Programming（AOP）机制实现。同时，考虑到目前服务请求端程序一般都根据Service的WSDL自动生成代码框架，如使用Apache的WSDL2JAVA工具自动生成

36、请求端代码。为了对用户采集QoS信息提供较好的支持，我们实现了可以根据WSDL自动生成的、支持QoS信息采集的Service请求端自动生成工具（该工具已开放、可下载 ）。这个工具利用了WSDL2JAVA提供的生成框架，扩展了WSDL2JAVA工具本身的功能：我们在WSDL2JAVA工具生成的代码框架中定义了若干的“QoS信息采集点”，对于每一个扩展点都使用AOP技术插桩进若干代码。这些代码包含了我们对“响应时间”、“异常信息”这样一些基本的SOAP消息处理过程中的信息的采集代码。同样是为了用户方便性的考虑，这项工具实现了自动编译，打包等功能，便于用户使用。当用户需要增加他想采集的信息时，只需找

37、到对应的“QoS信息采集点”，并修改对应的Aspect里的代码即可。需要强调的是，我们增加的采集代码并没有修改原有WSDL2JAVA产生的存根的结构，对于最终用户来说这种变化是透明的，用户可以忽略这种变化而仍按照原有方式编写客户端程序。同时，这种支持生成客户端存根的工具有很多，SOAP容器一般都会提供这种功能，如Weblogic，Xfire等，因此这种方法具有一定的通用性。4.3 QoS信息发送从服务运行端和服务请求端采集的数据，都必须以一定的格式发送回到QoS信息管理框架上。为此，我们定义了QoS信息发送协议。此传输协议格式如图4所示：图表 4 QoS信息发送协议传输的QoS信息中，分为两个

38、部分：数据头和数据体，数据体又由一些数据块组成。类似于HTTP等协议，数据头指明了这条数据的属性信息，而数据体包含了真正的QoS信息。数据头部分的第一个域指明了这条数据的类型：实时数据或缓存数据，实时数据是由采集方实时采集并发送的（即采集一条后立即发送），其数据体往往只有一个数据块；而缓存数据是又采集方采集并在本地缓存后发送的数据（即采集多条后一次发送）。第二个域指明了数据体的长度。数据体由多个数据块组成，一个数据块就是采集端一次采集得到的QoS信息，数据体的每一个数据块中，按照“属性-值”（即property: value）的形式罗列了采集到的QoS信息。这些信息的内容如图表 5所示。图表

39、5列举了可以采集到的若干基本信息，当需要对其进行扩展时，可以依据所定制的QoS模型，使用Ext1和Ext2字段描述新增属性。属性名含义属性名含义User_ID用户ID号IP用户IP地址CollectSource来源（请求端或运行端）Service_ID服务在注册中心的ID号(可选)ServiceURL服务的URLOPERATION调用的操作StartTime调用起始时间EndTime调用结束时间ResponseTime相应时间Input输入信息OutPut输出信息Exception异常信息Ext1扩展字段1Ext2扩展字段2图表 5 从运行端或请求端发送的QoS信息格式5 QoS信息的汇聚和存

40、储QoS信息存储模块主要完成两个任务：1.接收并汇聚由各个采集端（如服务请求端、服务运行端）发送回来的QoS信息，2.将接收到的QoS信息存储起来，并提供外部访问的查询接口。这个部分的主要目标有三个：1.QoS信息接收端必须具有较高的处理效率，能够同时处理大量请求，2.QoS信息存储层提供大容量的存储机制，能够保存所有历史数据，3.QoS信息存储层提供的查询功能应具有较高的效率。以下两节分别就QoS信息的汇聚和存储讨论相关的技术问题，和我们提出的设计方案。5.1 QoS信息汇聚QoS信息汇聚模块主要是提供一个接口，接收从采集端获取的QoS信息。其目标是在有多个客户端同时向服务器发送QoS信息时

41、，能提供较好的并发性能，使得同时到达的QoS信息能尽可能的被处理。在当前的比较成熟的数据传输协议中，应用最为广泛的是基于HTTP的协议（比如servlet）和XML类协议（比如SOAP）。然而，由于他们各自的缺点，这些协议并不适用于我们的场合。首先，这些协议的标准实现是基于传统的Java I/O的，而在本质上，传统Java I/O提供的读写操作都是“阻塞”的，在标准实现中，采取的是“Per thread serves per request（每一个线程处理一个请求）”的请求服务模式18，研究19表明这是一个性能瓶颈；其次，这些协议都是有着特定使用场合，如XML类协议，其结构化的标签结构独立于具

42、体实现，便于交互的各方进行处理，能够提供良好的互操作性，但对于我们应用当中的QoS信息，标签显得多余并且浪费。进一步的实验也印证了我们的观点：我们发现，使用Web Service接口的并发效率相当低。在我们的实验中，我们使用Tomcat 5.1作为Web Server，Axis1.4作为SOAP Engine发布了一个接收QoS信息的接口，实验结果表明这样的环境该接口的吞吐量仅为10个请求/每秒。另一个可以选择的方案是Java NIO技术。从Java1.4开始，Java更加关注性能方面的提高，Java NIO支持对内存缓冲区的直接操作，同时支持真正的非阻塞的I/O19，打破了原有“per th

43、read serves per request”的局限，提高了I/O效率。但是，它的缺点是底层操作过多，实现比较复杂。然而开源项目有效的弥补了这一点。在实现过程中，我们使用XSocket （一个基于NIO的开源框架）实现了一个高吞吐量QoS信息接收接口。5.2 QoS信息存储描述QoS信息的数据量可能非常大：假设一个服务的吞吐量量为10个请求/每秒（Axis支持的服务即是如此），那么1个小时该服务累积的访问次数即为36,000次。在Internet上部署的Web Service越来越多的情况下，所需存储QoS信息也越来越多。因此存储模块所面临的一个重要问题是能将收集到的QoS信息较好的组织和存

44、储起来，并能提供较高性能的访问接口，访问QoS属性度量模块访问。使用数据库管理系统存储QoS信息是第一个可以考虑的方案：数据库管理系统适合结构化存储，可以提供较高的CRUD（增删改查）的效率。但数据库系统并不适用于我们的场景：首先，我们需要存储的QoS信息具有统一的格式，数据操作主要是“增加”和“查询”，“删除”和“修改”操作很少；其次，从扩展性考虑，一旦存储的数据量过大，数据库可能会成为查询的瓶颈；再次，对于数据库提供的其他功能，如并发处理，事务处理等，由于使用场景的局限性，我们也很难利用到这些功能。因此，我们选用了普通的文件存储作为QoS信息存储介质，而存储的内容就是前述接受到的原始QoS

45、信息，其总体框架如图表 6所示。 图表 6 QoS信息存储结构图查询服务QoS信息的请求会包含两方面的查询维度：服务名称和时间跨度。如一个查询请求的语义信息如下：查询“天气预报服务，从1月31日到2月11日（时间跨度）的QoS信息”。根据上述需求，为提高查询的效率，我们制定了两个维度的索引：时间索引和服务名称索引。首先，存储QoS信息的数据文件每天生成一个，并用文件名标识他的时间属性，使用这种方式，既可以避免数据文件过大或过多，又隐含的提供了时间维度的索引。其次，针对所有的数据文件，建立统一的倒排索引文件来索引服务的名称。即，索引文件的每一个条目保存“服务ID-对应文件ID-该文件中该条数据位

46、置”的三元组。基于这样的设计，查询请求在常数时间内就可以定位到所需的数据文件中的对应位置。同时，由于各个服务本身的重要程度和使用频率的不同，查询请求在各个服务之间的分布也会不同。基于这样的假设，我们可以建立数据缓存（图6左端所示）。缓存分为索引缓存和QoS信息缓存两种：索引缓存是将访问频率较高的部分索引信息缓存到内存中，QoS信息缓存是将访问频率较高的QoS数据缓存到内存中（一般以服务为单位）。这样的缓存方案可以较好的减少查询请求访问磁盘的次数。而在我们的设计中，缓存的更新策略是可以被定制的，可以按照不同算法（如LRU，LFU等算法）建立缓存。值得强调的是，无论查询得到的数据是来自数据文件还是

47、缓存，对于外部使用者来说都是透明的，即高层查询API会屏蔽底层的具体实现。6 QoS属性的度量质量属性的度量方法一直都是研究上的热点问题之一。譬如在软件可靠性工程领域，对复杂系统的可靠性系统的度量方法一直都是研究的热点。在Web服务领域，QoS属性的度量研究近年也逐渐呈上升趋势。当前大多数对QoS属性的研究都相对比较简单：如对于可访问性度量，大多基于固定长度时间内中可访问时间的比例进行计算；对于响应时间的度量，是基于一定次数访问的平均响应时间进行度量。然而，在实际的研究工作中，我们发现，一般的QoS属性度量方法不足以全面而精确地描述实际的Web 服务的运行特性，主要有以下两个原因：1. 时间、

48、环境因素。在对服务QoS进行度量时需要考虑时间和环境因素的影响。以可靠性为例，一般定义为系统在一个完整时间间隔之内正常服务的能力，该值常被定义为一个平均值。但是若在特定时间段内故障率较高，而在所计算的“完整的时间间隔”内，故障的出现是不均匀的，那么仅用一个时间间隔的平均值是不足以反映软件可靠性的实际特点；另外一种情况是QoS属性受环境的影响，在不同的网络环境、不同硬件、基础软件等条件下的软件可能体现出不同的运行特性，如在不同数量的并发请求下，系统所表现出的可靠性、响应时间等都可能不同。2. 用户因素。用户因素是指不同用户由于其所处的环境或自身特征的原因，对于相同Service感受到的QoS不同

49、。在单个用户自身未曾对某个服务的QoS进行过度量时，需要考虑其他用户使用该服务时得到的QoS信息。在这种情况下，我们需要考虑用户关联性，帮助用户尽可能准确地评估Web Service服务质量。鉴于此，我们认为，对于Web Service QoS属性的度量，应该考虑到Web Services本身及被度量的QoS属性的特征，考虑时间和用户因素的影响，采用不同的数学模型进行度量。同时，在分析开放的、动态的分布环境下的应用软件的QoS属性时，我们不仅需要考虑对其进行静态度量，同样重要的是需要发现软件QoS属性动态变化的规律与趋势，对服务在短期或长期未来的QoS进行评估。动态预测是大量基于QoS应用的基

50、础（如动态服务选择和组装）。鉴于此，我们认为，对于QoS属性的度量应该是一个具备充分扩展性的框架。这个框架可以在用户定义的时间、环境、用户的因素的需求下，将静态和动态度量分别考虑，最终计算得到QoS度量结果。具体而言，QoS度量模块在管理框架中的所需要完成的功能如下：l 能够对系统中QoS属性度量方法进行维护。即，有权限的用户可以往系统中添加、删除度量方法。l 能够根据用户提交的需求（起始/终止时间、时间段、用户ID、度量方法等）正确调用度量方法并得到计算结果。因此，我们设计了一个可扩展的QoS度量模块。该模块使用Strategy模式保证可扩展性。当用户需要添加一个新的度量方法时，只需根据需求

51、继承合适的父类并完成对应的处理方法即可。添加到QoS管理系统中的QoS度量方法需要提供一定格式的描述信息，保证其对QoS模型定制模块可见，并能够根据用户要求在指定条件下触发。我们可以以下一个五元组描述一个度量方法：<Name, Metric_id, AttrbuteName, Description, ClassName, OperationName>。在这个五元组中，Name表示该度量方法的名称，Metric_id是这个度量方法的ID号（每一个度量方法都有其唯一的ID号）；Description是对该度量方法的描述；ClassName和 OperationName记录其度量方法对

52、应的类名和操作名。在系统中添加了一个新的度量方法后，若希望在QoS属性绑定度量方法时绑定这种方法，只需将该方法的Metric_id添加到绑定度量方法列表中即可。一个被绑定的度量方法，当其被执行的条件满足时，系统根据其描述信息中包含的ClassName和OperationName信息，通过反射机制对其进行调用。这样的设计避免了系统对度量方法“硬编码”的调用方式，方便系统（动态）的添加进一种新的度量方法，有利于提高系统的可扩展性。根据一个确定的度量方法，可以得到一个QoS属性的数值（见图表2）。在很多时候，需要将多个QoS属性进行综合评价，从而获得QoS特性的度量值（图表2）直至获得服务QoS的综

53、合评估值。在我们的以往工作20中，我们提出了一种将各不同QoS属性进行高斯归一化之后进行加权平均的“QoS特性”度量方法。该方法考虑了QoS属性存在正属性和负属性的差别（正属性表示数值越大则服务质量越高的QoS属性，如可用性；负属性表示数值越大则服务质量越低的QoS属性，如响应时间），并且使用高斯归一化能很好的避免特异值（特别大或特别小的值）对计算结果的影响。在本管理框架中对“QoS特性”的度量即采用的这种方法。在本文提到的管理框架中，针对上文提到的考虑“时间、环境、用户”因素的QoS度量，集成了一些本文作者在QoS度量方法方面做出的一些初步尝试，如：文献21提出了一种考虑用户特殊性而进行Qo

54、S预测的方法；此外，我们认为一般来说这样的度量必须考虑每一个QoS属性的特点而单独进行，如文献提出了一种服务可用性的度量模型22（主要考虑服务连续、非连续失效的情况）、文献提出了一种可用性动态预测方法23，文献提出了一种针对响应时间的动态预测方法。这些度量、预测方法已经集成到本文提到的管理框架中。7管理框架可扩展性实例研究本节主要讨论本文阐述的可扩展的Web Service QoS管理框架的在实际项目中的作用，及其定义的扩展性机制的合理性。本实例研究取材于国家863项目“面向软件专业孵化器的分布式公共技术”，本文阐述的管理框架已经被实际应用到该项目中。 “十五”期间，国家863计划在北京、上海

55、、广州等地建立了十三个863软件专业孵化器。为实现互通互连，这些孵化器中的有一个中心节点（部署在北京）和十二个普通节点（部署在各省市的软件园区），中心节点是普通节点实现互联的基础。本期863项目的目标是在上述十三个孵化器在实现互通互连的基础上，帮助软件企业充实并共享分布在不同孵化器的服务资源，保证企业可以高效、方便的获取技术服务。该项目基于SOA技术，本文提出的管理框架作为服务质量度量的重要组成部分被集成到其中。该项目的一个核心需求是：在孵化器各个节点上均部署有提供企业应用系统测试的Web Service，包括请求测试服务、孵化器单位报价服务、浏览测试计划服务等功能。中心节点上部署有一个BPE

56、L流程，该流程将上述服务集成在一起。本文提出的管理框架的实现被用于获取和度量上述服务的服务质量。考虑到应用上性能的需求，上述服务的调用基本为异步调用：即，客户端发送请求后并不等待执行结果，而是直接返回；在服务执行结束后，再将执行结果发送到客户端程序指定的接口上。在该项目的实际开发过程中，提出了一个实际需求：需要计算服务的“业务执行时间”，即完成服务对应的实际业务操作所需要花费的时间。举例而言，孵化器内的企业对孵化器平台请求“提供系统测试方案”服务，从孵化器平台在接收到这个请求开始、直至它成功的完成了一个系统测试方案，这之间的时间间隔即是“业务执行时间”。“业务执行时间”也可以看成是一个QoS属

57、性，对企业用户选择服务而言显得尤为重要。由于服务调用是异步的，因此会产生两条Web服务调用记录：一条是在异步调用时产生，另一条是在异步调用得到返回结果时（也就是服务进行回调时）产生。同样由于是异步调用，这两条记录之中可能包含有若干多条其它服务的调用记录（QoS信息）。要计算这样的两条记录之间的时间差距这样的需求在一开始并没有考虑到。因此，本文提出的管理框架中，从QoS模型的定制、QoS信息的采集到QoS属性度量方法均需要使用到框架中的扩展性机制进行扩展才能满足项目需求。以下分别阐述为适应该项需求，管理框架在各部分中进行的扩展。7.1 QoS模型定义部分对于扩展QoS属性的需求，只需在模型定义中加入一个叶子节点“业务执行时间”；并将在QoS度量模块中加入的“业务执行时间度量方法”绑定到需要度量的服务的Operation对应的度量方法列表中即可（如图表 7所示）。图表 7 扩展模型定制7.1 QoS信息采集部分为度量“业务执行时间”，我们需要在调用服务请求端记录下调用发生的时间和服务执行完成并返回结果的时间。在本项目中实际调用Web服务是部署在中心节点上的BPEL流程，也就是说，BPEL流程也就是我们采集部分的服务请求端。因为项目中采