李 鵬,胡 革2，孫 學

(1.中國西南電子技術(shù)研究所,成都 610036；2.江南計算技術(shù)研究所，江蘇 無錫214083)

1 引 言

現(xiàn)代各級軍事組織的命令、控制、通信、計算機和情報偵察監(jiān)視系統(tǒng)之間的交互變得越來越復雜，希望能夠創(chuàng)建一個戰(zhàn)術(shù)平臺間準確和實時的態(tài)勢共享與交互平臺，并在復雜、惡劣和動態(tài)環(huán)境中維持高效的運作能力[1-2]。為滿足上述應用需求，軍事系統(tǒng)、通信和信息基礎設施變得越來越面向服務，通過采用開放式架構(gòu)原理和概念構(gòu)建以面向服務的架構(gòu)(Service-Oriented Architecture，SOA)為中心的公共核心服務基礎設施，實現(xiàn)資源受限網(wǎng)絡環(huán)境下的系統(tǒng)協(xié)同交互也變得越來越有必要[2]。

美國防部在《2011—2036無人系統(tǒng)綜合路線圖》中已提出采用開放式架構(gòu)和面向服務架構(gòu)SOA的原則，建立一個面向開發(fā)和采辦的通用框架，以提升協(xié)同作戰(zhàn)環(huán)境下的系統(tǒng)互操作性[3]。此外，由Web Service實現(xiàn)的SOA也被北大西洋公約組織(North Atlantic Treaty Organization,NATO)C3機構(gòu)選作NATO內(nèi)部命令控制系統(tǒng)之間信息交互的推薦方法，尤其是在NATO C4ISR系統(tǒng)和NATO網(wǎng)絡使能能力方面，并通過一系列現(xiàn)場和競爭性實驗進行了SOA的可行性評估及性能改進[4]。NATO IST-090工作組詳述了將SOA應用到戰(zhàn)術(shù)層面時所面臨的挑戰(zhàn)，后續(xù)的IST-118號文件進一步細述了在戰(zhàn)術(shù)層面實施SOA的條件，并以規(guī)范的形式給出了將SOA應用到戰(zhàn)場惡劣網(wǎng)絡環(huán)境時的指導和最佳實踐方法[5]。

雖然SOA在互聯(lián)網(wǎng)領域已有較完備的技術(shù)與標準體系，但現(xiàn)有的實現(xiàn)技術(shù)對網(wǎng)絡資源需求較高，并不適用于戰(zhàn)術(shù)網(wǎng)絡環(huán)境，同時對戰(zhàn)術(shù)環(huán)境下SOA架構(gòu)的應用概念、限制性因素及關(guān)鍵技術(shù)等認識還比較模糊。本文將對TSOA架構(gòu)概念、技術(shù)體系進行梳理，重點探討在戰(zhàn)術(shù)領域所面臨的挑戰(zhàn)及關(guān)鍵技術(shù)問題，并對國內(nèi)外相關(guān)發(fā)展情況進行總結(jié)。

2 戰(zhàn)術(shù)面向服務架構(gòu)概念分析

2.1 TSOA概念

SOA是一種架構(gòu)設計風格，使資源以服務的形式提供并被發(fā)現(xiàn)，而不需要提前感知資源的存在。架構(gòu)內(nèi)的服務以一種統(tǒng)一和通用的方式進行交互，可以顯著增強互操作性及信息共享程度，并支持高層應用的彈性設計與靈活可變性。目前實現(xiàn)SOA的最通用和成熟的技術(shù)是Web Service，在信息系統(tǒng)和服務基礎設施中已被廣泛支持與使用。

戰(zhàn)術(shù)面向服務架構(gòu)(Tactical Service-Oriented Architecture,TSOA)的初步設想是將SOA的好處帶到戰(zhàn)術(shù)環(huán)境中，提升各種系統(tǒng)和設備在戰(zhàn)術(shù)層面的互操作性，將不同類型戰(zhàn)術(shù)邊緣節(jié)點上的功能單元通過定義良好的接口和契約聯(lián)系起來，進一步通過對底層基礎應用的編排或者組織實現(xiàn)如協(xié)同探測、協(xié)同攻擊和協(xié)同干擾等高層應用功能。TSOA的最終目標是實現(xiàn)戰(zhàn)術(shù)服務基礎設施(Tactical Service Infrastructure,TSI)，致力于解決SOA技術(shù)在戰(zhàn)術(shù)領域的應用問題，增強跨平臺戰(zhàn)術(shù)邊緣節(jié)點的互操作性，減少集成和維護開銷，提升復用率，通過服務能力的發(fā)現(xiàn)組合與編排增加對需求更改的敏捷反映能力，構(gòu)建以TSOA為中心的戰(zhàn)術(shù)服務基礎設施平臺[2]。

