陳 辭
(海軍駐大連四二六廠軍事代表室 大連 116001)
海上面臨著愈發(fā)多元化的安全威脅,不僅有局部戰(zhàn)爭、邊界沖突、戰(zhàn)略威懾等諸多傳統(tǒng)軍事行動,維和、反恐、救災、護航、撤僑等非戰(zhàn)爭軍事行動也成為各國海軍的重要使命。這使得海上任務的背景更加復雜化、對象更加多元化、行動更加多樣化,對于海上信息系統(tǒng)信息化建設的要求也越來越高。但目前海上信息系統(tǒng)的信息化建設主要立足于傳統(tǒng)的金字塔型指揮體系,難以滿足信息化戰(zhàn)爭對扁平化信息交互的需求,缺乏對多平臺系統(tǒng)資源統(tǒng)一調度、高效運作的支持,系統(tǒng)靈活配置、柔性重組能力不夠,系統(tǒng)流程隨需應變、動態(tài)重構的能力不足。因此,探索一種能夠支持動態(tài)模塊化構建、重組的海上信息化系統(tǒng)是一個亟須解決的問題,本文將商用IT領域流行的OSGi(Open Service Gateway Initiative)架構應用到海上信息系統(tǒng),并對其應用效果做出了相應的分析。
未來海戰(zhàn)是海、空、天、以至電磁譜域一體化的戰(zhàn)爭,是晝夜24小時全天候的戰(zhàn)爭,是一場總體戰(zhàn)、立體戰(zhàn)、導彈戰(zhàn)、電子戰(zhàn)[1]。多軍兵種聯(lián)合作戰(zhàn)必將成為未來信息化戰(zhàn)爭的主要作戰(zhàn)模式,以作戰(zhàn)任務為中心,根據(jù)作戰(zhàn)系統(tǒng)各自不同的特點和優(yōu)勢資源,進行優(yōu)化整合,實施作戰(zhàn)系統(tǒng)動態(tài)集成,極大發(fā)揮多系統(tǒng)的整體作戰(zhàn)效能[2]。如何最大限度發(fā)揮裝備協(xié)同作戰(zhàn)的能力,以及如何為高科技的裝備使用創(chuàng)造條件等問題直接關系到高科技局部戰(zhàn)爭的成敗,它們的成功解決將大大提高海軍的作戰(zhàn)能力[3]。
因此,將現(xiàn)有海上信息系統(tǒng)中包括各個武器平臺,傳感器系統(tǒng)在內的各種資源充分重用、共享是解決裝備性能瓶頸、提高協(xié)同作戰(zhàn)能力的有效途徑,也是目前海上信息系統(tǒng)急需解決的難題。
網(wǎng)絡中心戰(zhàn)概念的誕生使得海軍能夠建立以C4ISR為支撐點、以網(wǎng)絡為中心的新型作戰(zhàn)系統(tǒng)結構,從而實現(xiàn)多平臺、多基地的互聯(lián)互通,以及協(xié)同作戰(zhàn)的快速反應要求[4]。在這種分布式的作戰(zhàn)體系中,其最大特征在于體系的區(qū)域上分布性、單元的自治性、單元的獨立性,以及單元間在整體目標驅動下的同步性,包括通信交流網(wǎng)絡、指揮與協(xié)調關系、在任務執(zhí)行上協(xié)作與協(xié)同關系等[5]。
但是,由于目前海上信息系統(tǒng)各個平臺之間的能力差異、集成規(guī)劃和技術體制的限制,在各個系統(tǒng)接口關系和信息流程相對固定,缺乏對信息化戰(zhàn)爭中靈活、快速、動態(tài)OODA環(huán)的支持,海上信息系統(tǒng)隨需應變、動態(tài)集成、重組能力嚴重不足。因此,研究面向海上信息服務的即插即用、動態(tài)集成技術,實現(xiàn)跨平臺多系統(tǒng)指揮控制、情報收集、處理能力、武器控制能力的聚合分解,能夠打破系統(tǒng)邊界,滿足多樣化的海上信息服務的需要勢在必行。
海上信息系統(tǒng)其實是不同平臺預警探測系統(tǒng)、情報偵察系統(tǒng)、指揮與火力控制系統(tǒng)、通信系統(tǒng)、武器系統(tǒng)等諸多子系統(tǒng)整合而成的大系統(tǒng)(System of Systems)。而目前大系統(tǒng)集成沒有有效的方法指導,缺乏頂層設計,導致大系統(tǒng)構建的周期增長、系統(tǒng)穩(wěn)定性減弱、性能降低、互操作性弱、耦合度大等問題。
橫向參考美軍的發(fā)展,2004年1月,美軍發(fā)布《聯(lián)合轉型路線圖》,強調以“基于能力,效果驅動”的方式推進聯(lián)合部隊轉型,全球信息柵格(GIG)是聯(lián)合作戰(zhàn)轉型的關鍵概念和基礎設施。使命能力包則是美軍在網(wǎng)絡中心戰(zhàn)的背景下提出的,基于面向服務體系結構(SOA)的指揮控制系統(tǒng)解決方案。使命能力包以網(wǎng)絡中心企業(yè)服務為基礎,整合各個現(xiàn)役的指控平臺,用以增強美軍在聯(lián)合作戰(zhàn)戰(zhàn)場環(huán)境下的技術優(yōu)勢和信息優(yōu)勢。
因此,自主構建具有良好穩(wěn)定性、可擴展性的海上信息系統(tǒng)非常必要。
隨著通信、汽車、娛樂等行業(yè)的發(fā)展以及手持設備的應用,輸入設備日益豐富,獲取數(shù)據(jù)和服務的方式也越來越多[6~7]。復雜的應用環(huán)境無疑使得軟件功能復雜,規(guī)模龐大,開發(fā)周期更長,成本更高,在這樣的動態(tài)環(huán)境中,商業(yè)與應用模式變化迅速,已開發(fā)的軟件很快就不能適應新的變化。有的軟件甚至剛剛開發(fā)完成就已經不適合應用了[8]。正是在這種日新月異的背景下,OSGi應運而生。
OSGi直譯為“開發(fā)服務網(wǎng)關”,是一個由OSGi聯(lián)盟發(fā)起的以Java為技術平臺的動態(tài)模塊化規(guī)范。自從1999年OSGi聯(lián)盟成立以來,OSGi技術就伴隨著Java一起飛速發(fā)展,越來越多的世界著名IT企業(yè)都加入到了OSGi的陣營之中,如Adobe、IBM、Oracle、SAP、RedHat和Siemens等。這些軟件廠商推出的許多產品都支持OSGi技術,甚至產品本身就使用了OSGi技術構建。這些IT巨頭的踴躍參與,也從側面證明了OSGi技術有著非常廣闊的市場前景[9]。
OSGi規(guī)范應用的范圍非常寬泛,可以應用于移動通訊、汽車、嵌入式設備[10]、家庭網(wǎng)關、個人電腦、高端服務器等多種領域。而最新的OSGi規(guī)范是2012年7月發(fā)布的Release 5,Version5.0(R5.0)注版本,該規(guī)范定義了Java模塊化系統(tǒng)所涉及的各種場景(開發(fā)、打包、部署、更新和交互等),以及其中用到的標準接口和參考模型。OSGi的運行環(huán)境、核心架構以及常用的標準服務如圖1所示。

