基于SOA的电力应用系统QoS模型的研究

陈小红，孟颖超

(河南省电力勘测设计院，郑州 450007)

0 引言

电力工业的改革将逐步形成以竞价为基础的电力市场，竞争激烈的电力市场必将在能量管理系统(EMS)、电量计量(TMR)系统、广域实时动态测量系统(WAMS)、企业资源计划(ERP)系统以及其他电站自动化系统等多个信息系统间实现数据共享和应用集成。但从电力信息系统的建设现状来看，以“纵向层次多、横向系统多”为主要特征的“信息孤岛”现象较为普遍，缺乏对应用系统的全局视图以及统一的计算平台，很难发挥全局统筹规划和协作的整体优势。“信息孤岛”的主要表现有：相似的系统，功能不尽相同；相似的功能，分散在不同系统；相同的数据，存放在多个不同系统，彼此间不一致；各系统间缺乏联系和有效整合，信息不能共享，业务不能协同开展，信息孤岛问题已越来越制约整个电力系统生产效率的提升。针对以上问题，迫切需要进行各系统之间的资源整合和沟通。

上述需求对信息技术提出了巨大挑战，而近年来在实际需求的牵引下，信息技术也有了长足的发展。Web Services和面向服务的架构(SOA)越来越受到人们的关注，并且在科学计算、制造业、电子政务、电力行业很多领域得到广泛应用。由不同的提供者提供的、可供他人选择和利用的网络服务在逐渐增多。服务数量的不断增加以及服务提供者之间的竞争会产生许多功能相近的服务。目前，基于服务功能信息的服务发现机制，如通用描述、发现与集成服务(UDDI)中的服务发现机制[1]，不能有效地对这些功能相似的服务进行区分。服务使用者不仅要获得满足自己功能要求的服务，还渴望能根据自己的特定需要选择当前情形下最合适的服务，如对一些关键性的任务，使用者倾向于选择可靠性、安全性高的服务，对一些次要的任务可选择价格较低、安全性适中的服务等。

目前已经有很多研究将服务质量(QoS)引入服务描述中，建立基于服务功能信息和QoS信息的服务发现模型。所谓QoS信息不是描述服务能够实现哪些功能，而是描述服务如何实现这些功能，如服务的执行时间、服务的可靠性等[2-3]。目前，一些研究关注于扩展现有的Web Services体系中服务注册、服务发现模型，例如, 在已有的服务提供者、服务消费者、服务注册机构这3个角色的基础上增加QoS保证者角色，从而将服务的QoS纳入服务发现模型中[4]。Web Services一般情况下由第三方服务提供者提供，由于它是在因特网环境下动态调用，服务之间的QoS差异非常大，因此，要想把QoS属性全面引入面向服务的应用系统中，实现基于功能信息和QoS信息的服务发现机制，有必要建立一个QoS描述模型，使得应用系统能获得服务提供商对QoS属性的描述以及服务使用者的QoS属性需求，最终在服务合成时，系统可以更好地选择用户所需的服务。建立这样的描述模型要解决的关键在于：如何根据应用系统的要求，定制QoS属性描述集合，如何描述QoS属性的信息，如何实现基于这些属性信息的服务选取以及如何描述用户的QoS需求。本文将结合一个实际系统建设中有关QoS属性的具体问题，探讨面向服务应用的QoS描述模型的设计、系统支持和应用。

1 PoSOA系统及其QoS描述

