基于服務總線的艦載指控系統集成方法研究＊

（海軍裝備部 北京 100841）

1 引言

艦載指控系統從誕生以來先后經歷了獨立式、集中式、分開式和分布式四個發展階段［1］，并隨著信息技術與作戰方式的不斷發展，正逐步發展為支持“網絡中心戰”的全分布式的綜合指控系統。與傳統艦載指控系統相比，新型艦載指控系統不但要具有作為獨立平臺單獨執行作戰任務能力，還要能夠進行編隊、護航等多兵種協同作戰，這就要求指控系統具備動態可配置、可重用、可功能互操作等特性［2～3］，對艦載指控系統的集成能力和水平提出了更高的要求。本文分析服務總線的體系構架和實時服務總線的模型，探討了如何在艦載指控領域實施基于服務總線的業務集成方法。

2 服務總線

2.1 服務總線體系構架概述

服務總線是面向服務構架的基礎設施和實現平臺，充當連接和集成各種實時／非實時應用系統消息總線，實施了必要抽象層將定義服務的消息轉化成可供業務構件處理的數據。其實質是服務間的連接框架，核心功能包括了消息機制、消息轉換、消息路由和服務容器四部分［4～5］，如圖1所示。

圖1 服務總線組成結構圖

1）消息機制

消息機制提供管理計算資源和網絡通信的機制，屏蔽分布環境復雜性和異構性，為應用程序提供透明的通信服務。服務總線的消息機制采用通信通道抽象服務之間的消息通信，可支持兩種通信模式：多對多的發布／訂閱和點到點的請求／響應的消息模式。

發布／訂閱是異步消息傳遞模式，發布者發布的消息可傳遞給多個訂閱者。在發布／訂閱模式中，首先訂閱者將訂閱信息發布到服務總線，發布者在發布消息后，服務總線將消息轉發給相關訂閱者。發布／訂閱方式一般通過主題樹實現。主題樹以消息發布者為根接點，父子結點之間表示了一種發布／訂閱關系。每個父結點將消息發布給其子結點，每個子結點可以選擇接受或拒絕來自父結點的所有消息。

請求／響應模式是服務提出請求，其它服務響應的模式，每個消息僅傳遞給一個消費者。它可以是同步也可以是異步的。同步方式中，請求方等待響應以進行后續操作；異步方式中，請求方無需等待響應消息。請求／回復模式可以有單向／雙向兩種消息通道。單向通道只傳遞請求或響應消息。雙向通道中一個通道可同時傳遞請求和響應消息。請求／響應一般通過隊列實現。每個服務都可建立其請求和響應隊列。

2）消息轉換

連接在總線上的服務種類很多，可能采用不同的消息協議，其對于信息的需求也不同，例如兩個通訊的服務A 采用時間格式是“YYYY-MM-DD”，而B采用“MM-DD-YYYY”。因此需要對消息進行轉換。消息轉換包括消息通信協議的橋接和消息內容轉換。協議橋接實現不能直接通訊的協議之間消息的傳遞，內容轉換支持對不同消息內容的轉換。

3）消息路由

消息路由是分析服務傳遞的步驟，建立傳遞線路和規則，并逐步傳遞消息的過程。ESB可根據消息內容將其由提供者傳遞到接受者。消息路由主要包括路由線路和路由規則兩個部分。

路由線路描述了服務將要發送的地址和路由規則，包含在消息的元數據中。它分為不帶分支判定的簡單消息線路和包括分支、判定、條件等執行過程的復雜消息線路。簡單消息線路上的各個服務結點順序執行；復雜處理過程在復雜的路由中，需要支持流程分離、流程聚合以及復雜分支判定等多種處理機制。

路由規則多采用分布式的管理方式，即規則分散在各個服務節點，由該節點的服務容器管理。路由規則定義了消息傳遞和路由線路的選擇策略，例如需要滿足的前提條件、路由時間延遲要求、可允許的失敗連接的次數等。

4）服務容器

服務容器是將各種類型的軟件組件或應用，封裝成可支持標準通訊協議（如JMS、JBI、JCA、SOAP等）的服務，并抽象成一個端點，連接到總線上的組件。服務容器既可以封裝用戶應用軟件，也可以封裝服務總線的基礎服務［6］。

通過服務容器，可以實現對軟件的局部管理和全局管理相結合的方式。局部管理是服務容器對其所封裝的軟件的管理，包括生命周期管理、連接管理等。服務容器屏蔽了軟件的異構性，使得總線的基礎服務對每個特定的服務軟件透明。

2.2 現有服務總線模型及其存在的問題

