一種基于IEC 61968標(biāo)準(zhǔn)接口測(cè)試自動(dòng)化的實(shí)現(xiàn)方法

蔡淵 方連航 陳華軍 楊航

【摘要】介紹了一種IEC 61968標(biāo)準(zhǔn)接口的WebServices自動(dòng)化測(cè)試方法。對(duì)IEC 61968標(biāo)準(zhǔn)接口的WebServices實(shí)現(xiàn)進(jìn)行了介紹，使用Apache CXF作為WebServices的實(shí)現(xiàn)中間件，采用CXF中的攔截器來(lái)實(shí)現(xiàn)可定制的WebServices輸入和輸出展示，可對(duì)WebServices的請(qǐng)求和響應(yīng)消息體進(jìn)行編輯和查看，從而實(shí)現(xiàn)對(duì)IEC 61968 WebServices接口的自動(dòng)化測(cè)試。

【關(guān)鍵詞】IEC61968CX;WebServices攔截器

1.引言

隨首電力信息化系統(tǒng)的發(fā)展，各開發(fā)商為不同的業(yè)務(wù)部門開發(fā)了相應(yīng)的業(yè)務(wù)信息化系統(tǒng)，由于各開發(fā)商所使用的技術(shù)不同、開發(fā)周期不同，沒有采用統(tǒng)一的技術(shù)，從而導(dǎo)致各業(yè)務(wù)系統(tǒng)相互獨(dú)立，業(yè)務(wù)系統(tǒng)間形成數(shù)據(jù)的壁壘，數(shù)據(jù)只能在各業(yè)務(wù)系統(tǒng)內(nèi)流轉(zhuǎn)，從而產(chǎn)生“數(shù)據(jù)孤島”問題，嚴(yán)重阻礙了信息化建設(shè)的開展，容易形成重復(fù)建設(shè)的情況，降低了數(shù)據(jù)作為“資產(chǎn)”的價(jià)值。

“信息孤島”現(xiàn)象不是一個(gè)個(gè)案，在電力行業(yè)乃至信息化行業(yè)內(nèi)普遍存在，為了解決電力行業(yè)內(nèi)的“信息孤島”問題，國(guó)際電力標(biāo)準(zhǔn)委員會(huì)制定了IEC 61970/IEC 61968系列標(biāo)準(zhǔn)。IEC 61970標(biāo)準(zhǔn)中定義了公共信息模型（Common Information Model，CIM[1]）和組件接口規(guī)范（Component Interface Specification，CIS[2]），為各應(yīng)用系統(tǒng)間的交互提供了語(yǔ)義和語(yǔ)法上的依據(jù)。IEC 61970定義的CIS接口采用CORBA（Common Object Request Broker Architecture，CORBA[3]）技術(shù)，技術(shù)門檻較高，且采用緊耦合的方式，適合以高性能進(jìn)行大量數(shù)據(jù)的傳輸，對(duì)于一些通知消息類的小數(shù)據(jù)量傳輸來(lái)說，其結(jié)構(gòu)過于龐大，不利于開發(fā)商的快速實(shí)現(xiàn)，為此IEC 61968標(biāo)準(zhǔn)在IEC 61970 CIM/CIS標(biāo)準(zhǔn)的基礎(chǔ)之上，擴(kuò)展了配電管理部分的CIM模型，并定義了業(yè)務(wù)系統(tǒng)信息交換模型（Information Exchange Model，IEM[4]）和另一種松耦合方式的消息傳遞標(biāo)準(zhǔn)，以當(dāng)前流行的WebServices技術(shù)進(jìn)行實(shí)現(xiàn)。

本文對(duì)IEC 61968標(biāo)準(zhǔn)定義的WebServices標(biāo)準(zhǔn)接口進(jìn)行了介紹，同時(shí)描述了一個(gè)采用Apache CXF[5]實(shí)現(xiàn)的IEC 61968標(biāo)準(zhǔn)接口的測(cè)試方法，采用JAVA編程語(yǔ)言，以CXF中攔截器的方式實(shí)現(xiàn)對(duì)WebServices輸入輸出的攔截，并對(duì)輸入輸出XML[6]內(nèi)容進(jìn)行查看和編輯，可以為不同的要求配置不同的WebServices輸入內(nèi)容，從而實(shí)現(xiàn)IEC 61968標(biāo)準(zhǔn)接口的自動(dòng)化測(cè)試。