圖1給出了TSOA與傳統(tǒng)SOA的應用差異性對比。其中，在功能目標方面，TSOA與常規(guī)SOA具有相同的目標，即通過標準化的接口封裝與互操作規(guī)范，實現(xiàn)不同業(yè)務系統(tǒng)之間的互操作性和信息共享能力；在運行環(huán)境方面，運行TSOA的戰(zhàn)術(shù)環(huán)境基礎設施節(jié)點移動性更強，資源與網(wǎng)絡帶寬受限，網(wǎng)絡可靠性更低；在交互對象及內(nèi)容方面，相較于常規(guī)SOA，TSOA的參與對象通常計算能力受限，服務交互的內(nèi)容吞吐量較低，交互信息粒度更大。

圖1 常規(guī)SOA與TSOA應用差異性對比Fig.1 Comparison between regular SOA and TSOA

2.2 TSOA架構(gòu)組成

參照常規(guī)SOA架構(gòu)組成，同時結(jié)合TSOA目標及其部署場景的特殊性以及交互差異性[2]，給出如圖2所示的TSOA服務基礎設施層架構(gòu)。其中，無線電接入層包含戰(zhàn)術(shù)環(huán)境下不同形式的通信方式，每種通信方式都需要提供標準化的數(shù)據(jù)收發(fā)與網(wǎng)絡狀態(tài)獲取接口，并按約定模式接入戰(zhàn)術(shù)服務基礎設施的傳輸機制接入模塊；服務能力抽象與接入部分實現(xiàn)設備節(jié)點資源能力和服務的規(guī)范化描述，并通過標準接口向平臺進行注冊；上層信息系統(tǒng)借助戰(zhàn)術(shù)服務基礎設施的標準化接口從服務注冊機構(gòu)內(nèi)查詢所需服務，并按照約定形式進行服務調(diào)用，還可以通過對不同設備間的服務交互流程進行編排，實現(xiàn)更高層的戰(zhàn)術(shù)應用。

圖2 TSOA服務基礎設施層架構(gòu)圖Fig.2 TSOA service infrastructure layer architecture

戰(zhàn)術(shù)服務基礎設施TSOA架構(gòu)模塊是其中的核心組成部件，主要分為三部分：

(1)傳輸處理模塊實現(xiàn)服務、消息和數(shù)據(jù)包層面的跨平臺間服務交互內(nèi)容的轉(zhuǎn)發(fā)、格式轉(zhuǎn)換等傳輸處理，支持跨網(wǎng)絡的數(shù)據(jù)包路由交換，并適配不同網(wǎng)絡間的消息傳輸能力以及運行上下文信息。對于服務層傳輸處理，根據(jù)需要對接收到的消息內(nèi)容進行修改，如進行圖像數(shù)據(jù)壓縮處理、消息內(nèi)容格式轉(zhuǎn)換、編碼形式修改等，以及實現(xiàn)服務消息負載的動態(tài)自適應處理；對于消息層傳輸處理，通過對接收數(shù)據(jù)消息頭的分析，實現(xiàn)不同網(wǎng)絡間消息的存儲轉(zhuǎn)發(fā)等處理；對于數(shù)據(jù)包層傳輸處理，則直接通過分析數(shù)據(jù)包頭實現(xiàn)后續(xù)的轉(zhuǎn)發(fā)等處理。

(2)控制器模塊是TSOA服務交互平臺的核心部分，包含與常規(guī)SOA架構(gòu)類似的QoS管理、元數(shù)據(jù)管理、封包管理、服務注冊、服務發(fā)現(xiàn)、運行策略管理、上下文監(jiān)控、安全管理、命名服務等功能，為平臺使用者提供標準化的服務注冊、查詢、注銷、狀態(tài)監(jiān)控等接口，并能夠在復雜戰(zhàn)術(shù)環(huán)境下提供可靠的、魯棒的和高效的運行能力。

(3)傳輸機制接入模塊提供插件式接入能力，向下實現(xiàn)底層不同無線通信方式的標準化接入，向上為服務交互應用提供不同類型的傳輸保障機制。此外，該模塊還應能夠監(jiān)控網(wǎng)絡當前的運行狀態(tài)，并反饋給節(jié)點上的服務提供者與使用者，使其能夠根據(jù)網(wǎng)絡狀況做出適應性的調(diào)整。

2.3 TSOA架構(gòu)特征

結(jié)合運行場景及戰(zhàn)術(shù)設備特征，TSOA架構(gòu)及其實現(xiàn)技術(shù)應具有輕量化、可裁剪和跨平臺部署一致性特征。

(1)輕量化層面

TSOA框架應具備服務管理和交互、運行生命周期管理等基礎功能，同時具備部署簡單、運行效率高、啟動快、規(guī)則精簡、空間資源需求少、程序代碼耦合度小等特點。應用層面?zhèn)戎赜跍p小開發(fā)復雜度，簡化編程模型，縮短應用部署時間；設計層面應側(cè)重于提升開發(fā)和運行效率，降低對于運行平臺的能力需求；運行層面應側(cè)重于降低系統(tǒng)資源開銷，以適配戰(zhàn)術(shù)環(huán)境下設備配置低，平臺運行能力弱的特征[6]。