Java業務集成（Java business integration，JBI）是JCP 制定的Java 平臺的ESB 標準化技術規范［7］。JBI中定義了兩種組件：綁定組件（Binding Components，BC）和 服 務 引 擎（Service Engine，SE）。綁定組件用于根據特定協議和傳輸器發送和接收消息，如HTTP／Web Service、JMS、FTP等。服務引擎實現業務邏輯，編排整合各種服務。綁定組件把消息在特定協議的格式和規格化格式之間進行轉換，使JBI系統只需處理規格化消息，從而把JBI系統與特定協議分離［8～9］。

JBI給出了服務總線系統的接口和交互標準，但并沒有給出具體的實現方法，特別是如何應付高并發的業務請求。一些基于JBI的服務總線系統采用部署集群的方式應對高并發的業務請求，但由于接入總線的外部Web Service服務本身的處理能力有限，即便再多集群，對該服務的調用仍然是多種業務流對有限資源的競爭使用。這種實現方式沒有考慮到不同類型的業務對時效性的要求，當系統重載總線發生業務擁塞時，所有的服務都處于等待狀態，系統服務質量迅速下降。

2.3 實時服務總線模型

實時服務總線作為一個集中式數據和服務交換平臺，需要處理大量的實時業務。實時業務對業務的執行時間有明確的時間約束。實時服務總線應具備實時調度能力，盡可能地保證每個任務滿足它們的時間約束。一方面對外部請求做出及時響應，另一方面縮短系統平均響應時間，提高系統資源利用率［10］。

為了使服務總線系統能夠處理實時業務，對JBI標準進行改進，采用優先級驅動策略，按照業務優先級的高低動態分配各類業務流的帶寬。擴展JBI的標準化消息路由組件，增加下列三個組件，如表1所示。

表1 三種不同級別業務類型

1）流量整形漏桶組件

該組件位于服務提供者組件和消息路由組件之間，采用漏桶算法（Leaky Bucket，LB）對業務請求進行流量過濾和整形。如圖2所示，業務請求先被輸入一個緩沖隊列中，漏桶流控組件根據系統分配給該業務的流量帶寬將業務消息放入輸出緩沖隊列中供消息路由組件分發。如果業務請求因為擁塞排隊超過有效時間，漏桶流控組件直接返回超時錯誤消息給綁定組件。

2）流量優先級調度組件

該組件位于服務消費者組件或服務引擎組件和消息路由組件之間。如圖2所示，該組件為每一個業務流建立一個傳輸隊列，消息路由將不同的業務流消息放入相應傳輸隊列中。調度組件使用加權公平隊列算法（Weighted Fair Queuing，WFO），以分配給該業務的帶寬作為權重調度各業務流，將消息路由至其它服務消費者組件或服務引擎組件。WFQ和LB算法共同作用保證總線上各業務流量的穩定。

3）消息路由組件

該組件定時與流量整形漏桶組件通信，實時獲取并記錄各業務輸入流量、業務超時和丟棄情況。當服務提供者組件發生流量擁塞時，該組件能根據總線當前流量情況動態調整分配各業務流帶寬。

圖2 實時服務總線消息處理

3 面向服務的艦載指控系統體系結構

根據艦載指控系統的功能需求及對其軟件體系結構分析，本文構建了“以服務為核心”的多層次模型；并以縱向和橫向分層表達方式將艦載指控系統體系結構劃分為：橫向包括了對象層、構件層、服務層、業務服務層、表示層等五層，以及縱向包括了標準規范、服務集成支撐、基礎公共服務、并行和高可用容錯處理框架四部分。該結構基于SOA 的開放式系統結構體系，充分體現了面向服務的“松耦合”、“即插即用”、“靈活組裝”和“柔性重組”等特點，能有效提高艦載指控系統的技術適應能力、擴展能力、升級適裝、互操作能力。

圖3 服務化的艦載指控系統體系結構圖

1）對象層

對象是面向對象編程語言中基本組織單元，也是構件的組成元素，具有封裝、繼承、多態等特性。當前主流的面向對象編程語言包括了C／C＋＋和JAVA，面向對象編程是當前成熟的編程方法，可快速搭建構件的實現。

2）構件層

構件代表了業務服務的具體實現技術，通過標準化接口暴露業務服務，是艦載指控系統軟件的部署和配置的基本單元。它與具體的實現技術相關，當前主要的構件標準包括了CCM，SCA，OSGi等。

3）服務層

服務層是指艦載指控系統服務集，是艦載指控業務邏輯的基本封裝單元。服務接口描述定義了服務提供者與使用者間的契約，當前服務接口描述方式包括了WSDL，CORBA IDL等方式。

4）流程層

