OSGi架構在海上信息系統應用研究＊

陳 辭

（海軍駐大連四二六廠軍事代表室 大連 116001）

1 引言

海上面臨著愈發多元化的安全威脅，不僅有局部戰爭、邊界沖突、戰略威懾等諸多傳統軍事行動，維和、反恐、救災、護航、撤僑等非戰爭軍事行動也成為各國海軍的重要使命。這使得海上任務的背景更加復雜化、對象更加多元化、行動更加多樣化，對于海上信息系統信息化建設的要求也越來越高。但目前海上信息系統的信息化建設主要立足于傳統的金字塔型指揮體系，難以滿足信息化戰爭對扁平化信息交互的需求，缺乏對多平臺系統資源統一調度、高效運作的支持，系統靈活配置、柔性重組能力不夠，系統流程隨需應變、動態重構的能力不足。因此，探索一種能夠支持動態模塊化構建、重組的海上信息化系統是一個亟須解決的問題，本文將商用IT領域流行的OSGi（Open Service Gateway Initiative）架構應用到海上信息系統，并對其應用效果做出了相應的分析。

2 海上信息系統的需求分析

1）現有資源重用、共享需求

未來海戰是海、空、天、以至電磁譜域一體化的戰爭，是晝夜24小時全天候的戰爭，是一場總體戰、立體戰、導彈戰、電子戰［1］。多軍兵種聯合作戰必將成為未來信息化戰爭的主要作戰模式，以作戰任務為中心，根據作戰系統各自不同的特點和優勢資源，進行優化整合，實施作戰系統動態集成，極大發揮多系統的整體作戰效能［2］。如何最大限度發揮裝備協同作戰的能力，以及如何為高科技的裝備使用創造條件等問題直接關系到高科技局部戰爭的成敗，它們的成功解決將大大提高海軍的作戰能力［3］。

因此，將現有海上信息系統中包括各個武器平臺，傳感器系統在內的各種資源充分重用、共享是解決裝備性能瓶頸、提高協同作戰能力的有效途徑，也是目前海上信息系統急需解決的難題。

2）即插即用、動態集成

網絡中心戰概念的誕生使得海軍能夠建立以C4ISR為支撐點、以網絡為中心的新型作戰系統結構，從而實現多平臺、多基地的互聯互通，以及協同作戰的快速反應要求［4］。在這種分布式的作戰體系中，其最大特征在于體系的區域上分布性、單元的自治性、單元的獨立性，以及單元間在整體目標驅動下的同步性，包括通信交流網絡、指揮與協調關系、在任務執行上協作與協同關系等［5］。

但是，由于目前海上信息系統各個平臺之間的能力差異、集成規劃和技術體制的限制，在各個系統接口關系和信息流程相對固定，缺乏對信息化戰爭中靈活、快速、動態OODA環的支持，海上信息系統隨需應變、動態集成、重組能力嚴重不足。因此，研究面向海上信息服務的即插即用、動態集成技術，實現跨平臺多系統指揮控制、情報收集、處理能力、武器控制能力的聚合分解，能夠打破系統邊界，滿足多樣化的海上信息服務的需要勢在必行。

3）穩定性、可擴展性

海上信息系統其實是不同平臺預警探測系統、情報偵察系統、指揮與火力控制系統、通信系統、武器系統等諸多子系統整合而成的大系統（System of Systems）。而目前大系統集成沒有有效的方法指導，缺乏頂層設計，導致大系統構建的周期增長、系統穩定性減弱、性能降低、互操作性弱、耦合度大等問題。

橫向參考美軍的發展，2004年1月，美軍發布《聯合轉型路線圖》，強調以“基于能力，效果驅動”的方式推進聯合部隊轉型，全球信息柵格（GIG）是聯合作戰轉型的關鍵概念和基礎設施。使命能力包則是美軍在網絡中心戰的背景下提出的，基于面向服務體系結構（SOA）的指揮控制系統解決方案。使命能力包以網絡中心企業服務為基礎，整合各個現役的指控平臺，用以增強美軍在聯合作戰戰場環境下的技術優勢和信息優勢。