2.IEC 61968 WebServices接口

IEC 61968接口可以通過多種技術(shù)方式進(jìn)行實(shí)現(xiàn)，如WebServices、JMS等，本文對(duì)WebServices實(shí)現(xiàn)方式進(jìn)行了說明。

IEC 61968標(biāo)準(zhǔn)定義了一個(gè)通用的接口，并以WSDL[7]的方式對(duì)接口進(jìn)行了規(guī)范化定義，其中WebServices服務(wù)名稱為：Service，該服務(wù)只包含三個(gè)方法：

PublishEvent：事件發(fā)布方法，用于事件通知。PublishEvent方法的輸入?yún)?shù)為EventMessage，返回值為ResponseMessage。

Request：請(qǐng)求方法，用于查詢或更新操作。Request方法的輸入?yún)?shù)為RequestMessage，返回值為ResponseMessage。

Response：響應(yīng)方法，用于對(duì)通知消息的確認(rèn)，或是對(duì)數(shù)據(jù)處理結(jié)果的反饋。Response方法的輸入?yún)?shù)為ResponseMessage，返回值為ResponseMessage。

3.IEC 61968消息結(jié)構(gòu)

3.1 消息頭結(jié)構(gòu)

IEC 61968 Header（消息頭）包含了一些消息基本描述與控制信息。請(qǐng)求、響應(yīng)、事件消息都有消息頭結(jié)構(gòu)。消息頭只有Verb（動(dòng)詞）和Noun（名詞）兩個(gè)必須的字段，其他的字段都是可選的，消息頭包括以下元素：

Verb（動(dòng)詞）：描述要進(jìn)行的動(dòng)作，用來(lái)標(biāo)識(shí)要采取的動(dòng)作類型，如create（創(chuàng)建）、close（關(guān)閉）、cancel（取消）;created（已創(chuàng)建）、closed（已關(guān)閉）、changed（已更改）。IEC 61968標(biāo)準(zhǔn)規(guī)范了一個(gè)動(dòng)詞列表，動(dòng)詞取值只能從動(dòng)詞列表中選擇。

Noun（名詞）：用來(lái)標(biāo)識(shí)Payload（消息有效內(nèi)容）的類型，描述消息的主題。

Revision（修訂）：消息修訂版本號(hào)。

ReplayDetection（重發(fā)檢測(cè)）：這是一個(gè)復(fù)雜元素，包含一個(gè)timestamp（時(shí)標(biāo)）和一個(gè)nonce（隨機(jī)數(shù)）用于防止重發(fā)攻擊。時(shí)標(biāo)由源系統(tǒng)生成表示消息創(chuàng)建的時(shí)間;隨機(jī)數(shù)是一個(gè)序列號(hào)或隨機(jī)生成的字符串（例如UUID），由源系統(tǒng)生成，并且在一天內(nèi)不允許重復(fù)。

Context（上下文）：表示消息上下文，如PRODUCTION（生產(chǎn)）、TESTING（測(cè)試）、STUDY（研究）、TRAINING（培訓(xùn)）等。

Timestamp（時(shí)標(biāo)）：一個(gè)遵循ISO-8601的字符串，表示消息發(fā)送的時(shí)間。

Source（來(lái)源）：消息產(chǎn)生的來(lái)源，系統(tǒng)或組織的名稱，如EMS、GIS。

AsyncReplyFlag（異步應(yīng)答標(biāo)志）：表示應(yīng)答消息是否異步發(fā)送。

ReplyAddress（應(yīng)答地址）：異步應(yīng)答發(fā)送消息的目標(biāo)地址。

AckRequired（確認(rèn)請(qǐng)求）：表示請(qǐng)求的消息是否需要一個(gè)回傳的確認(rèn)消息。

User（用戶）：一個(gè)復(fù)雜結(jié)構(gòu)表示用戶以及相關(guān)的組織，包含一個(gè)UserID（用戶標(biāo)識(shí)）Organization（組織標(biāo)識(shí)）。