PoSOA系统是一个基于SOA的电力综合应用系统，其目标是面向电力用户开发能够提供一站式、集成化的面向服务的综合应用系统，涉及的应用领域众多。服务的提供者遍及各个方面，提供的服务数量众多，不可避免地会存在相当多的功能相近的服务。用户对信息服务的要求千差万别，仅描述功能上的需求不能很好满足用户的需要。因此，有必要在PoSOA应用系统中建立基于服务功能信息和QoS信息的服务选取机制。由于PoSOA应用系统是基于因特网的应用系统，其动态性和不确定性要求我们建立完善的异常处理机制，在异常处理机制中，当某个服务不可用时，要寻找功能相近且能满足用户QoS需求的服务来替换，这种服务的替换也需要QoS属性的支持。因此，在认真分析了PoSOA应用系统对引入服务的QoS属性的要求后，作者提出了一种面向服务应用的QoS描述模型，在该描述模型的基础上，对面向服务的应用系统中的3个角色提供QoS属性方面的支持，并以此为基础在PoSOA应用系统中引入服务的QoS属性，实现基于服务综合信息(包含功能信息和QoS信息)的服务选取和服务替换。

2 面向服务应用的QoS描述模型

2.1 相关工作

在分布式应用系统和面向服务的应用系统中，已经有一些研究工作关注服务的QoS描述和应用。NoFun[5]是一种QoS描述语言，这个描述语言分成3个部分：第1部分是在ISO/IEC 9126规范的基础上确定系统描述的QoS需求集合以及集合元素之间的关系(是一种树状的层次结构)；第2部分是为每个组件的基本属性，即树状层次结构的叶子节点添加QoS信息；第3部分描述系统的QoS需求。NoFun描述语言将抽象模型(ISO/IEC 9126规范)和应用系统的具体描述模型(QoS需求集合)分离，使得应用系统可以较容易定制适合特定应用系统的QoS属性描述集合。QML作为一个通用的QoS建模语言，采用类似接口定义语言(IDL)的方式描述组件的QoS属性。QML描述的QoS信息和应用系统联系比较紧密，较好地将QoS属性信息集成到应用系统中。Web服务提供语言(WSOL)兼容W3C的Web服务描述文件(WSDL)，添加对Web Ser-vices的QoS约束、访问权限以及Web Services之间关系的描述信息。WSOL对Web Services的描述内容比WSDL更加丰富，对Web Services的描述也更加准确，但WSOL没有考虑服务使用者的QoS需求描述。

2.2 QoS描述模型的结构

借鉴NoFun将抽象模型和应用系统具体描述集合分离的思想，结合服务这种新式组件的特性，建立了适应面向服务式应用的QoS描述模型，如图1所示。

图1 QoS描述模型

对一个特定的应用系统而言，其QoS描述模型包括3个部分。

(1)QoS属性描述内容(Content文件的内容)。这一部分主要是确定QoS属性描述的内容属性之间的层次关系以及属性的描述类型。

(2)描述模型内部处理策略(Process文件)。主要针对描述集合中的组合属性描述如何根据其子节点的属性值得到该节点的属性值。

(3)属性匹配算法。为描述结构中的每个属性建立属性值匹配算法。

下面详细讨论这3个方面。

2.2.1 描述集合的定制和属性的描述结构(Content文件)

在这个描述模型中，作者根据文献[4]提出的QoS属性描述范围，结合面向服务应用系统的动态、灵活、变化迅速的特点，设计了一个基本的QoS属性本体。借助QoS属性本体的支持，应用系统的开发人员可以根据应用系统的具体情况选择该本体的一个子集，作为当前应用系统的QoS属性集合。集合中的元素，即QoS属性之间存在树状的层次结构，这个层次结构把集合中的QoS属性分为3种：根节点(QoS)是一个没有实际意义的节点；叶子节点叫作基本属性，服务注册时仅对这些属性赋值；其余节点称作复合属性，这些复合属性的子孙中至少有一个基本属性。然后，在描述类型本体的支持下，为集合中的每个属性建立属性描述结构，这个描述结构主要包括属性名称、属性父节点、属性关联的QoS本体、数据类型及描述单位，比如，对一个特定的属性“服务执行时间”，其描述结构如下：

Usability

2.2.2 描述模型内部处理策略(Process文件)

服务提供商在服务注册时，只允许在基本属性节点上注册QoS属性信息，这样做的目的主要基于两方面的考虑。