(2)可裁剪層面

從裝備型譜來看，戰(zhàn)術(shù)邊緣裝備包含大量異構(gòu)環(huán)境，如手持、背負、車載、艦載和機載等，存在軟件運行環(huán)境差異較大的問題，因此TSOA框架應在協(xié)同交互等必備功能的基礎上，同時支持備選功能的可裁剪性，以適應具備不同功能、可靠性和能量的平臺的差異性需求。

(3)跨平臺部署一致性層面

TSOA框架應能夠適配多種類型的運行平臺，實現(xiàn)不同平臺上的部署一致性、接入一致性、開發(fā)一致性、接口一致性和描述方式一致性，為開發(fā)者與平臺接入服務提供一致性的應用模式，使得原來對于不同平臺割裂的開發(fā)實踐趨于統(tǒng)一。

3 TSOA面臨的挑戰(zhàn)及關(guān)鍵問題

3.1 面臨的挑戰(zhàn)

戰(zhàn)術(shù)環(huán)境下的設備節(jié)點、通信鏈路相較于傳統(tǒng)SOA運行環(huán)境更加復雜，需要充分分析，并意識到將SOA擴展到戰(zhàn)術(shù)環(huán)境時所面臨的挑戰(zhàn)[2]。

圖3對戰(zhàn)術(shù)環(huán)境下的限制性因素進行了總結(jié)，主要分為設備限制性因素和網(wǎng)絡限制性因素兩類，其中設備限制因素包括計算能力、能量限制、物理限制、發(fā)送/接收覆蓋范圍、輸入/輸出限制、環(huán)境條件限制和網(wǎng)絡互連能力等；網(wǎng)絡限制又分為通信能力、通信中斷、移動性和互操作性等。

圖3 戰(zhàn)術(shù)環(huán)境限制性因素分解示意圖Fig.3 Constrains in a tactical environment

設備限制性因素主要來自于戰(zhàn)術(shù)環(huán)境中不同類型作戰(zhàn)節(jié)點的自身能力特性。例如，機載、車載以及船載等強平臺設備通常具有較強的計算能力，通信覆蓋范圍廣，能夠接入的輸入/輸出類型豐富；而手持和背負式移動終端等弱平臺則僅具有有限的計算資源以及電池電量，對于功耗開銷和環(huán)境限制敏感，通信覆蓋范圍、網(wǎng)絡互連與交互能力以及安全保障機制都較弱。

網(wǎng)絡限制性因素主要來自于設備的通信機制以及實際戰(zhàn)場運行環(huán)境。戰(zhàn)場的復雜電磁環(huán)境會給設備通信系統(tǒng)的可用頻譜、通信范圍以及誤碼率等造成影響[7]。設備的能量變化會導致通信距離變化，彼此之間的頻譜干擾與沖突可能造成通信中斷，設備的無線電靜默還會進一步導致缺乏保障性的數(shù)據(jù)分發(fā)能力，使得服務間的連接與交互面臨許多困難。另外，戰(zhàn)術(shù)操作的內(nèi)在特征通常要求作戰(zhàn)單元具有高移動性，需要頻繁加入和退出不同的無線網(wǎng)絡，變化的網(wǎng)絡拓撲給設備的服務發(fā)現(xiàn)、地址規(guī)劃、安全交互等帶來了更大挑戰(zhàn)。由于戰(zhàn)術(shù)環(huán)境中設備類型及通信體制的多樣性，還必須處理異構(gòu)無線電設備、協(xié)議和服務以及應用之間的互操作問題。此外，實際環(huán)境中的地形、障礙物等條件還會改變無線電覆蓋范圍，導致高通信時延、吞吐量動態(tài)變化、網(wǎng)絡帶寬受限以及連接不可靠等問題，嚴重影響服務管理以及服務交互協(xié)議的有效性和傳輸成功率。

3.2 關(guān)鍵問題

TSOA架構(gòu)應在實現(xiàn)常規(guī)SOA能力的基礎上，適應上述戰(zhàn)術(shù)環(huán)境的限制性特征，實現(xiàn)具備資源高效、時延和抗毀性容忍等特征的戰(zhàn)術(shù)服務基礎設施平臺，因此需要重點關(guān)注并解決如下關(guān)鍵問題：

(1)異構(gòu)通信網(wǎng)絡兼容問題

目前，SOA的主要實現(xiàn)技術(shù)Web Service的所有通信都基于XML描述的SOAP消息。SOAP消息通過HTTP協(xié)議傳輸，HTTP基于的TCP/IP協(xié)議需要在服務提供者和使用者間建立可靠連接。然而在戰(zhàn)術(shù)環(huán)境下，可能存在多種通信體制，并且無法實現(xiàn)基于IP的通信協(xié)議。但考慮到后期兼容性等問題，NATO的策略是借鑒民用標準，盡可能采用COTS產(chǎn)品，在所有的網(wǎng)絡類型中IP應能夠作為通用的網(wǎng)絡協(xié)議。但由于不同的戰(zhàn)術(shù)網(wǎng)絡間存在時延、帶寬以及通信協(xié)議的差異性等問題，實際環(huán)境中可能會形成不同的IP子網(wǎng)，這就可能要求TSOA解決連接不同IP子網(wǎng)，實現(xiàn)跨網(wǎng)絡之間的TCP數(shù)據(jù)通信、帶寬差異適配等功能。另外，戰(zhàn)術(shù)環(huán)境下變化的網(wǎng)絡拓撲還意味缺少連接保障機制[8]。因此，如何確保跨異構(gòu)網(wǎng)絡的通信兼容是TSOA需要解決的關(guān)鍵問題。

