宋文婷，趙建新，艾 冰，高騰飛

（北方自動(dòng)控制技術(shù)研究所，太原 030006）

0 引言

軍用指揮軟件在指揮信息系統(tǒng)中起著舉足輕重的作用。大型指揮軟件涉及到指揮業(yè)務(wù)、態(tài)勢(shì)感知、組織籌劃、情報(bào)偵察、綜合保障、網(wǎng)絡(luò)通信等方面[1]，這些功能通常并行開(kāi)發(fā)，再統(tǒng)一集成。.NET平臺(tái)自被微軟推出后，依靠其跨語(yǔ)言、跨平臺(tái)、提供面向?qū)ο箝_(kāi)發(fā)支持的優(yōu)勢(shì)，逐步取代了Win32 API在Windows桌面開(kāi)發(fā)中的顯赫地位，成為未來(lái)大型軍用指揮軟件開(kāi)發(fā)的重要平臺(tái)。

在.NET平臺(tái)傳統(tǒng)開(kāi)發(fā)模式中，各功能模塊在集成時(shí)需部署在一起，缺乏模塊調(diào)用的統(tǒng)一機(jī)制，易造成依賴混亂；公用模塊重復(fù)開(kāi)發(fā)，資源浪費(fèi)；模塊間耦合度高，牽一發(fā)而動(dòng)全身；系統(tǒng)可擴(kuò)展性差，成為制約大型軍用指揮軟件團(tuán)隊(duì)開(kāi)發(fā)的瓶頸問(wèn)題，急需設(shè)計(jì)在.NET平臺(tái)下支持并行開(kāi)發(fā)、模塊間松耦合、組件重用性高、便于擴(kuò)展的插件機(jī)制。

插件是可以獨(dú)立開(kāi)發(fā)、部署的單元，可以動(dòng)態(tài)地安裝到運(yùn)行容器中，在不修改應(yīng)用主體的情況下擴(kuò)展原有系統(tǒng)的功能，而不對(duì)其產(chǎn)生影響。采用插件機(jī)制能夠快速分解和解決問(wèn)題、實(shí)現(xiàn)應(yīng)用功能、方便版本管理，能夠針對(duì)特定需求定制功能集合、簡(jiǎn)化用戶界面、減少內(nèi)存耗費(fèi)，提高指揮軟件的易用性和高效性[2]。

.NET平臺(tái)上的插件機(jī)制，以微軟推行的解決方案為主[3]，包括組件對(duì)象模型（COM）、動(dòng)態(tài)鏈接庫(kù)（DLL）、MEF、MAF、SharpDevelop 等。COM 組件技術(shù)及DLL方式缺乏對(duì)插件的統(tǒng)一管理功能、插件間調(diào)用方式單一、軟件規(guī)模達(dá)到一定程度容易出現(xiàn)邏輯混亂，無(wú)法滿足大型指揮軟件系統(tǒng)的開(kāi)發(fā)；MEF、MAF、SharpDevelop技術(shù)在插件動(dòng)態(tài)加載方面不足，不支持“即插即用”。

本文采用OSGi（全稱(chēng)：Open Service Gateway Initiative，開(kāi)放服務(wù)網(wǎng)關(guān)規(guī)范）[4]規(guī)范在.NET平臺(tái)實(shí)現(xiàn)插件的加載與管控，將功能模塊設(shè)計(jì)為擁有獨(dú)立目錄結(jié)構(gòu)、相互隔離、可以“即插即用”的指揮軟件插件，滿足大型軟件團(tuán)隊(duì)并行開(kāi)發(fā)、插件化調(diào)用、擴(kuò)展方便的要求。

1 基本原理介紹

OSGi一方面指OSGi Alliance組織，另一方面指該組織制定的基于Java語(yǔ)言的服務(wù)規(guī)范——OSGi服務(wù)平臺(tái)。該平臺(tái)支持模塊化與插件化、具有熱插拔與動(dòng)態(tài)特性、支持SOA、支持插件擴(kuò)展、提供安全性等[6]。OSGi與現(xiàn)有插件技術(shù)對(duì)比見(jiàn)表1。