因此，自主構建具有良好穩定性、可擴展性的海上信息系統非常必要。

3 OSGi架構描述

隨著通信、汽車、娛樂等行業的發展以及手持設備的應用，輸入設備日益豐富，獲取數據和服務的方式也越來越多［6～7］。復雜的應用環境無疑使得軟件功能復雜，規模龐大，開發周期更長，成本更高，在這樣的動態環境中，商業與應用模式變化迅速，已開發的軟件很快就不能適應新的變化。有的軟件甚至剛剛開發完成就已經不適合應用了［8］。正是在這種日新月異的背景下，OSGi應運而生。

OSGi直譯為“開發服務網關”，是一個由OSGi聯盟發起的以Java為技術平臺的動態模塊化規范。自從1999年OSGi聯盟成立以來，OSGi技術就伴隨著Java一起飛速發展，越來越多的世界著名IT企業都加入到了OSGi的陣營之中，如Adobe、IBM、Oracle、SAP、RedHat和Siemens等。這些軟件廠商推出的許多產品都支持OSGi技術，甚至產品本身就使用了OSGi技術構建。這些IT巨頭的踴躍參與，也從側面證明了OSGi技術有著非常廣闊的市場前景［9］。

OSGi規范應用的范圍非常寬泛，可以應用于移動通訊、汽車、嵌入式設備［10］、家庭網關、個人電腦、高端服務器等多種領域。而最新的OSGi規范是2012年7月發布的Release 5，Version5.0（R5.0）注版本，該規范定義了Java模塊化系統所涉及的各種場景（開發、打包、部署、更新和交互等），以及其中用到的標準接口和參考模型。OSGi的運行環境、核心架構以及常用的標準服務如圖1所示。

圖1 OSGi內容總覽

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

圖2 OSGi插件化開發模型

4 基于OSGi架構的海上信息系統應用模型

4.1 OSGi架構應用模型

OSGi架構定義了一個良好的面向服務的編程和運行模型。一個普通的OSGi Bundle可以向本地的注冊中心注冊服務，同時也可以查詢、監聽和使用同一個OSGi架構內注冊的服務。但是，在分布式、多平臺集成的海上環境下僅僅做到這些是不夠的。遠程服務作為在異構分布式環境中的必備要素，在OSGi架構中也獲得了良好的技術支撐。

下面描述了一個典型的基于OSGi的海上信息系統遠程服務應用場景。該場景中共有A、B、C、D四個海上信息節點，節點A提供CORBA服務，節點B提供Web服務（模擬異構環境），節點C提供運行于OSGi容器的OSGi服務，而節點D則是服務使用者，相互關系如圖3所示。

圖3 OSGi遠程服務典型應用場景

對于海上信息系統這類異構、復雜的大系統，典型的服務集成框架中至少需要包括以下的幾個功能模塊：遠程服務管理模塊、監控模塊、策略模塊、服務發現管理模塊、處理器管理模塊等。相應的OSGi架構應用模型如圖4所示。

圖4 OSGi架構應用模型示意圖

遠程服務管理模塊主要提供上文提到的遠程服務管理能力。它負責監聽遠程服務注冊和使用請求，對不同類型的服務進行管理，針對不同的服務配置類型，通知處理器管理模塊進行發布和調用，維護當前發布的服務以及使用的遠程服務的信息；監控模塊負責監控OSGi容器中的本地注冊中心，并從遠程服務管理模塊得到要監控的信息，對系統的運行情況進行調整和配置，保持系統的正常運行；策略模塊為遠程服務管理模塊提供服務管理策略，為監控模塊提供動態調整策略的支持；服務發現管理模塊用于實現服務發現的動態管理和調用；處理器管理模塊用于對處理器模塊進行管理，并向遠程端點發布和調用服務，根據遠程服務管理模塊所傳遞的信息調用相應的處理器模塊；處理器模塊是對某一種具體的遠程訪問機制的封裝（模擬海上信息系統中的各種異構平臺）。不同的處理器模塊用于實現OSGi容器內的模塊以不同的方式向OSGi容器外的服務的訪問。處理器管理模塊和不同的處理器模塊的相互協作，實現了對異構、復雜的海上信息環境下不同的遠程訪問機制的集成和管理。