業務服務層把組合服務層的各種服務，根據作戰任務及作戰流程，按照站位進行打包、配置和封裝，以供最終作戰用戶使用。該層對應于指控顯控臺、武器顯控臺、情報顯控臺等設備上的軟件功能。

5）表示層

按照“軟硬件分離、數據與應用分離、顯示與處理分離”的原則，表示層提供標準的人機操控界面，將需要展現的數據展現給操作使用人員。根據使用需求不同劃分為通用操控界面與實時操控界面。通用操控界面為所有非實時需求的作戰設備提供人機操控與數據顯示，通過解析與控制業務層傳送XML數據與數據處理分離。

6）標準規范

標準規范是服務化體系結構中各層軟件所涉及的標準規范的集合，包括了對象層的C／C＋＋、構件層的SCA、CCM 和OSGi、服務層的WSDL和CORBA IDL、流程層的BPEL 以及界面層的Portal Form 等。

7）服務集成支撐

服務集成支撐提供服務運行時的支撐庫和工具，包括了服務總線和應用服務器等內容。其中服務總線面向服務構架的基礎設施和實現平臺，充當連接和集成各種實時／非實時應用系統消息總線，實施了必要抽象層將定義服務的消息轉化成可供業務構件處理的數據，核心功能包括了消息實時傳輸、遠程過程調用、服務注冊與發現等。應用服務器是應用服務配置部署和加載的服務器，是服務構件模型的具體實施。

8）基礎公共服務

基礎公共服務是指開發、集成、管理和監控應用系統的基礎公共服務。

9）并行和高可用框架

基于消息傳遞的并行框架支持，通過帶郵箱的任務實現高度并行，消除了對線程、共享內存和鎖機制等影響并行操作的依賴。

4 基于服務總線的艦載指控系統集成實施方法

基于服務總線的艦載指控應用系統開發集成過程如圖4所示，包括了應用開發、集成、部署、運行和監控等五個過程，對應了五類系統用戶角色：系統開發人員、系統集成人員、系統部署人員、系統管理人員和系統操作用戶。主要的開發步驟如下：

圖4 艦艇指控系統服務化軟件開發及部署圖

1）應用系統開發

系統開發人員利用構件開發工具環境進行單個應用服務構件的開發，生成消息、服務和構件的描述文件；

2）應用系統集成

系統集成人員利用構件集成工具環境根據應用系統功能對多個構件進行集成，包括應用功能組裝、作戰業務流程管理和應用重組容錯等，生成構件應用組裝描述文件、流程定義文件、重組配置描述文件等；

3）應用系統部署

系統部署人員根據應用集成的配置文件，將構件化應用系統從構件庫中下載、安裝和配置到最終的物理臺位；

4）應用系統運行

根據各個作戰臺位的節點的部署配置信息，啟動構件化應用系統各個子功能系統，使作戰應用系統進入運行狀態；系統操作用戶是構件化作戰應用系統的最終操作使用人員；

5）應用系統監控跟蹤

系統管理人員利用應用系統跟蹤監控軟件對作戰系統的信息流和控制流進行實時監控并記錄存儲，并對系統運行狀況進行監控與評價。

5 結語

本文針對艦載指控系統所面臨的易于實現與集成的實際作戰需求，構建了“以服務為核心”的多層次體系結構模型，并在此基礎上提出了工程實施方法及技術解決方案。研究成果對實現具備即插即用、柔性重組、良好的互操作的服務化艦載指控系統，具有重要工程應用價值。

［1］李明，王曉軍.以網絡為中心的美國海軍［M］.北京：國防工業出版社，2008：22-23.

［2］羅雪山，等.指揮信息系統分析與設計［M］.長沙：國防科技大學出版社，2008：55-56.

［3］張維明，等.信息系統建模技術與應用［M］.北京：電子工業出版社，1997：44-45.

［4］楊芙清，梅宏，李克勤.軟件復用與軟件構件技術［J］.電子學報，1999，27（2）：68-75.

［5］邵歡慶，康建初.企業服務總線的研究與應用［J］.計算機工程，2007，32（2）：220-222.

［6］邢少敏，周伯生.SOA 研究進展［J］.計算機科學，2008，135（19）：19-21.

［7］李明.基于CORBA 的分布式MVC 軟件體系結構［J］.計算機工程與科學，2008，30（5）：95-97.

［8］張偉寧，劉列根，張宇.基于消息傳遞的ESB 的研究與應用［J］.微計算機信息，2008，24（9）：18-20.

［9］鐘山，岳祥.WFQ 流量調度算法研究［J］.光通信研究，2006，32（5）：16-18.

［10］彭政，聶瑞華，李飛.基于ServiceMix的SOA 架構的研究與實現［J］.計算機工程與科學，2009，31（4）：153-156.