(2)服務管理問題

服務分發(fā)和獲取是TSOA服務管理的重要組成部分。在高動態(tài)環(huán)境下，服務發(fā)現(xiàn)架構(gòu)應該盡量減少手動配置工作量，能夠提供一個完整的和給定時間點及時更新的可用服務快照，支持自動發(fā)現(xiàn)和相關(guān)服務的選擇。此外，動態(tài)變化的網(wǎng)絡環(huán)境以及無線電靜默意味缺乏保障性的服務分發(fā)能力，動態(tài)環(huán)境下的無線連接可能僅具備有限的網(wǎng)絡能力，TSOA還應該能夠在設備和網(wǎng)絡部分失效的情況下維持服務管理功能，并且具有帶寬高效的特征，確保注冊機構(gòu)失效或者消失時服務發(fā)現(xiàn)的可用性、魯棒性、可存活性是很重要的。服務發(fā)現(xiàn)基礎設施還必須提供最新的可用服務列表，請求響應能夠反映出服務網(wǎng)絡和設備的當前狀態(tài)。因此，如何實現(xiàn)具備位置和能力感知、及時動態(tài)更新、帶寬高效以及魯棒的服務動態(tài)分發(fā)、獲取和狀態(tài)管理機制是TSOA需要解決的關(guān)鍵問題[6]。

(3)服務交互問題

常規(guī)SOA應用中的消息通常使用重量級的格式和協(xié)議實現(xiàn)，如TCP/IP、HTTP、XSD/XML、SOAP、WS-*等，其中XML和HTTP是許多SOA實現(xiàn)的基礎組成部分。戰(zhàn)術(shù)環(huán)境下，由于缺乏可靠的連接保障機制以及帶寬受限等原因，請求響應協(xié)議和基于XML的數(shù)據(jù)格式會因為時延和負載資源消耗原因可能被禁用，需要考慮高效的服務交互機制或替代方案，如通過數(shù)據(jù)壓縮、取代傳輸協(xié)議或者優(yōu)化應用的方式來減輕通信負載。戰(zhàn)術(shù)環(huán)境下，通信網(wǎng)絡帶寬還會隨地形環(huán)境和節(jié)點移動產(chǎn)生變化，這就要求交互過程中能夠感知通信鏈路狀況，向服務提供者和使用者反饋網(wǎng)絡狀態(tài)，實現(xiàn)動態(tài)自適應調(diào)整。因此，如何在不穩(wěn)定、帶寬受限和動態(tài)變化的環(huán)境下實現(xiàn)服務的可靠有效交互也是TSOA需要解決的關(guān)鍵問題。

(4)安全問題

戰(zhàn)術(shù)網(wǎng)絡環(huán)境下，大量的服務業(yè)務數(shù)據(jù)需要在不同的參與者之間進行垂直或者水平交換，相較于常規(guī)SOA需要更加嚴格的安全保障機制。為了確保TSOA架構(gòu)的安全運行，需要從參與節(jié)點、交互對象以及數(shù)據(jù)內(nèi)容等不同層面出發(fā)，針對不同服務類型和等級制定不同的安全策略，對于服務管理、交互過程中的數(shù)據(jù)需要采用加密機制，對于服務提供和使用者需要采用有效的身份驗證機制確保服務交互雙方的合法性等。如何結(jié)合戰(zhàn)術(shù)網(wǎng)絡環(huán)境特征，制定合適的服務訪問控制與安全的數(shù)據(jù)交互協(xié)議框架，確保服務管理和交互的安全性，是決定TSOA能否實際應用的關(guān)鍵問題。

4 TSOA相關(guān)技術(shù)

目前，傳統(tǒng)通過Web Service實現(xiàn)的SOA主要應用在指揮部等高層命令系統(tǒng)中。雖然SOA也被推薦在戰(zhàn)術(shù)層面C2中使用，卻面臨多重挑戰(zhàn)。針對戰(zhàn)術(shù)環(huán)境下面臨的挑戰(zhàn)及問題，需要開發(fā)、裁剪、評估那些最適用于TSOA的技術(shù)、技巧和協(xié)議。

4.1 服務發(fā)現(xiàn)機制

