徐京京 馬素霞 王海威
(華北電力大學(xué)控制與計算機(jī)工程學(xué)院 北京 102206)
《2018~2023年中國電能質(zhì)量治理產(chǎn)業(yè)市場前瞻與投資戰(zhàn)略規(guī)劃分析報告》近日由中國前瞻產(chǎn)業(yè)研究院發(fā)布,據(jù)預(yù)估,今年我國電能質(zhì)量治理市場規(guī)模預(yù)計將達(dá)1187億元,并且此后將保持每年百億元的穩(wěn)定增長態(tài)勢。隨著風(fēng)電、光伏發(fā)電等可再生能源發(fā)電的快速發(fā)展,電氣化鐵路、城市軌道交通建設(shè)的加速,新能源汽車充電樁的大規(guī)模使用和各種新型電子設(shè)備的出現(xiàn),由此產(chǎn)生了一系列新的電能質(zhì)量問題,也加劇了以往一些長期存在的電能質(zhì)量問題。在此背景下,電能質(zhì)量智能信息系統(tǒng)在電網(wǎng)資源全面數(shù)字化、數(shù)據(jù)傳送及共享等方面將面臨更嚴(yán)峻的考驗。
為實現(xiàn)數(shù)據(jù)在國家電網(wǎng)及其各子公司間的流轉(zhuǎn)、共享,加強(qiáng)國網(wǎng)系統(tǒng)與各監(jiān)測終端廠商設(shè)備實時、準(zhǔn)實時和非實時通訊,提出建立統(tǒng)一的數(shù)據(jù)交換通道和據(jù)交換規(guī)則,使得來自不同系統(tǒng)、不同數(shù)據(jù)格式的數(shù)據(jù)能夠進(jìn)行上傳訪問、共享[1]。經(jīng)過探索,Web服務(wù)在解決這一問題上表現(xiàn)突出。不同監(jiān)測設(shè)備廠家通過Web服務(wù),將監(jiān)測終端采集到的數(shù)據(jù)提供給電能質(zhì)量智能信息系統(tǒng)等分析設(shè)備;電能質(zhì)量智能信息系統(tǒng)對個數(shù)據(jù)指標(biāo)進(jìn)行分析計算,將結(jié)果以Web服務(wù)的形式上傳到國網(wǎng)監(jiān)測平臺,其他用戶也可以從服務(wù)獲取分析數(shù)據(jù),做可視化展示等二次應(yīng)用開發(fā)[2~3]。
Web服務(wù)的良好表現(xiàn)使得其得到越來越多的關(guān)注,應(yīng)運(yùn)而生的是多種多樣的服務(wù)描述方式、服務(wù)傳輸協(xié)議、服務(wù)框架等,服務(wù)的多樣性使其不可避免地存在語法、語義、描述結(jié)構(gòu)異構(gòu)的問題[4]。服務(wù)的多樣性同樣給用戶端調(diào)用服務(wù)帶來了很大的挑戰(zhàn)[5]。作為服務(wù)的請求者和生產(chǎn)者,電能質(zhì)量智能信息系統(tǒng)為國網(wǎng)監(jiān)測平臺提供服務(wù)接口,同時調(diào)用解析不同設(shè)備廠家提供的服務(wù)。在實際與廠家對接的工作中,總是在接口聯(lián)調(diào)上耗費(fèi)巨大的精力,因此,采用更加通用和自動化的服務(wù)檢測訪問方法是十分有必要的[6~7]。針對這一問題,本文研究了面向多監(jiān)測終端廠家服務(wù)的調(diào)用方法將面向不同廠家的調(diào)用方法集成,根據(jù)用戶請求某廠家數(shù)據(jù),通過Web服務(wù)調(diào)用,自動匹配調(diào)用服務(wù),返回XML結(jié)果。它提供一套調(diào)用接口,用戶無需了解Web服務(wù)的具體內(nèi)容和差異,并且允許以類似的方式調(diào)用各種設(shè)備廠家開發(fā)的Web服務(wù)。
目前主流的Web服務(wù)風(fēng)格有兩種,一種是RPC(Remote Procedure Call,遠(yuǎn)程過程調(diào)用)風(fēng)格的,還有就是REST(Representational State Transfer,表現(xiàn)層狀態(tài)轉(zhuǎn)化)式的[8]。遠(yuǎn)程過程調(diào)用風(fēng)格的兩大代表是XML-RPC和大Web服務(wù)。盡管XML-RPC的應(yīng)用依然存在,作為一種遺留技術(shù),已被SOAP取代[9]。
REST風(fēng)格比RPC風(fēng)格輕量且響應(yīng)快。RPC請求都是HTTP協(xié)議的POST方法,其方法信息協(xié)議包含在SOAP協(xié)議包或HTTP協(xié)議包中。REST方法信息存在于HTTP方法中(如GET、PUT),無需引入SOAP消息傳輸層。相比之下RPC方法的通用性差一些。從服務(wù)的作用域方面看,RPC包含于協(xié)議包中,不能直觀看到,而REST采用URI顯示定義作用域,更加直觀明了。RPC風(fēng)格的關(guān)注服務(wù)器到客戶端之間的調(diào)用,不關(guān)注基于哪個網(wǎng)絡(luò)層的協(xié)議,這種面向方法的調(diào)用過程對應(yīng)的是REST的面向資源狀態(tài)的調(diào)用。目前主流的框架有SUN的JAX-WS,Apache的CXF、Axis1、Axis2、Wink,Jboss RESTEasy,Dubbo等。適用于SOAP風(fēng)格的框架有RESTEasy、Wink、CXF、Axis2;適用于SOAP的框架有Xfire、Axis2、CXF、Axis1等。
REST數(shù)據(jù)格式可以為HTML、XML、Json格式,根據(jù)國際電工委員會(IEC)發(fā)布的IEC6970系列國際標(biāo)準(zhǔn)中應(yīng)用最為廣泛的XMLWeb服務(wù)組建模型[10],本文所解析的均為XML格式數(shù)據(jù)。
RESTful(REST式的)Web服務(wù),定義了數(shù)據(jù)CRUD(Create Read Update Delete,增查改刪)的元操作,與之對應(yīng)的HTTP方法是GET(獲取資源),POST(新建資源也可以用于更新資源),PUT(更新資源),DELETE(刪除資源),通過HTTP方法,就可以完成對數(shù)據(jù)的增刪查改操作。由于研究服務(wù)調(diào)用方法,本論文主要關(guān)注GET從服務(wù)器取出資源(一項或多項)和POST在服務(wù)器新建一個資源[11~12]。
RESTful架構(gòu)風(fēng)格所有的資源,都可以通過URI定位,每個資源至少有一個URI與之對應(yīng),最典型的URI即URL,而且這個定位與其他資源無關(guān),也不會因為其他資源的變化而改變。
基于SOAP+WSDL的Web服務(wù)允許不同種類的應(yīng)用程序通過標(biāo)準(zhǔn)HTTP協(xié)議調(diào)用服務(wù)生產(chǎn)者發(fā)布的服務(wù)方法。在二進(jìn)制層操作是過去大部分遠(yuǎn)程調(diào)用技術(shù)都要求的。而Web服務(wù)通過使用SOAP、HTTP、XML等組件,隔離服務(wù)請求方和服務(wù)提供方,利用服務(wù)接口連接雙方,服務(wù)實現(xiàn)與接口分離,調(diào)用方無須了解服務(wù)提供者方法的具體實現(xiàn)細(xì)節(jié),因此Web服務(wù)是較為松散耦合的,基于SOAP服務(wù)的數(shù)據(jù)交換是以XML格式通過HTTP進(jìn)行,調(diào)用服務(wù)的方式有靜態(tài)、半自動、動態(tài)方式[13]。
以往在服務(wù)請求方調(diào)用Web服務(wù)之前,需要掌握接口參數(shù)、綁定類型與方式、所需調(diào)用服務(wù)的功能等信息,通過輸入固定類型的消息參數(shù)對服務(wù)進(jìn)行調(diào)用。用戶請求端需要人為的對WSDL進(jìn)行解析,確定所需要的服務(wù)的功能,特別是服務(wù)調(diào)用參數(shù)及其類型,在調(diào)用服務(wù)時,封裝這些消息參數(shù),調(diào)用所需要的方法,發(fā)送請求到服務(wù)器端,這種調(diào)用服務(wù)的方式是靜態(tài)綁定的方式,弱化了服務(wù)松散耦合的優(yōu)點(diǎn)[14]。因此,增加服務(wù)請求方和服務(wù)提供方耦合,使得一旦服務(wù)提供者更改服務(wù)的某些細(xì)節(jié),請求方不得不重復(fù)修改、解析讀取來保證自己的程序不出錯。為了降低耦合,降低人力成本,本文采取動態(tài)綁定與調(diào)用SOAP服務(wù)的方法。
對于面向資源的RESTful風(fēng)格服務(wù),需要使用URI協(xié)議標(biāo)識各個資源并發(fā)布出接口,服務(wù)請求者訪問所請求的資源需要訪問具有指定性和描述性的標(biāo)識,經(jīng)由HTTP,實現(xiàn)資源的表述從服務(wù)器到用戶端的轉(zhuǎn)移。
圖1 調(diào)用RESTful服務(wù)圖
SOAP服務(wù)是面向方法調(diào)用過程的,相比靜態(tài)調(diào)用方法需要提前約定服務(wù)功能、接口參數(shù)、綁定類型,動態(tài)訪問盡量減少人為參與,即無需了解WSDL中參數(shù)的結(jié)構(gòu)和定義,而是事先建立一個相關(guān)知識庫,根據(jù)請求設(shè)施約束,匹配所訪問的方法。
調(diào)用流程如圖2所示。
1)請求服務(wù)。
2)請求信息經(jīng)匹配器處理,生成用戶請求。
3)從知識庫提取服務(wù)描述,將兩個描述進(jìn)行匹配。
4)選擇適合的綁定類型、端口。
5)對WSDL描述的服務(wù)參數(shù)和用戶提供的服務(wù)參數(shù)進(jìn)行映射。
6)調(diào)用操作的名稱以及操作需要的一個輸入消息進(jìn)行調(diào)用。
7)返回調(diào)用結(jié)果。
圖2 調(diào)用SOAP服務(wù)圖
如圖3所示,面向多監(jiān)測終端廠家服務(wù)的調(diào)用方法將面向不同廠家的調(diào)用方法集成,根據(jù)用戶請求某廠家數(shù)據(jù),通過Web服務(wù)調(diào)用模塊,自動匹配調(diào)用服務(wù),返回XML結(jié)果。對應(yīng)地,本方法主要提供給國網(wǎng)電能質(zhì)量智能信息系統(tǒng)與各監(jiān)測終端廠家,進(jìn)行數(shù)據(jù)對接,返回的XML,經(jīng)解析存入電能質(zhì)量智能信息系統(tǒng)PQES數(shù)據(jù)庫。
圖3 系統(tǒng)物理結(jié)構(gòu)圖
服務(wù)是一種安全且降低耦合數(shù)據(jù)對接方法,然而不同的廠家有著不同開發(fā)能力和開發(fā)習(xí)慣,進(jìn)行數(shù)據(jù)服務(wù)接口對接又弱化了服務(wù)的優(yōu)點(diǎn)。根據(jù)上述描述可以看出,Web統(tǒng)一對接問題是普遍存在且急需解決的問題。本文研究了面向多監(jiān)測終端廠家服務(wù)的調(diào)用方法將面向不同廠家的調(diào)用方法集成[15],根據(jù)用戶請求某廠家數(shù)據(jù),通過Web服務(wù)調(diào)用,自動匹配調(diào)用服務(wù),返回XML結(jié)果。它提供一套調(diào)用接口,用戶無需了解Web服務(wù)的具體內(nèi)容和差異,并且允許以類似的方式調(diào)用各種設(shè)備廠家開發(fā)的Web服務(wù)。目前測試的服務(wù)數(shù)量還比較有限,下一步的工作是集成更多的服務(wù)調(diào)用方法。