圖1 OSGi內容總覽
在OSGi插件化開發(fā)模型中,系統(tǒng)被設計成一個核心加上一系列插件構成的功能模塊,各個模塊相對獨立,除了實現(xiàn)軟件關鍵邏輯的核心模塊,其他模塊都是可以被裁減的,如果一個模塊設計得當,甚至可以獨立發(fā)布或者直接安裝在其他的系統(tǒng)中運行。而這恰恰就是現(xiàn)有海上信息系統(tǒng)所需要的。

圖2 OSGi插件化開發(fā)模型
OSGi架構定義了一個良好的面向服務的編程和運行模型。一個普通的OSGi Bundle可以向本地的注冊中心注冊服務,同時也可以查詢、監(jiān)聽和使用同一個OSGi架構內注冊的服務。但是,在分布式、多平臺集成的海上環(huán)境下僅僅做到這些是不夠的。遠程服務作為在異構分布式環(huán)境中的必備要素,在OSGi架構中也獲得了良好的技術支撐。
下面描述了一個典型的基于OSGi的海上信息系統(tǒng)遠程服務應用場景。該場景中共有A、B、C、D四個海上信息節(jié)點,節(jié)點A提供CORBA服務,節(jié)點B提供Web服務(模擬異構環(huán)境),節(jié)點C提供運行于OSGi容器的OSGi服務,而節(jié)點D則是服務使用者,相互關系如圖3所示。

圖3 OSGi遠程服務典型應用場景
對于海上信息系統(tǒng)這類異構、復雜的大系統(tǒng),典型的服務集成框架中至少需要包括以下的幾個功能模塊:遠程服務管理模塊、監(jiān)控模塊、策略模塊、服務發(fā)現(xiàn)管理模塊、處理器管理模塊等。相應的OSGi架構應用模型如圖4所示。