互聯(lián)網(wǎng)中現(xiàn)有大量的服務發(fā)現(xiàn)方法。然而，相對戰(zhàn)術(shù)網(wǎng)絡面臨的新挑戰(zhàn)，仍有很大的研究空間。服務發(fā)現(xiàn)涉及兩方面問題：一是注冊機構(gòu)內(nèi)可用服務描述的組織和管理；二是服務發(fā)現(xiàn)協(xié)議，其實現(xiàn)機制與注冊機構(gòu)的架構(gòu)相關(guān)，如中心式、分布式。

(1)服務注冊

早期的服務注冊主要通過使用WSDL對服務進行描述，并使用有中心形式的UDDI實現(xiàn)服務注冊，但由于WSDL主要對服務接口特征進行描述，無法描述服務的QoS等語義特征，因此后期的研究工作中則通過采用OWL-S來實現(xiàn)服務的語義描述，以改進UDDI數(shù)據(jù)模型和它基于關(guān)鍵字檢索的查詢機制。事實上，服務注冊機構(gòu)管理的服務信息的語義標注需要額外的工作。另一個研究內(nèi)容是從現(xiàn)有的服務注冊方法中抽取語義信息，形成(半)自動化方式。

(2)服務發(fā)現(xiàn)

服務發(fā)現(xiàn)協(xié)議的基本方法是中心式，依靠一個中心節(jié)點來組織和管理服務描述。這種方法在正常環(huán)境下可以提供快速的本地檢索，但當客戶端數(shù)量增加時中心式方法的可擴展性較差；另外，還存在單點失效問題。在由很多獨立移動節(jié)點組成的戰(zhàn)術(shù)環(huán)境中，問題更加明顯。

TSOA服務發(fā)現(xiàn)機制的目標是遵循目前互聯(lián)網(wǎng)領域相關(guān)標準，改進現(xiàn)有注冊機制，通過建立領域本體庫的方式，增加語義級別的服務描述能力，從而提高服務匹配的準確率和有效性。通過考慮分布式本地存儲服務目錄的方法，在網(wǎng)絡的參與者之間形成P2P機制，減少服務發(fā)現(xiàn)的相關(guān)必要流量，通過基于WS-Notification規(guī)范的訂閱發(fā)布機制，可以實現(xiàn)基于服務訂閱以及消息發(fā)布機制的服務分發(fā)。實現(xiàn)過程中，還需要真正考慮到戰(zhàn)術(shù)網(wǎng)絡的特征，如無線移動網(wǎng)絡的限制性因素、用戶行為和移動性、設備資源受限等。

4.2 有效的消息傳輸方式

Web Service使用XML來編解碼數(shù)據(jù)，并使用SOAP等重量級格式和協(xié)議傳輸數(shù)據(jù)。戰(zhàn)術(shù)環(huán)境下需要減少由于Web Service造成的網(wǎng)絡負載開銷，必須減少每個消息的大小以及傳輸?shù)南?shù)量，因此可以從如下三個層面進行考慮，最優(yōu)化SOAP消息的傳遞性能，避免對戰(zhàn)術(shù)網(wǎng)絡中不足的無線網(wǎng)絡資源的浪費。

(1)數(shù)據(jù)壓縮

通過數(shù)據(jù)壓縮來減輕XML文件造成的網(wǎng)絡負載，如二進制算術(shù)編碼BAC、EFX和GZIP等[9]。利用壓縮技術(shù)可以減少每個消息大小和帶寬需求，但不會減少節(jié)點之間發(fā)送的消息數(shù)量。

(2)協(xié)議優(yōu)化

通過取代傳輸協(xié)議來減輕通信負載[10]。Web Service的通信開銷在限制性網(wǎng)絡環(huán)境下需要一種優(yōu)化的資源使用方案，如所圖4示。文獻[11]提出了一個用于動態(tài)環(huán)境下SOAP性能分析的測試框架SPADE，選用UDP、SCTP和AMQP傳輸協(xié)議來替代HTTP/TCP進行優(yōu)化測試，并在幾種特定的民用和軍用網(wǎng)絡環(huán)境下進行了評估測試。

圖4 SPADE架構(gòu)概要Fig.4 SPADE framework overview

(3)減少交互

通過使用訂閱/發(fā)布模式，客戶端訂閱信息，而不是請求模式[12]。消息傳輸過程中，允許相同信息發(fā)送給多個客戶端，交互過程中利用附近客戶端的緩存，通過優(yōu)化應用的信息交換需求來降低信息負載。服務發(fā)現(xiàn)通過考慮本地服務目錄的方法，減少交互的必要流量。交互過程中，進一步結(jié)合內(nèi)容過濾的方法，確保僅僅相關(guān)的數(shù)據(jù)被傳輸。文獻[13]提出了一種支持戰(zhàn)術(shù)網(wǎng)絡運行SOA的敏捷計算中間件，將針對TCP或UDP協(xié)議的抗毀性Mockets協(xié)議替換為一種智能的訂閱發(fā)布服務，并利用智能化處理和網(wǎng)絡監(jiān)視器適應網(wǎng)絡流量變化。

4.3 端到端服務性能保障機制