(1)如果允许服务提供者在复合属性和基本属性上都注册属性值，由于服务提供者的属性计算策略和应用系统的属性计算策略不可能完全相同，就会造成信息的混乱和浪费。

(2)将描述粒度限制在基本属性，可以有效避免由于描述粒度不同造成的属性描述信息不足。

由于服务提供者仅仅在叶子节点(属性层)注册QoS属性信息，为了得到其他层的QoS属性信息，需要建立描述模型的内部处理策略，可以根据所有属性节点的信息得到子特性以及特性的信息。确定了QoS描述模型的描述内容和描述结构后，系统开发人员要针对每个特性和子特性设计特定的内部处理算法。

2.2.3 属性匹配策略(Match文件)

服务的QoS属性涉及范围比功能属性更广，包含的类型也比较复杂，和应用系统的依赖关系也更加密切。不同QoS属性之间在描述和处理上有明显的差异，即使相同的QoS属性，在不同的应用系统中的描述策略和处理策略也不一样。这种个性化的特点使得我们不能用一种统一的方式处理所有的QoS属性，因此，系统设计开发人员对描述模型中的每个非根节点设计开发特定的属性匹配算法，这些属性匹配算法作为以后基于QoS属性的服务选择的基础。

上述3个文件构成了整个QoS描述模型的主要内容，针对不同应用系统的特点，给这些文件确定具体的描述内容，形成针对特定系统的QoS描述模型。下面就以PoSOA应用系统为例，介绍QoS描述模型的具体实现。

3 QoS描述模型在PoSOA中的应用

3.1 PoSOA系统的QoS描述模型

考虑到服务的QoS属性和应用系统联系紧密的特点，作者根据PoSOA系统自身的特点以及系统面向的用户需求，在QoS属性本体的支持下，设计了该系统的QoS描述结构。PoSOA应用系统面向不同层次的用户，他们对信息服务需求的差异性比较大，但还是有一些共性，他们关心的主要是和服务使用相关的问题。作者根据用户这些共性要求，选择出QoS本体中与服务使用相关的属性，作为QoS描述模型的主要描述内容，同时根据系统异常处理的需要，增加了一些服务可用性方面的内容，这些内容构成了整个系统的QoS属性描述结构(如图2所示)，同时还为每个属性建立其描述方式，最后生成XML格式的描述内容文件(Content文件)。

图2 电力应用系统的QoS描述结构

在该描述结构的基础上，作者对其中的非叶子节点(根节点除外)设计了模型内部处理算法。例如，对子属性有效性，处理算法可以描述如下：如果当前时间在有效时间范围内，有效区域包含电力应用系统的应用范围，有效性为“2”；如果当前时间在有效时间范围内，有效区域不包含在系统的应用范围但是两者有交集，有效性为“1”；如果当前时间不在有效范围内或有效区域和系统的应用范围没有交集，其有效性为“0”。

同时，对描述模型中的每一个非根节点建立属性匹配算法，所有的属性匹配算法都在Match文件中描述。以有效时间为例，在描述模型中，有效时间的数据类型是一个区间类型{start, end}，其属性匹配算法如下：

UsefulLife_Match(String c_time){

if (c_time.compareTo(UsefulLife.start)>=0){

if(c_time.compareTo(UsefulLife.end)<=0)

return true;}

else return false}

3.2 PoSOA系统中QoS属性相关工具集

要在PoSOA应用系统全面引入QoS属性作为服务选取的辅助手段，在已确定的QoS描述模型的基础上，对SOA中的3个基本角色提供相关工具支持，如图3所示。这些工具主要包括QoS属性注册工具、QoS需求描述工具以及基于QoS属性的服务选取工具。

3.2.1 QoS属性注册工具