圖4 OSGi架構應用模型示意圖
遠程服務管理模塊主要提供上文提到的遠程服務管理能力。它負責監(jiān)聽遠程服務注冊和使用請求,對不同類型的服務進行管理,針對不同的服務配置類型,通知處理器管理模塊進行發(fā)布和調用,維護當前發(fā)布的服務以及使用的遠程服務的信息;監(jiān)控模塊負責監(jiān)控OSGi容器中的本地注冊中心,并從遠程服務管理模塊得到要監(jiān)控的信息,對系統(tǒng)的運行情況進行調整和配置,保持系統(tǒng)的正常運行;策略模塊為遠程服務管理模塊提供服務管理策略,為監(jiān)控模塊提供動態(tài)調整策略的支持;服務發(fā)現(xiàn)管理模塊用于實現(xiàn)服務發(fā)現(xiàn)的動態(tài)管理和調用;處理器管理模塊用于對處理器模塊進行管理,并向遠程端點發(fā)布和調用服務,根據(jù)遠程服務管理模塊所傳遞的信息調用相應的處理器模塊;處理器模塊是對某一種具體的遠程訪問機制的封裝(模擬海上信息系統(tǒng)中的各種異構平臺)。不同的處理器模塊用于實現(xiàn)OSGi容器內的模塊以不同的方式向OSGi容器外的服務的訪問。處理器管理模塊和不同的處理器模塊的相互協(xié)作,實現(xiàn)了對異構、復雜的海上信息環(huán)境下不同的遠程訪問機制的集成和管理。
1)遠程服務管理機制
在服務發(fā)布過程中,遠程服務管理模塊初始化時,會向本地注冊中心查詢“Strategy”服務,如果不存在則使用默認服務發(fā)布策略;查找到策略服務后,通過調用策略服務對象的相應方法獲取到服務發(fā)布策略,遠程服務管理模塊內置一個發(fā)布的服務列表,當監(jiān)聽到遠程服務注冊事件時,遠程服務管理模塊將該服務的描述信息加入到該列表,并使用服務發(fā)布策略發(fā)布該服務。
在服務使用過程中,遠程服務管理模塊初始化時,會向本地注冊中心查詢“Strategy”服務,如果不存在則使用默認服務調用策略;查找到策略服務后,通過調用策略服務對象的相應方法獲取到服務調用策略,當監(jiān)聽到遠程服務的調用事件并調用成功后,遠程服務管理模塊內置一個列表來保存調用的遠程服務的信息,并使用遠程服務調用策略進行處理。
針對海上信息系統(tǒng)的異構、分布式復雜環(huán)境,服務提供者在服務注冊時可以在自己的屬性信息里面配置自己需要使用的遠程互操作技術(如CORBA、Web Service等),同樣,使用者也可以對應的方式配置自己需要采用的訪問方式,從而增加了整個OSGi架構應用模型的靈活性和動態(tài)性。
2)監(jiān)控和動態(tài)調整機制
考慮到OSGi架構應用模型中存在很多Bundle,這些Bundle在本地的注冊中心注冊了很多服務,為了實時掌握OSGi容器的運行情況并給服務發(fā)布和動態(tài)調整提供依據(jù),此應用模型提供對本地OSGi容器運行情況的監(jiān)控機制,主要使用的是OSGi內核以及Java虛擬機提供的API,監(jiān)控的內容主要包括服務的依賴關系、堆棧的使用情況和本地線程數(shù)。
其中服務依賴關系方面,OSGi容器內的Bundle在注冊服務時可以在元信息描述文件內設置服務注冊的信息和需要使用到的其他服務的信息,因而OSGi容器內注冊的服務之間存在著依賴關系,除了在元信息描述文件內靜態(tài)的獲取這些信息之外,還需要使用OSGi提供的API獲得運行時的服務依賴關系;堆棧使用方面,JVM為每一個新創(chuàng)建的線程都分配一個堆棧。而對于本地線程數(shù)而言,如果運行的線程太多可能引起內存溢出之類的異常,因此在線程比較多的情況下控制最大線程數(shù)可以保證系統(tǒng)在比較穩(wěn)定的狀態(tài)下運行。
應用模型支持在Bundle數(shù)量不斷增加時對系統(tǒng)和運行環(huán)境做出動態(tài)調整。監(jiān)控模塊初始化時,會向本地注冊中心查詢“Strategy”服務,如果不存在則不進行動態(tài)調整(使用人工調整);查找到策略服務后,通過調用策略服務對象isConfigable方法獲取到動態(tài)調整策略。調整主要涉及對新的服務注冊、調用和查詢進行控制;對應用模型運行容器的堆棧使用和Bundle生命周期狀態(tài)調整。
3)策略機制
應用模型以即插即用、動態(tài)加載的策略模塊的形式實現(xiàn)了策略驅動的海上信息系統(tǒng)。策略主要包括:OSGi本地服務發(fā)布給遠程使用時,調用監(jiān)控模塊獲得本地的運行情況,如果本地線程數(shù)或者本地堆棧使用超過設定的上限,則新的遠程服務的注冊、查詢、調用請求將會被緩存;在服務調用過程中,如果服務突然失效,或者因為某些未知的原因不可訪問,在服務調動策略的驅動下,遠程服務管理模塊會進行相應的處理;根據(jù)監(jiān)控模塊獲得的本地資源使用情況,如果本地線程數(shù)超過設定的上限,則新的遠程服務的注冊、查詢、調用請求將會被緩存;如果本地堆棧使用超過上限,則進行清理,并調整高啟動級別的Bundle生命周期狀態(tài)。這樣的柔性動態(tài)調整策略可以大大增強OSGi架構應用模型的穩(wěn)定性。
4)處理器管理機制
每個處理器模塊都是以OSGi Bundle的形式加載的,OSGi Bundle的動態(tài)性保證了基于異構、分布式的處理器的動態(tài)性。每個處理器需要實現(xiàn)Handler接口,注冊“Handler”服務,并在屬性中說明類型,如“TYPE:Web Service”…;處理器管理模塊運行期間將會向本地注冊中心監(jiān)聽注冊的Handler服務,并將服務引用加入到列表,將其屬性中的“TYPE”字段加入到自己的“SupportType”列表。同時,基于新的互操作協(xié)議開發(fā)的處理器,只要實現(xiàn)了Handler接口、注冊“Handler”無法,并且按照自身的編程模型做好服務的發(fā)布和調用工作,就可以將其動態(tài)的加入到基于OSGi的海上信息系統(tǒng)應用模型中來,增強那應用模型的可擴展性。
5)服務發(fā)現(xiàn)運行機制
與處理器管理機制類似,應用模型提供了服務發(fā)現(xiàn)管理機制。在服務發(fā)現(xiàn)管理模塊的作用下,包括有一個Discovery的接口類,在該模塊中創(chuàng)建了UDDI的名字服務機制、本地配置文件等多種服務發(fā)現(xiàn)方式。每種方式都實現(xiàn)了上述的Discovery接口,同時,應用模型運行前可以配置需要加載的服務發(fā)現(xiàn)類型。
由于OSGi架構天生的動態(tài)性會帶來模塊加載的不確定性,服務發(fā)現(xiàn)管理模塊需要緩存所有的遠程服務查詢和注冊請求,按照一定的時間間隔輪詢所有請求,并向遠程服務注冊中心查詢和注冊,從而控制這些訪問不是并發(fā)執(zhí)行,保證了整個應用模型運行效率。
綜上所述,基于OSGi架構的海上信息系統(tǒng)應用模型能夠滿足目前海上信息系統(tǒng)現(xiàn)有資源重用共享、即插即用動態(tài)集成、穩(wěn)定性以及可擴展性等諸多需求。進一步深入地將OSGi架構應用到海上信息系統(tǒng)是很有價值的。
隨著信息化技術的不斷發(fā)展,現(xiàn)代信息化戰(zhàn)爭對扁平化信息交互的需求越來越高。尤其對于海上信息系統(tǒng)而言,多平臺各系統(tǒng)資源統(tǒng)一調度、協(xié)同共享、即插即用、動態(tài)集成、柔性重組的需求急需滿足。在商業(yè)IT領域已經取得很大成果的OSGi動態(tài)模塊化架構恰恰能夠很好地對應解決目前海上信息系統(tǒng)的各種需求,增強信息服務共享能力,提高海上一體化信息支持服務水平。
[1]張中南,王峰,張衛(wèi)峰.未來海上防空作戰(zhàn)戰(zhàn)場環(huán)境研究[J].現(xiàn)代防御技術,2005,33(3):9-13.
[2]李建軍,劉翔,任彥,等.作戰(zhàn)任務高層本體描述及規(guī)劃[J].火力與指揮控制,2008,33(1):53-55.
[3]王敏.海上作戰(zhàn)環(huán)境仿真技術在C4ISR系統(tǒng)的應用研究[J].艦船電子工程,2003(6):2-5.
[4]李開生,王文友.國外潛艇作戰(zhàn)系統(tǒng)的現(xiàn)狀及其發(fā)展趨勢[J].火力與指揮控制,2005,30(3):4-7.
[5]黃廣連,陽東升,張維明,等.分布式作戰(zhàn)體系的描述[J].艦船電子工程,2007,27(5):3-6.
[6]熊江.OSGi的分析和實現(xiàn)及其改進思路[J].計算機科學,2004,31(3):192-194.
[7]熊江,應宏.基于 OSGi的普及計算系統(tǒng)的改進[J].計算機科學,2005,32(1):61-63.
[8]孫力軍,陳德人,施敏華.基于OSGi的自適應可進化軟件框架[J].江南大學學報,2007,6(2):140-143.
[9]周志明,謝小明.深入理解OSGi[M].北京:機械工業(yè)出版社,2013:2-3.
[10]楊春陽,劉兵.基于OSGi規(guī)范的“智能化”嵌入式應用開發(fā)[J].儀器儀表學報,2004,25(4):632-634.