目前確保戰(zhàn)術(shù)無線通信網(wǎng)絡中服務質(zhì)量的研究主要集中在增加帶寬，提升傳輸可靠性，以及如何使用網(wǎng)絡編碼技術(shù)、動態(tài)頻譜技術(shù)、魯棒路由協(xié)議和跨層的自適應機制等方面。實際應用中，還需要調(diào)查并量化TSOA在各種戰(zhàn)術(shù)環(huán)境中應用QoS需求的網(wǎng)絡負載情況。通過QoS策略規(guī)范，實現(xiàn)基于優(yōu)先級順序的信息分發(fā)，對任意給定服務，能夠制定不同的服務分發(fā)等級。通過制定服務訪問控制機制，確保只有授權(quán)的消費者能夠訪問給定的服務。通過提供負載編解碼、內(nèi)容完整性和簽名機制，確保只有具有正確的解碼Key的消費者能夠訪問內(nèi)容，還能夠檢查內(nèi)容的完整性，根據(jù)服務請求發(fā)起者的簽名，提供端到端的QoS分發(fā)服務[14]。

4.4 網(wǎng)絡狀態(tài)自適應機制

節(jié)點移動性、資源受限設備、大量異構(gòu)的無線通信技術(shù)以及經(jīng)常變化的環(huán)境條件，意味著運行在戰(zhàn)術(shù)環(huán)境中的分布式應用需要應對頻繁的連接斷開以及無線電通信狀態(tài)波動，從而要求上層應用具備網(wǎng)絡感知和自適應的能力，能夠靈活調(diào)節(jié)自身配置參數(shù)，以匹配網(wǎng)絡狀況的變化情況。

服務架構(gòu)應實現(xiàn)底層網(wǎng)絡拓撲知識管理，使得服務總線能夠?qū)W習傳輸層的能力和負載情況；然后，服務總線能夠找到最優(yōu)的方式和路徑連接提供者和消費者，從而執(zhí)行最優(yōu)的服務路由。另外，服務應該能夠根據(jù)網(wǎng)絡狀態(tài)進行調(diào)整，具備自適應網(wǎng)絡感知與調(diào)整能力，使得能夠適應運行環(huán)境的改變。

文獻[15]提出了一種具備動態(tài)檢測和自適應機制(DDAM)的分布式和可擴展敏捷通信中間件解決方案，用于網(wǎng)絡檢測和通信自適應。該中間件能夠獲取、分析、共享網(wǎng)絡中的流量統(tǒng)計和分析結(jié)果，尤其適用于戰(zhàn)術(shù)邊緣網(wǎng)絡。DDAM包含兩個主要部件：NetSensor提供高效的網(wǎng)絡狀態(tài)監(jiān)控功能；NetSupervisor負責刻畫用于連接節(jié)點的網(wǎng)絡技術(shù)特征。DDAM的目標是提升可用網(wǎng)絡資源，并可以通過檢測網(wǎng)絡狀態(tài)自適應動態(tài)調(diào)整自身行為方式。圖5給出了DDAM實際部署的示意圖。

圖5 DDAM部署示意圖Fig.5 Example of DDAM deployment

4.5 跨異構(gòu)網(wǎng)絡的服務信息交互

戰(zhàn)術(shù)異構(gòu)網(wǎng)絡環(huán)境下需要解決Web Service實施時面臨的兩項關(guān)鍵技術(shù)：

(1)帶寬匹配

在戰(zhàn)術(shù)網(wǎng)絡環(huán)境下，當多個使用者同時使用低速網(wǎng)絡時，由于資源共享的原因可能會導致有效數(shù)據(jù)率變得很低，當將這種網(wǎng)絡和更快速的網(wǎng)絡連接時，兩個網(wǎng)絡的網(wǎng)關(guān)節(jié)點會由于兩端速率不匹配而丟包[8,16]。這個問題可以通過引入存儲-轉(zhuǎn)發(fā)的能力解決。存儲-轉(zhuǎn)發(fā)模式還有助于緩解由于頻繁的通信中斷帶來的問題，確保消息不被丟失，并在接下來進行重發(fā)，從而避免消息被立即重發(fā)。當跨越異構(gòu)網(wǎng)絡時，可能需要不同的通信協(xié)議，這意味著消息在從發(fā)送者到接收者的傳遞過程中必須使用多種不同的協(xié)議。因此，可在應用層添加存儲-轉(zhuǎn)發(fā)功能，實現(xiàn)跨協(xié)議的服務交互通信[8]。

(2)端到端連接