OSGi插件結(jié)構(gòu)在形式上分獨(dú)立的宿主程序和多個(gè)互不相關(guān)的功能插件，各部分能夠共同形成一個(gè)邏輯上的完整系統(tǒng)[7]。宿主程序完成基本系統(tǒng)功能，可以加載多個(gè)不同的功能插件，接受插件提供的服務(wù)并提供給用戶，是整個(gè)插件系統(tǒng)的基礎(chǔ)和主干。功能插件能動(dòng)態(tài)加載到插件系統(tǒng)中，提供相對(duì)單一的功能，多個(gè)插件使系統(tǒng)功能完善，完成許多復(fù)雜的處理，是插件系統(tǒng)的重要構(gòu)成部分。

根據(jù)OSGi規(guī)范，插件結(jié)構(gòu)如圖1所示，每個(gè)插件對(duì)應(yīng)一個(gè)文件夾，由插件清單配置文件Manifest.xml和插件程序集組成。

程序數(shù)據(jù)流程大致為：運(yùn)行啟動(dòng)后，宿主程序遍歷插件目錄，將包含Manifest.xml的目錄識(shí)別為插件，根據(jù)該文件中信息（包括插件名稱(chēng)、特征名稱(chēng)、版本、初始狀態(tài)等）創(chuàng)建插件對(duì)象，設(shè)置該插件狀態(tài)為安裝狀態(tài)；當(dāng)插件目錄下所有插件安裝完成后，宿主程序逐個(gè)解析插件間依賴關(guān)系；完成目錄下插件的解析后，加載Manifest.xml中指定的程序集啟動(dòng)插件；如果沒(méi)有拋出異常，插件啟動(dòng)成功，狀態(tài)變?yōu)榛顒?dòng)狀態(tài)，插件被加載到程序中；當(dāng)不需要運(yùn)行某插件時(shí)，可以停止或卸載，狀態(tài)變?yōu)橥Ｖ够蛞研遁d狀態(tài)。

采用基于OSGi的插件機(jī)制開(kāi)發(fā)軍用指揮軟件是把各大功能模塊劃分為不同插件，每個(gè)插件完成相對(duì)獨(dú)立的功能，各插件之間以及插件與宿主程序之間通過(guò)標(biāo)準(zhǔn)接口進(jìn)行集成。有利于減輕軟件開(kāi)發(fā)者負(fù)擔(dān)，增強(qiáng)軟件的可擴(kuò)展性。

表1 現(xiàn)有插件技術(shù)與OSGi的對(duì)比

2 技術(shù)實(shí)現(xiàn)

2.1 OSGi插件化實(shí)現(xiàn)

采用OSGi插件機(jī)制，將插件分為宿主程序和功能插件[4]。宿主程序是功能插件運(yùn)行的容器，提供環(huán)境初始化、宿主程序的啟動(dòng)、注銷(xiāo)、功能插件注冊(cè)等功能；功能插件就是指揮軟件具體功能的實(shí)現(xiàn)。

插件化的實(shí)現(xiàn)原理如圖2所示，定義IBundle為公共接口類(lèi)，負(fù)責(zé)提供獲取插件上下文、讀取插件Manifest.xml文件等初始化接口，以及啟動(dòng)、停止，卸載、更新插件等插件操作類(lèi)接口；定義IFrameWork繼承IBundle作為宿主程序接口類(lèi)；此外，為宿主程序定義了4個(gè)接口：觸發(fā)事件接口IFrameworkFireEvent、服務(wù)接口IFrameworkService、監(jiān)聽(tīng)器接口 IFrameworkListener、安裝器接口IFrameworkInstaller。

圖2 插件接口類(lèi)圖

宿主程序類(lèi)Framework繼承并實(shí)現(xiàn)IFramework、IFramework Fire Event、IFramework Service、IFrameworkListener、IFrameworkInstaller接口；功能插件類(lèi)Bundle實(shí)現(xiàn)IBundle接口，具體實(shí)現(xiàn)接口中申明的方法。

2.2 插件加載

插件加載是從本插件的類(lèi)型空間加載需要的類(lèi)型。插件運(yùn)行所需的程序集并不位于同一目錄，通過(guò)設(shè)計(jì)類(lèi)加載器，使其能夠從插件目錄中正確加載到插件程序集，采用顯式加載和隱式加載兩種。顯式加載通過(guò)Type.GetType方法支持；隱式加載則通過(guò)對(duì) CLR Loader擴(kuò)展來(lái)支持[3]。