MessageID（消息ID）：消息的唯一標(biāo)識(shí)，兩個(gè)消息不允許有相同的MessageID。

CorrelationID（關(guān)聯(lián)ID）：該字段用于將消息連接在一起。該字段可以在請(qǐng)求中提供，因此客戶端可以關(guān)聯(lián)對(duì)應(yīng)的應(yīng)答消息。服務(wù)器段會(huì)將應(yīng)答消息的CorrelationID設(shè)置為源消息的CorrelationID取值。

Comment（注釋）：任何描述性的文字。

Property（性質(zhì)）：復(fù)合類型允許客戶以鍵/值對(duì)的方式擴(kuò)展傳輸?shù)男畔ⅲ粋€(gè)Name（名稱）和Value（取值）。

other（其他）：其他的客戶擴(kuò)展，由開發(fā)商自行定義擴(kuò)展。

IEC 61968標(biāo)準(zhǔn)規(guī)范了一個(gè)動(dòng)詞列表，Verb（動(dòng)詞）只能為下表的取值。

表1 IEC 61968推薦動(dòng)詞表

請(qǐng)求動(dòng)詞 回復(fù)動(dòng)詞 事件動(dòng)詞 使用場(chǎng)景

Get Reply 無(wú) 查詢

Create Reply Created 事務(wù)

Change Reply Changed 事務(wù)

Cancel Reply Canceled 事務(wù)

Close Reply Closed 事務(wù)

Delete Reply Deleted 事務(wù)

Execute Reply Executed 事務(wù)

Request（請(qǐng)求動(dòng)詞）的使用方法如下：

Get用于查詢消息名詞中指定類型的對(duì)象。

Create用于創(chuàng)建消息名詞中指定類型的對(duì)象。

Delete用于刪除對(duì)象，為了維持修訂歷史，有時(shí)目錄系統(tǒng)并不是真正刪除對(duì)象。

Close和Cancel用于與業(yè)務(wù)處理相關(guān)的動(dòng)作，如關(guān)閉一個(gè)工作訂單或取消了控制請(qǐng)求。

Change用于更改對(duì)象，但需注意，當(dāng)通過業(yè)務(wù)規(guī)則進(jìn)行表示時(shí)會(huì)模棱兩可，尤其是在復(fù)雜數(shù)據(jù)集的情況下（復(fù)雜數(shù)據(jù)集一般具有N：1的關(guān)系）。

Execute用于使用操作集進(jìn)行傳輸?shù)膹?fù)雜事務(wù)，可能包含一個(gè)以上的動(dòng)詞。

每個(gè)Request（請(qǐng)求）都使用Reply（回復(fù)動(dòng)詞）進(jìn)行回復(fù)。Event（事件動(dòng)詞）常常是請(qǐng)求的結(jié)果，一個(gè)Create可導(dǎo)致一個(gè)Created事件的產(chǎn)生。事件中使用的動(dòng)詞為相應(yīng)請(qǐng)求動(dòng)詞的“過去式”。

消息頭的定義如圖1所示：

圖1 消息頭定義

3.2 消息請(qǐng)求結(jié)構(gòu)

IEC 61968Request（消息請(qǐng)求）結(jié)構(gòu)只用于請(qǐng)求消息中，用于存放請(qǐng)求消息的請(qǐng)求參數(shù)，請(qǐng)求結(jié)構(gòu)中的元素都不是必須的，在實(shí)際應(yīng)用中可以根據(jù)實(shí)際情況進(jìn)行選用。消息請(qǐng)求結(jié)構(gòu)包括的元素描述如下：

StartTime（起始時(shí)間）：當(dāng)一個(gè)請(qǐng)求需要起始時(shí)間作為過濾條件時(shí)使用。

EndTime（結(jié)束時(shí)間）：當(dāng)一個(gè)請(qǐng)求需要結(jié)束時(shí)間作為過濾條件時(shí)使用。