常規(guī)Web Service依賴于客戶端和服務端之間直接的端到端連接。TCP是為有線網(wǎng)絡設計的面向連接通信機制，其控制機制主要是為處理擁塞設計的，運行過程中通常存在較少的錯誤處理。由于戰(zhàn)術(shù)網(wǎng)絡下的高錯誤率和高延時，TCP的擁塞控制將會由于大量的連接超時產(chǎn)生大量的網(wǎng)絡非最優(yōu)化利用。當多個網(wǎng)絡互連時，TCP需要建立端到端連接，從而加重這個問題。如果連接超時，SOAP響應就不能夠被路由返回到服務消費者。連接不可靠性問題以及高錯誤率問題必須采用可靠的消息傳輸機制進行補償，如重傳所有到消費者的丟失數(shù)據(jù)包。如圖6所示，可以通過在位于客戶端和服務端網(wǎng)絡之間的網(wǎng)絡流經(jīng)節(jié)點增加服務代理，服務代理可以有多個目的，如緩存、防火墻、內(nèi)容適配等。Web Service代理和HTTP代理具有相同的作用，它的工作就是作為服務提供者和消費者之間的中間人。

圖6 通過代理的跨異構(gòu)網(wǎng)絡服務交互Fig.6 Heterogeneous network service interaction via proxy

跨異構(gòu)網(wǎng)絡交互還可能加重傳輸?shù)目勺儠r延，如生產(chǎn)者和消費者之間的多跳等問題，需要在傳輸協(xié)議棧中增加特殊的適配，這點類似于傳統(tǒng)網(wǎng)絡，可以通過使用非連接協(xié)議、增加包超時時間、延時容忍協(xié)議等技術(shù)解決。

4.6 安全性策略

戰(zhàn)術(shù)服務交互基礎設施必須提供支持信息交換、服務發(fā)布和共享、數(shù)據(jù)模型和協(xié)議處理的安全框架。安全框架中需要考慮不同層次和不同限制性因素的安全策略，通過一種多策略架構(gòu)實現(xiàn)支持不同的業(yè)務和信息跨層交互的安全機制。在信息層面包含基于強加解密標準和密碼，通過使用創(chuàng)新式的Key發(fā)布機制以確保信息只有被授權(quán)的用戶能夠訪問。另外，對于消息層面的安全，可以通過分析WS-Security、WS-Policy和WS-Security Policy協(xié)議的技術(shù)實現(xiàn)，通過SAML在不同的安全域之間交換認證和授權(quán)數(shù)據(jù)。對于戰(zhàn)術(shù)網(wǎng)絡環(huán)境下的非數(shù)據(jù)服務，如聲音、視頻流、實時告警數(shù)據(jù)等，還可以借助其他加解密策略提升安全性[17]。

TACTICS開發(fā)的安全架構(gòu)由兩個不同的服務組構(gòu)成，即核心服務和功能服務。功能服務負責通過不同的機制，如加密算法、訪問控制、入侵檢測等執(zhí)行必備的保護目標；核心服務則根據(jù)預先定義的安全策略來管理這些機制[18]。特別需要注意的是，安全架構(gòu)的設計與開發(fā)過程中，要考慮到戰(zhàn)術(shù)網(wǎng)絡環(huán)境的特征，制定輕量級和優(yōu)化的安全機制。

5 TSOA相關(guān)工作進展

2011年美國國防部發(fā)布的《2011—2036財年無人系統(tǒng)綜合路線圖》中提出了建立面向開發(fā)和采辦的通用框架，并采用面向服務架構(gòu)SOA標準來設計軟件和集成新服務，促進系統(tǒng)之間的互操作性[3,19]。同年，美國空軍研究實驗室ARL制定了關(guān)于TSOA協(xié)議與技術(shù)的研究計劃，重點關(guān)注將SOA應用到戰(zhàn)術(shù)邊緣需要解決的問題，并提出TSOA是USMC對于DoD指示(DoDD 8320.02,2004,該指示指出采用和實施TSOA作為一個標準組件來管理各軟件部件，并實現(xiàn)不同作戰(zhàn)運行單元間的關(guān)鍵數(shù)據(jù)共享)在戰(zhàn)術(shù)層面的回應。TSOA兼容性機制已經(jīng)在所有海軍C2軟件系統(tǒng)得到批準，過去以及當前的新系統(tǒng)將約束服務提供商以及使用者利用TSOA作為分布式機制，確保這些系統(tǒng)能夠與TSOA系統(tǒng)實現(xiàn)交互[20]。

結(jié)合戰(zhàn)場的限制性環(huán)境因素，歐洲提出了TACTICS戰(zhàn)術(shù)服務基礎設施架構(gòu)。TACTICS聯(lián)盟由12個成員和轉(zhuǎn)包商組成，研究的項目提出了兼容戰(zhàn)術(shù)無線電網(wǎng)絡限制環(huán)境的SOA架構(gòu)定義，給出了將服務應用于戰(zhàn)術(shù)無線電網(wǎng)絡限制環(huán)境的可行方法，論證了在真實戰(zhàn)術(shù)環(huán)境下支撐服務運行的戰(zhàn)術(shù)服務基礎設施的能力。TACTICS明確的目標是高移動性、資源非常受限的設備。TACTICS服務堆棧中也期望具備抗毀性特征，以滿足資源受限和高動態(tài)移動戰(zhàn)術(shù)環(huán)境的需求。另外，相對于現(xiàn)有堆棧，TACTICS將通過服務定義的語義性、位置和能力感知的服務選擇機制更有效地輔助服務使用[2]。