4.2 各個模塊的運行機制

1）遠程服務管理機制

在服務發布過程中，遠程服務管理模塊初始化時，會向本地注冊中心查詢“Strategy”服務，如果不存在則使用默認服務發布策略；查找到策略服務后，通過調用策略服務對象的相應方法獲取到服務發布策略，遠程服務管理模塊內置一個發布的服務列表，當監聽到遠程服務注冊事件時，遠程服務管理模塊將該服務的描述信息加入到該列表，并使用服務發布策略發布該服務。

在服務使用過程中，遠程服務管理模塊初始化時，會向本地注冊中心查詢“Strategy”服務，如果不存在則使用默認服務調用策略；查找到策略服務后，通過調用策略服務對象的相應方法獲取到服務調用策略，當監聽到遠程服務的調用事件并調用成功后，遠程服務管理模塊內置一個列表來保存調用的遠程服務的信息，并使用遠程服務調用策略進行處理。

針對海上信息系統的異構、分布式復雜環境，服務提供者在服務注冊時可以在自己的屬性信息里面配置自己需要使用的遠程互操作技術（如CORBA、Web Service等），同樣，使用者也可以對應的方式配置自己需要采用的訪問方式，從而增加了整個OSGi架構應用模型的靈活性和動態性。

2）監控和動態調整機制

考慮到OSGi架構應用模型中存在很多Bundle，這些Bundle在本地的注冊中心注冊了很多服務，為了實時掌握OSGi容器的運行情況并給服務發布和動態調整提供依據，此應用模型提供對本地OSGi容器運行情況的監控機制，主要使用的是OSGi內核以及Java虛擬機提供的API，監控的內容主要包括服務的依賴關系、堆棧的使用情況和本地線程數。

其中服務依賴關系方面，OSGi容器內的Bundle在注冊服務時可以在元信息描述文件內設置服務注冊的信息和需要使用到的其他服務的信息，因而OSGi容器內注冊的服務之間存在著依賴關系，除了在元信息描述文件內靜態的獲取這些信息之外，還需要使用OSGi提供的API獲得運行時的服務依賴關系；堆棧使用方面，JVM為每一個新創建的線程都分配一個堆棧。而對于本地線程數而言，如果運行的線程太多可能引起內存溢出之類的異常，因此在線程比較多的情況下控制最大線程數可以保證系統在比較穩定的狀態下運行。

應用模型支持在Bundle數量不斷增加時對系統和運行環境做出動態調整。監控模塊初始化時，會向本地注冊中心查詢“Strategy”服務，如果不存在則不進行動態調整（使用人工調整）；查找到策略服務后，通過調用策略服務對象isConfigable方法獲取到動態調整策略。調整主要涉及對新的服務注冊、調用和查詢進行控制；對應用模型運行容器的堆棧使用和Bundle生命周期狀態調整。

3）策略機制

應用模型以即插即用、動態加載的策略模塊的形式實現了策略驅動的海上信息系統。策略主要包括：OSGi本地服務發布給遠程使用時，調用監控模塊獲得本地的運行情況，如果本地線程數或者本地堆棧使用超過設定的上限，則新的遠程服務的注冊、查詢、調用請求將會被緩存；在服務調用過程中，如果服務突然失效，或者因為某些未知的原因不可訪問，在服務調動策略的驅動下，遠程服務管理模塊會進行相應的處理；根據監控模塊獲得的本地資源使用情況，如果本地線程數超過設定的上限，則新的遠程服務的注冊、查詢、調用請求將會被緩存；如果本地堆棧使用超過上限，則進行清理，并調整高啟動級別的Bundle生命周期狀態。這樣的柔性動態調整策略可以大大增強OSGi架構應用模型的穩定性。