2.2.1 顯式加載

插件可用的類(lèi)型空間由本地程序集、子插件本地程序集、依賴的程序集和子插件依賴的程序集組成。這些信息配置在Manifest.xml文件中。加載的順序?yàn)椋合到y(tǒng)庫(kù)、本地Import（引用另一個(gè)插件共享的類(lèi)型）、Import對(duì)應(yīng)的Export信息（把本地程序集包含的類(lèi)向其他插件暴露）、Require的 Bundle Dynamic Import（引用另一個(gè)插件定義的所有的Export暴露出來(lái)的所有類(lèi)）。

顯示加載需要使用Type.GetType（name）方法。如果類(lèi)型名稱(chēng)沒(méi)有包含程序集全名，則從正在執(zhí)行的程序集和mscorlib.dll加載類(lèi)型；如果指定了程序集全名，則先加載程序集，在進(jìn)行類(lèi)的加載。

2.2.2 隱式加載

隱式類(lèi)型加載用于解決插件間的靜態(tài)依賴，即一個(gè)插件在實(shí)現(xiàn)中直接引用了另一個(gè)插件的類(lèi)的情況，通過(guò)CLR Loader觸發(fā)完成加載程序集、插件、資源和類(lèi)型，為了使CLR能夠成功從依賴的插件加載到需要的類(lèi)型，對(duì)CLR類(lèi)加載器進(jìn)行擴(kuò)展，通過(guò)監(jiān)聽(tīng)AppDomain的AssemblyResolve事件，匹配各插件的程序集全名，加載所需的程序集：

2.3 插件擴(kuò)展

插件采用引用服務(wù)、定義擴(kuò)展點(diǎn)兩種方式實(shí)現(xiàn)擴(kuò)展式設(shè)計(jì)。

1）引用服務(wù)，插件通過(guò)引用服務(wù)接口來(lái)獲取系統(tǒng)中的服務(wù)，完成現(xiàn)插件功能的擴(kuò)展。即采用傳統(tǒng)的面向?qū)ο蠓绞綄?shí)現(xiàn)：引用定義服務(wù)的插件并實(shí)現(xiàn)對(duì)應(yīng)接口，完成功能擴(kuò)展。

2）定義擴(kuò)展點(diǎn)[8]，在 Manifest.xml文件中定義插件擴(kuò)展信息，包括可擴(kuò)展點(diǎn)和擴(kuò)展點(diǎn)?？蓴U(kuò)展點(diǎn)是指一個(gè)插件暴露給其他插件，可用于擴(kuò)展的信息；擴(kuò)展點(diǎn)則定義了插件對(duì)其他插件的擴(kuò)展。擴(kuò)展點(diǎn)結(jié)構(gòu)如圖3所示。

圖3 擴(kuò)展點(diǎn)結(jié)構(gòu)

插件通過(guò)暴露擴(kuò)展點(diǎn)提供給其他插件，實(shí)現(xiàn)新功能的添加。擴(kuò)展點(diǎn)信息定義如圖4所示。被擴(kuò)展插件和擴(kuò)展插件通過(guò)擴(kuò)展點(diǎn)建立關(guān)聯(lián)，擴(kuò)展點(diǎn)通過(guò)ExtensionPoint節(jié)點(diǎn)定義并指定Point屬性（即擴(kuò)展點(diǎn)名稱(chēng)）；擴(kuò)展則通過(guò)Extension定義并指定Point屬性（即擴(kuò)展點(diǎn)名稱(chēng)），并在子節(jié)點(diǎn)定義擴(kuò)展的信息。

插件擴(kuò)展具有動(dòng)態(tài)性[9]，在插件啟動(dòng)時(shí)暴露擴(kuò)展點(diǎn)供其他插件使用，并通過(guò)GetExtension方法和ExtensionChanged事件獲取其他插件對(duì)該擴(kuò)展點(diǎn)的所有擴(kuò)展信息并監(jiān)聽(tīng)擴(kuò)展信息的變更；在插件停止時(shí)從宿主程序中卸載，對(duì)其他插件并不造成影響，保證了插件間的松耦合。