Option（配置）：名值對(duì)方式，在查詢請(qǐng)求時(shí)可作為過濾條件，可用于規(guī)定超時(shí)時(shí)間或規(guī)范化響應(yīng)模式等，在具體實(shí)現(xiàn)時(shí)作為自定義的擴(kuò)展。

ID（標(biāo)識(shí)）：在查詢請(qǐng)求時(shí)，可以作為過濾條件標(biāo)識(shí)一個(gè)或多個(gè)對(duì)象，可以在“close”、“delete”、“cancel”事務(wù)中標(biāo)識(shí)特定的對(duì)象。每個(gè)ID都有一組屬性，“kind”用于說明標(biāo)識(shí)的類型，如名稱、UUID、事務(wù)ID或其他類型，UUID默認(rèn)采用對(duì)象的mRID屬性取值;如果取值為名稱，“idType”和“idAuthority”需要提供。

Other：其他的自定義擴(kuò)展。

消息請(qǐng)求的定義如圖2所示：

圖2 消息請(qǐng)求定義

3.3 消息回復(fù)結(jié)構(gòu)

Reply（消息回復(fù)）作為對(duì)其他消息的響應(yīng)，包括的元素描述如下：

Result（結(jié)果）：消息回復(fù)的結(jié)果，取值為以下之一：

OK：沒有錯(cuò)誤，返回所有的結(jié)果，“Error”元素不需要。

PARTIAL：部分，返回部分結(jié)果，有一個(gè)或多個(gè)“Error”元素。

FAILED：錯(cuò)誤，沒有返回結(jié)果，有一個(gè)或多個(gè)“Error”元素。

Error（錯(cuò)誤）：錯(cuò)誤描述。

ID（標(biāo)識(shí)）：錯(cuò)誤對(duì)象ID。

Other（其他）：其他的自定義擴(kuò)展。

OperationId（操作ID）：操作ID，與請(qǐng)求的操作相同，用于描述是對(duì)哪個(gè)請(qǐng)求的回復(fù)。

消息回復(fù)的定義如圖3所示：

圖3 消息回復(fù)定義

Error元素描述處理的錯(cuò)誤信息，其元素描述如下：

code（錯(cuò)誤代碼）：用來(lái)描述錯(cuò)誤的類型。

level（嚴(yán)重級(jí)別）：分為：INFORM（信息）、WARNING（警告的）、FATAL（嚴(yán)重的）、CATASTROPHIC（災(zāi)難的）。

reason（錯(cuò)誤原因）：一般為人可讀的錯(cuò)誤名。

detail（詳細(xì)信息）：自由格式描述錯(cuò)誤具體的信息。

xpath（出錯(cuò)路徑）：XPath表達(dá)式標(biāo)識(shí)具體的出錯(cuò)的XML元素，

stackTrace（異常堆棧）：軟件產(chǎn)生的異常堆棧。

Location（異常位置）：軟件產(chǎn)生異常的位置。

ID（事務(wù)ID）：對(duì)應(yīng)的事務(wù)ID。

relationID（關(guān)聯(lián)ID）：出錯(cuò)的關(guān)聯(lián)對(duì)象，用于描述兩個(gè)對(duì)象間的關(guān)聯(lián)出錯(cuò)。

opertionId（操作ID）：與請(qǐng)求的操作相同，用于描述是對(duì)哪個(gè)請(qǐng)求的回復(fù)。

3.4 消息有效內(nèi)容結(jié)構(gòu)

Payload（消息有效內(nèi)容）可以看作是CIM模型的一個(gè)子集，通過定義包含在該消息中的IEC TC57 CIM模型的類和屬性實(shí)現(xiàn)。并不是所有的消息都需要有效內(nèi)容，例如get，close，cancel，reply操作等只需要消息頭，有效內(nèi)容可以為空。

有些類型的消息必須提供有效內(nèi)容，如果帶有動(dòng)詞create或change的請(qǐng)求消息，以及一些響應(yīng)消息和一些事件消息。

有效內(nèi)容一般包含遵循一個(gè)已定義了XSD[8]的XML文檔。

有些情況也會(huì)有例外，例如：一些XML有效內(nèi)容沒有XML Schemas，如RDF文件或動(dòng)態(tài)查詢結(jié)果，還可能是非XML格式，如CSV和PDF。

