基于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.