2.4 插件通信

插件間通信采用兩種通信方式。一種是通過(guò)CLR完成，即直接通過(guò)引用類(lèi)型來(lái)進(jìn)行通信，用于與底層基礎(chǔ)插件通信；另一種是插件之間通過(guò)服務(wù)來(lái)實(shí)現(xiàn)交互[10-11]，如圖5所示，插件以接口的形式定義契約（規(guī)定服務(wù)方法和數(shù)據(jù)類(lèi)型），服務(wù)提供者插件對(duì)契約中約定的服務(wù)進(jìn)行實(shí)現(xiàn)，將實(shí)現(xiàn)的服務(wù)對(duì)象注冊(cè)到服務(wù)總線上，服務(wù)消費(fèi)者插件從服務(wù)總線上獲取需要的服務(wù)對(duì)象，進(jìn)行調(diào)用。

圖4 擴(kuò)展點(diǎn)描述

圖5 插件通信

2.5 開(kāi)發(fā)平臺(tái)載入

本文基于Visual Studio的模板和向?qū)С绦騺?lái)實(shí)現(xiàn)功能插件與編程平臺(tái)的緊密結(jié)合，為軟件開(kāi)發(fā)者提供便捷的二次開(kāi)發(fā)平臺(tái)，實(shí)現(xiàn)插件復(fù)用、提高軟件開(kāi)發(fā)效率。

插件項(xiàng)目模板及向?qū)С绦蛴糜趧?chuàng)建自定義的項(xiàng)目[12-13]，根據(jù)上文描述的功能插件整理出項(xiàng)目模板，其中包含項(xiàng)目所需的目錄和公共文件（如配置文件、資源文件）。

設(shè)計(jì)支持線性步驟系列的應(yīng)用程序作為向?qū)?。向?qū)е刑峁└鱾€(gè)自定義參數(shù)值的輸入界面、處理啟動(dòng)項(xiàng)目創(chuàng)建的事件，事件接收用戶啟動(dòng)項(xiàng)目時(shí)所輸入的項(xiàng)目名稱(chēng)，從.NET提供的IWizard接口中讀取replacementsDictionary作為系統(tǒng)參數(shù)。根據(jù)系統(tǒng)參數(shù)和自定義參數(shù)，基于項(xiàng)目模板向?qū)Э焖偕筛鱾€(gè)項(xiàng)目。

3 應(yīng)用實(shí)例

本文在.NET平臺(tái)上應(yīng)用OSGi規(guī)范實(shí)現(xiàn)了軍用指揮軟件的插件機(jī)制，該機(jī)制已應(yīng)用到某外貿(mào)合成旅指揮軟件的開(kāi)發(fā)中。該軟件中軟件框架包括菜單、工具欄、按鈕和快捷鍵等[14]，均采用上文所述插件機(jī)制集成，快速實(shí)現(xiàn)應(yīng)用軟件的框架構(gòu)建。

以軍用指揮軟件中輔助計(jì)算功能模塊為例：

通用模塊開(kāi)發(fā)人員按照上文所述的插件設(shè)計(jì)方式完成該功能開(kāi)發(fā)、測(cè)試，如下頁(yè)圖6（a）所示；

將功能模塊集成到VisualStudio開(kāi)發(fā)工具中[15]，如圖6（b）所示；

圖6 應(yīng)用實(shí)例

在某外貿(mào)合成旅指揮軟件中需加載該功能，開(kāi)發(fā)人員無(wú)需進(jìn)行重復(fù)開(kāi)發(fā)，采用Visual Studio中完成加載，在圖6（c）所示的向?qū)е休斎胱远x參數(shù)；

將輔助計(jì)算功能加載到指揮軟件中，效果如圖6（d）所示。

4 結(jié)論

本文在.NET平臺(tái)上借鑒OSGi規(guī)范設(shè)計(jì)了一種軍用指揮軟件的插件機(jī)制，為開(kāi)發(fā)人員提供了簡(jiǎn)單、易用的接口，降低了系統(tǒng)耦合性；制定了開(kāi)發(fā)規(guī)范，有助于提高開(kāi)發(fā)效率、并行性和靈活性，縮短開(kāi)發(fā)周期。