還有些情況，有效內(nèi)容很大，必須進(jìn)行壓縮，否則將浪費(fèi)大量帶寬。為了適應(yīng)多種格式選項(xiàng)，有效內(nèi)容提供了以下的格式（圖4）：

圖4 消息有效內(nèi)容定義

在消息有效內(nèi)容中，我們可以通過使用XML的“any”結(jié)構(gòu)，來(lái)包含任何類型的XML文件。另外，它也提供了松耦合選項(xiàng)，也能使用由XSD定義的特殊復(fù)雜類型。

一些情況下可能需要zip格式、Base64+編碼的字符串，此時(shí)可在消息中使用“compressed”標(biāo)簽。下列情況需要使用壓縮方式：

一個(gè)遵循XML Schema的有效內(nèi)容，超出了預(yù)定義的大?。ㄈ?，1MB）。這種情況很常見。

具有非XML格式的有效內(nèi)容，如PDF，Excel表格，CSV文件，或二進(jìn)制圖片。

使用XML格式但沒有XML Schema的有效內(nèi)容，超出了預(yù)定義的大?。ㄈ纾?MB）。如作為一個(gè)SQL XML查詢結(jié)果生成的動(dòng)態(tài)XML。

當(dāng)有效內(nèi)容采用Base64編碼的壓縮方式時(shí)，它作為一個(gè)string存儲(chǔ)于compressed消息元素內(nèi)。另外，為了支持二進(jìn)制格式數(shù)據(jù)的高效傳輸，數(shù)據(jù)采用Base64編碼，但不壓縮。如果XML格式不能滿足性能的要求，可以對(duì)數(shù)據(jù)進(jìn)行分類，通過壓縮方式來(lái)實(shí)現(xiàn)“高速”傳輸。

Format標(biāo)簽可以用于標(biāo)識(shí)特定的數(shù)據(jù)格式，比如XML、RDF、SVG、BINARY、PDF、DOC、CSV等。該標(biāo)簽是可選字段，它一般只用于當(dāng)有效內(nèi)容的存儲(chǔ)使用compressed消息元素時(shí)。

4.Apache CXF

Apache CXF是一個(gè)開源的WebServices框架，大大簡(jiǎn)化了WebServices的創(chuàng)建，并可以在多種傳輸協(xié)議上運(yùn)行。采用CXF構(gòu)建WebServices服務(wù)非常方便，通過CXF的工具將WSDL生成為相應(yīng)的JAVA編碼后，只需要編寫少量代碼就可以實(shí)現(xiàn)WebServices服務(wù)的調(diào)用和發(fā)布。作為WebServices客戶端，對(duì)其他WebServices服務(wù)進(jìn)行調(diào)用時(shí)，相應(yīng)的主要代碼如下：首先構(gòu)建代理工廠JaxWsProxyFactoryBean對(duì)象，設(shè)置要調(diào)用的服務(wù)類型Operations和服務(wù)地址，創(chuàng)建相應(yīng)的客戶端對(duì)象client，構(gòu)建相應(yīng)的參數(shù)，調(diào)用相應(yīng)的服務(wù)方法。作為WebServices服務(wù)端，對(duì)外提供WebServices服務(wù)供其他客戶端調(diào)用時(shí)，相應(yīng)的主要代碼如下：首先要實(shí)現(xiàn)對(duì)應(yīng)的WebServices接口方法，通過Endpoint.publish，設(shè)置發(fā)布的地址和實(shí)現(xiàn)的對(duì)象即可。

5.CXF攔截器

通過Apache CXF實(shí)現(xiàn)WebServices的服務(wù)調(diào)用和服務(wù)發(fā)布非常簡(jiǎn)單，這些作用客戶端應(yīng)用進(jìn)行服務(wù)調(diào)用和實(shí)現(xiàn)WebServices服務(wù)器發(fā)布很有用，但作為測(cè)試來(lái)講，只能看到高層的JAVA對(duì)象是不夠的，必須能夠查看底層的消息并可以對(duì)消息進(jìn)行隨意的編輯才能實(shí)現(xiàn)測(cè)試的目的，這可以通過CXF的攔截器來(lái)實(shí)現(xiàn)。