4）處理器管理機制

每個處理器模塊都是以OSGi Bundle的形式加載的，OSGi Bundle的動態性保證了基于異構、分布式的處理器的動態性。每個處理器需要實現Handler接口，注冊“Handler”服務，并在屬性中說明類型，如“TYPE：Web Service”…；處理器管理模塊運行期間將會向本地注冊中心監聽注冊的Handler服務，并將服務引用加入到列表，將其屬性中的“TYPE”字段加入到自己的“SupportType”列表。同時，基于新的互操作協議開發的處理器，只要實現了Handler接口、注冊“Handler”無法，并且按照自身的編程模型做好服務的發布和調用工作，就可以將其動態的加入到基于OSGi的海上信息系統應用模型中來，增強那應用模型的可擴展性。

5）服務發現運行機制

與處理器管理機制類似，應用模型提供了服務發現管理機制。在服務發現管理模塊的作用下，包括有一個Discovery的接口類，在該模塊中創建了UDDI的名字服務機制、本地配置文件等多種服務發現方式。每種方式都實現了上述的Discovery接口，同時，應用模型運行前可以配置需要加載的服務發現類型。

由于OSGi架構天生的動態性會帶來模塊加載的不確定性，服務發現管理模塊需要緩存所有的遠程服務查詢和注冊請求，按照一定的時間間隔輪詢所有請求，并向遠程服務注冊中心查詢和注冊，從而控制這些訪問不是并發執行，保證了整個應用模型運行效率。

綜上所述，基于OSGi架構的海上信息系統應用模型能夠滿足目前海上信息系統現有資源重用共享、即插即用動態集成、穩定性以及可擴展性等諸多需求。進一步深入地將OSGi架構應用到海上信息系統是很有價值的。

5 結語

隨著信息化技術的不斷發展，現代信息化戰爭對扁平化信息交互的需求越來越高。尤其對于海上信息系統而言，多平臺各系統資源統一調度、協同共享、即插即用、動態集成、柔性重組的需求急需滿足。在商業IT領域已經取得很大成果的OSGi動態模塊化架構恰恰能夠很好地對應解決目前海上信息系統的各種需求，增強信息服務共享能力，提高海上一體化信息支持服務水平。

［1］張中南，王峰，張衛峰.未來海上防空作戰戰場環境研究［J］.現代防御技術，2005，33（3）：9－13.

［2］李建軍，劉翔，任彥，等.作戰任務高層本體描述及規劃［J］.火力與指揮控制，2008，33（1）：53－55.

［3］王敏.海上作戰環境仿真技術在C4ISR系統的應用研究［J］.艦船電子工程，2003（6）：2－5.

［4］李開生，王文友.國外潛艇作戰系統的現狀及其發展趨勢［J］.火力與指揮控制，2005，30（3）：4－7.

［5］黃廣連，陽東升，張維明，等.分布式作戰體系的描述［J］.艦船電子工程，2007，27（5）：3－6.

［6］熊江.OSGi的分析和實現及其改進思路［J］.計算機科學，2004，31（3）：192－194.

［7］熊江，應宏.基于 OSGi的普及計算系統的改進［J］.計算機科學，2005，32（1）：61－63.

［8］孫力軍，陳德人，施敏華.基于OSGi的自適應可進化軟件框架［J］.江南大學學報，2007，6（2）：140－143.

［9］周志明，謝小明.深入理解OSGi［M］.北京：機械工業出版社，2013：2－3.

［10］楊春陽，劉兵.基于OSGi規范的“智能化”嵌入式應用開發［J］.儀器儀表學報，2004，25（4）：632－634.