在PoSOA应用QoS属性描述模型中，所有的属性层节点(也就是树结构的叶子节点)可以分为3类：第1类属性必须由服务提供者提供初始值和属性更新，这类属性包括执行时间、有效时间、有效区域、安全等级、服务使用价格、服务执行价格、服务版本及服务提供商；第2类属性由服务提供者提供初始值，由应用系统进行属性更新，这类属性包括恢复时间、访问时间及反馈时间；第3类属性由应用系统提供初始值，并由系统进行信誉等级、客户评价等级及出错概率等属性的更新。由于服务提供者只关注前2类属性的注册，因此从中抽出第1类和第2类属性，按照描述内容的层次结构形成服务使用者非QoS注册模型，并要求服务提供者根据这个注册模型，填入相应的属性值以及描述类型。注册完成之后，形成一个独立的XML格式的服务QoS属性描述文件，该文件和WSDL[6]一起完成对服务的描述。

图3 QoS描述模型对SOA的3种角色的支持

3.2.2 QoS需求描述工具

考虑电力应用用户需求多样性的特点，作者在QoS描述模型的基础上，为服务使用者设计了可灵活定制的QoS需求描述模型。QoS需求描述模型的描述内容和描述结构与QoS属性描述模型一致，不同之处有2点：(1)在QoS需求模型中，所有节点只包括属性名称、属性语义信息和属性描述类型，不包含内部处理策略以及属性匹配策略；(2)服务使用者可以在描述模型的任何非根节点提出QoS需求，不只限制在属性节点层次。这个需求描述模型不但能使服务使用者比较灵活地描述自己的QoS需求，而且它和QoS描述模型在结构上的相似可以降低应用系统在处理QoS需求时的难度。

在这个需求描述模型基础上，服务使用者可以根据自己的需要，选择自己的QoS需求描述的属性集合，提出自己对服务QoS属性的要求。最后根据系统提供的工具生成XML格式的QoS需求描述文件。

3.2.3 基于QoS属性的服务选取工具

在PoSOA应用系统中，首先根据服务的功能属性，得到一个满足用户功能需求的服务初选集合。在这个集合中，通过解析用户的QoS需求描述文件和服务提供者QoS注册描述文件，结合描述模型中的每个属性的匹配算法，选择出满足用户QoS需求的那些服务并根据用户或系统设定的属性优先级别将这些服务排序，形成服务的候选队列，作为执行服务的依据，同时还可以在出现异常时作为服务替换的依据。

4 结束语

本文提出了一种基于SOA应用的QoS描述模型，并在电力应用系统中实现了该描述模型以及相关处理工具。在PoSOA系统中的基于语义的服务组合中引入QoS属性作为服务选取的重要辅助手段，有效地实现了功能相近服务的区分，使得服务的选取更加具有针对性；同时，还为电力应用系统中异常处理机制中的服务替换问题，提供了一个解决途径。

在下一步工作中，作者希望在QoS描述模型的基础上，借助本体技术的支持实现服务提供者对QoS属性注册的定制，这种定制包括注册的内容、属性的描述结构等。

参考文献：

[1]RICHARDS R.Universal description,discovery and integration of Web services(UDDI)[M]//Pro Php Xml & Web Services.State of Texas：Springer-Verlag，2006:751-780.

[2]CHUANG L，NIXON B A,YU E,et al.Non-functional requirements in software engineering[M].Boston：Kluwer Academic Publishers,1999.

[3]CAMPBELL A,COULSON G,HUTCHISON D.A quality of service architecture[J].Computer Communications Review,1994,24(2):6-27.

[4]RAN S P.A model for web services discovery with QoS[J].ACM SIGecom Exchanges,2003,4(1):1-10.

[5]BOTELLA P,BURGUES X,FRANCH X,et al. Modeling non-functional requirements[C]//Proceedings of Jornadas de Ingenieria de Requisitos Aplicada, Sevilla:2001.

[6]TIAN M,GRAMM A,NAUMOWICZ T,et al.A concept for QoS integration in Web services[C]// Rome：Web Services Quality Workshop and Wise,2003：149-155.