CXF的攔截器是CXF功能最主要的擴(kuò)展點(diǎn)。通過自定義的攔截器，可以改變請(qǐng)求和響應(yīng)的一些消息處理，其中最基本的原理還是一個(gè)動(dòng)態(tài)代理。當(dāng)服務(wù)被調(diào)用時(shí)，一個(gè)攔截器鏈表被創(chuàng)建并調(diào)用。每一個(gè)攔截器都有機(jī)會(huì)做他們想要處理的消息，包括：讀取，轉(zhuǎn)化，處理頭部，驗(yàn)證消息，等。攔截器可以用于CXF的客戶端和服務(wù)端。當(dāng)一個(gè)CXF客戶端調(diào)用一個(gè)CXF服務(wù)端的時(shí)候，客戶端有一個(gè)傳出（Out）的攔截器鏈，服務(wù)端有一個(gè)傳入（In）的攔截器鏈。當(dāng)服務(wù)端發(fā)送響應(yīng)給客戶端時(shí)，服務(wù)端有一個(gè)傳出（Out）的攔截器鏈，客戶端有一個(gè)傳入（In）的攔截器鏈。此外，在調(diào)用出錯(cuò)的情況下，一個(gè)CXF服務(wù)將創(chuàng)建單獨(dú)的對(duì)外輸出錯(cuò)誤處理鏈，客戶端將創(chuàng)建一個(gè)傳入（In）的錯(cuò)誤處理鏈。

創(chuàng)建代理工廠后分別向攔截器鏈表中添加相應(yīng)的攔截器，其中MessageInInterceptor和MessageOutInterceptor分別對(duì)應(yīng)客戶端的傳入攔截器和傳出攔截器。發(fā)布服務(wù)器后分別向攔截器鏈表中添加相應(yīng)的攔截器，其中MessageInInterceptor和MessageOutInterceptor分別對(duì)應(yīng)服務(wù)端的傳入攔截器和傳出攔截器。代碼的主要思想是將原始的消息內(nèi)容XML展示出來(lái)，對(duì)其進(jìn)行修改后，將修改后的內(nèi)容放到消息流中，替換原來(lái)的消息內(nèi)容，在發(fā)送消息時(shí)發(fā)送的就是修改后的消息內(nèi)容。測(cè)試軟件的界面如圖5所示：

圖5 測(cè)試軟件界面

6.結(jié)束語(yǔ)

測(cè)試工具的開發(fā)平臺(tái)是Eclipse 3.6.2，采用Eclipse RCP技術(shù)開發(fā)圖形化界面，使用JAVA開發(fā)語(yǔ)言。這種針對(duì)IEC 61968WebServices標(biāo)準(zhǔn)接口測(cè)試方法，可針對(duì)不同的應(yīng)用場(chǎng)景修改相應(yīng)的測(cè)試消息內(nèi)容，具有很好的通用性，測(cè)試效率高。此種測(cè)試方法沒有考慮IEC 61868 對(duì)Payload定義XSD限制的情況，未對(duì)Payload的內(nèi)容進(jìn)一步的處理，可在此基礎(chǔ)上對(duì)其進(jìn)行改進(jìn)以適應(yīng)更廣泛的測(cè)試要求。

參考文獻(xiàn)

[1]IEC 61970-301 Energy management system application program interface（EMS-API）：Part 301 Common Information Model（CIM）Base[S].2004.

[2]IEC 61970-401 Energy management system application program interface（EMS-API）：Part 401 Component interface specification（CIS）f ramework[S].2005.

[3]OMG.CORBA/IIOP2.3 Specification[S].1998.

[4]IEC 61968-1 Application integration at electric utilities-System interfaces for distribution management-Part 1：Interface architecture and general requirements[C].2003.

[5]CXF，http：//cxf.apache.org.

[6]W3C.Extensible Markup Language（XML）1.0（Fifth Edition）.2008.

[7]W3C.Web Services Description Language（WSDL）1.1.2001.

[8]W3C.XML Schema Part 0：Primer Second Edition.2004.