北大西洋公約組織NATO的STO組織也發(fā)起了SOA在戰(zhàn)術(shù)通信網(wǎng)絡環(huán)境下有效實現(xiàn)的項目，并對戰(zhàn)術(shù)環(huán)境特征以及TSOA的應用場景進行了分析，如圖7所示。目前SOA方法已經(jīng)被NATO C3機構(gòu)選擇作為NATO內(nèi)部信息交互的推薦方法。

圖7 TSOA戰(zhàn)術(shù)域用例Fig.7 Use case of TSOA in a tactical domain

NATOIST-090工作組對SOA在戰(zhàn)術(shù)環(huán)境下的應用挑戰(zhàn)進行了分析[4]，說明了如何將SOA應用到戰(zhàn)術(shù)層面，其中特別包括惡劣網(wǎng)格通信環(huán)境，給出了應用SOA解決方案的優(yōu)劣勢、限制性因素，以及在應用層、消息和傳輸層的堆棧優(yōu)化方法，并討論了3種將SOA擴展到戰(zhàn)術(shù)域的可能方法：改變現(xiàn)有的Web Service標準，以應用到惡劣網(wǎng)格環(huán)境中；在特定的子系統(tǒng)中使用其他技術(shù)，如DDS等，并通過使用網(wǎng)關(guān)實現(xiàn)這些技術(shù)與Web Service的集成；在整個信息基礎設施中使用其他技術(shù)。

NATOIST-118號文件《戰(zhàn)術(shù)域惡劣網(wǎng)絡環(huán)境下的SOA推薦實施方法》是NATO工作組新開始的工作[5]，細述了在戰(zhàn)術(shù)層面實施SOA的條件，目標是將SOA拓展到戰(zhàn)術(shù)領域時提供具體的建議和指導。該組織將通過一系列現(xiàn)場和競爭性的實驗，來實施可行性評估，以識別TSOA的可能性改進。由于Web Service帶來的內(nèi)在交互優(yōu)勢，未來的IST-118將主要精力集中在這項技術(shù)上。如圖8所示，一系列實驗正在計劃，以評估和識別可能的改進措施。

圖8 NATO TSOA實物測試場景示例Fig.8 NATO TSOA actual test scenario example

CoNSIS是一個基于MoU(包括美國、法國、德國、挪威)的國際項目[21]，致力于不同國家網(wǎng)絡間的協(xié)同工作能力，任務是連接德國和挪威的SOA研究環(huán)境，這些環(huán)境采用了不同的實施范例，但是和Web Service標準相近。CoNSIS考慮了高移動性應用，但重點關(guān)注于提升現(xiàn)有ESB(如開源SOPERA總線)的性能，并沒有在小型設備中得到驗證。

德國的SOA環(huán)境是一個基于Apache CxF實現(xiàn)的ESB，稱為RuDi[2]。RuDi提供了戰(zhàn)術(shù)層面的服務環(huán)境，可用于移動環(huán)境，但需要功能性強的設備支撐。為了提高在限制性戰(zhàn)術(shù)網(wǎng)絡環(huán)境下的性能，RuDi提供了分布式服務注冊、可靠性UDP、QoS支持、通過WS-Notification實現(xiàn)的基于訂閱發(fā)布機制的多播以及SOAP消息壓縮等機制。挪威國防研究機構(gòu)在TSOA方面也開展了大量的研究。挪威的SOA研究項目由多個松耦合的服務集合組成，通過WS-Discovery維持服務實例感知，并實現(xiàn)了包含存儲轉(zhuǎn)發(fā)功能的DSProxy代理。代理之間通過UDP進行通信，避免TCP連接帶來的帶寬開銷和高時延等問題。

此外，為了加快TSOA相關(guān)實施技術(shù)研究，受NATO STO/IST-118組織的安排，2016年專門召開了針對戰(zhàn)術(shù)領域SOA應用的國際會議ICMCIS，重點針對受限網(wǎng)絡環(huán)境下SOA的服務架構(gòu)、設計、部署和應用性能等問題開展研究，希望能夠?qū)ν苿覶SOA的技術(shù)發(fā)展及具體實施提供技術(shù)支持。

6 結(jié)束語

軍事系統(tǒng)、通信和信息基礎設施變得越來越面向服務，采用SOA架構(gòu)的原理和概念變得越來越有必要。本文從TSOA架構(gòu)的概念出發(fā)，分析了戰(zhàn)術(shù)環(huán)境下TSOA面臨的挑戰(zhàn)及關(guān)鍵問題，歸納了TSOA實施所需要解決的相關(guān)技術(shù)，最后總結(jié)了相關(guān)工作進展情況，旨在推進SOA架構(gòu)在戰(zhàn)術(shù)領域的技術(shù)成熟度與實際應用，從而加速戰(zhàn)術(shù)環(huán)境下服務基礎設施平臺的構(gòu)建步伐。