沈文亮

摘要：針對目前現(xiàn)代化聯(lián)合作戰(zhàn)的參戰(zhàn)軍種多元化、作戰(zhàn)原則統(tǒng)一等特點，提出了一種基于B/S架構(gòu)的軍事想定文書的協(xié)同編輯方法，通過建立長連接、操作轉(zhuǎn)換等技術，實現(xiàn)了想定文書的實時在線協(xié)同編輯，支持多人既獨立又聯(lián)動地編輯自己的想定文書部分，最終構(gòu)建成一個完整的軍事想定，該方法已經(jīng)通過技術驗證，投入生產(chǎn)使用。

關鍵詞：軍事想定；協(xié)同編輯；聯(lián)合作戰(zhàn)

中圖分類號：TP393文獻標志碼：A文章編號：1008-1739（2023）04-46-4

0引言

在軍事演習的準備階段，需要擬制軍事想定，想定[1]是指敵我雙方基本態(tài)勢、作戰(zhàn)企圖和作戰(zhàn)發(fā)展情況的設想，是根據(jù)訓練課題、目的、敵我編制與作戰(zhàn)特點結(jié)合實際地形而擬制的，組織和誘導戰(zhàn)役、戰(zhàn)術演習和作戰(zhàn)的基本文書。

隨著我國軍事改革的深入進行，對作戰(zhàn)指揮體制的聯(lián)合性、時效性、精確性要求越來越高，對于作戰(zhàn)前軍事想定的編輯也有了新的需求，跨平臺、分布式、實時性成為了擬制想定文書軟件發(fā)展的必然趨勢。因此，本文提出了一種基于瀏覽器/服務器（B/S）架構(gòu)的集成分布式文件系統(tǒng)的想定文書協(xié)同編輯系統(tǒng)的方法，并且已經(jīng)通過技術驗證投入應用。

1想定編輯現(xiàn)狀

1.1當前作戰(zhàn)形式特點

在一體化聯(lián)合作戰(zhàn)的大環(huán)境下，作戰(zhàn)訓練具有參戰(zhàn)軍種多元化、作戰(zhàn)目的明確、作戰(zhàn)原則統(tǒng)一和作戰(zhàn)體系完整等特點，聯(lián)合作戰(zhàn)的特點也決定了想定文書編輯時不同軍種、不同專業(yè)的人既需要分工合作，又需要遵循統(tǒng)一的作戰(zhàn)原則，在共同原則的指導下籌劃組織作戰(zhàn)和指揮控制部隊行動，使各作戰(zhàn)力量和作戰(zhàn)行動形成一個相互支持、相互聯(lián)動的統(tǒng)一整體。

1.2想定編輯軟件的實現(xiàn)方式

想定文書編輯一般有3種實現(xiàn)方式：

①單機獨立編輯：由單個計算機實現(xiàn)完成某個想定文書的編輯，或者由多個計算機相互獨立完成各自的想定文書。這種實現(xiàn)方式的優(yōu)點是實現(xiàn)簡單、操作簡單，一人負責文書的編輯，適合小型單一化訓練作戰(zhàn)。但是，在新的作戰(zhàn)形式下并不適用于這種單機方式，并且文書的編輯工作對人員綜合素質(zhì)要求極高，工作量也會很大，如果是多人在同一計算機上編輯想定文書，則會大大降低工作效率。

②異步協(xié)同編輯[2]：解決了單機編輯的協(xié)同問題，能夠支持多人共同編輯想定文書，每位編輯人員在個人計算機上承擔各自的編輯任務，最后將編輯好的想定文書提交到集中服務器上，由服務器對總想定進行沖突檢測和匯總。異步協(xié)同的方式雖然達到了多人協(xié)同編輯的目的，但是編輯人員無法實時看到其他編輯人員編寫內(nèi)容的情況，如果有內(nèi)容沖突還需返還給編輯人員重新編輯，因此，這種方式適合于各軍種、各專業(yè)、各裝備之間耦合度不高的軍事想定。顯然，這是不符合現(xiàn)代化軍事作戰(zhàn)理念的。

③同步協(xié)同編輯：也是協(xié)同工作的一種方式，與異步協(xié)同相比，滿足了異步協(xié)同無法實現(xiàn)的需求，支持多方、多角色實時在線協(xié)同編輯，每位編輯人員所編寫的內(nèi)容會實時展現(xiàn)在其他所有共同編輯人員的計算機上，新打開文書的編輯人員也可以看到最新的實時編輯內(nèi)容，既滿足了多人共同編輯想定的需求，又實現(xiàn)了多方相互輔助、相互聯(lián)動進行實時編輯的情況，達到真正的軍事想定文書協(xié)同編輯的目的，本文采用這種方式實現(xiàn)了軍事想定的協(xié)同編輯。

2關鍵技術

2.1基于Java實現(xiàn)的B/S架構(gòu)

B/S架構(gòu)[3-4]是一種基于Web的網(wǎng)絡結(jié)構(gòu)模式，前端顯示界面為瀏覽器客戶端，后端為Web服務器，采取瀏覽器請求，服務器響應的工作模式，稱為3層C/S架構(gòu)。B/S架構(gòu)如圖1所示。

第1層為瀏覽器客戶端，用于向用戶展示界面，用戶可以通過操作瀏覽器界面進行交互。

第2層為Web服務器，接收瀏覽器客戶端發(fā)來的請求，并在本層進行業(yè)務邏輯處理，再和數(shù)據(jù)庫服務器進行數(shù)據(jù)交互，作為整個架構(gòu)的核心，起到一個承上啟下的作用。

第3層為數(shù)據(jù)庫服務器，存儲了整個服務的數(shù)據(jù)，是軟件的根基，接收Web服務器的請求，并將執(zhí)行完SQL后的結(jié)果返回給Web服務器。

使用B/S架構(gòu)有以下幾個優(yōu)點：

①免安裝、共享性強：在安裝部署時用戶無需每臺計算機都安裝客戶端軟件，只要有瀏覽器即可訪問，方便快捷。

②交互性強：通過Web服務器可以輕松實現(xiàn)多客戶端的同步更新和實時交互。

③可擴展性高、維護簡單方便：軟件更新時，無需升級客戶端，只需要升級服務器，就可以實現(xiàn)軟件更新。

由于想定協(xié)同編輯軟件涉及多軍種、多角色共同編輯想定文書，客戶端數(shù)量龐大，實時在線協(xié)同編輯對共享性、交互性要求高，因此使用B/S架構(gòu)實現(xiàn)更加合適，并且考慮到想定編輯軟件服務可能部署在Windows、Linux等不同系統(tǒng)平臺上，使用Java開發(fā)Web服務器可以實現(xiàn)與平臺無關，具有高可移植性。

2.2實時協(xié)同編輯服務

2.2.1工作原理

實時協(xié)同編輯服務，是整個軟件的核心，其工作原理如下：

①當某個想定文書通過瀏覽器被首次打開時，實時協(xié)同編輯服務（以下簡稱為服務端）會將該文書下載到服務端生成一個臨時副本，并與客戶端建立起一個長連接，用于將修改過的文書副本實時更新到客戶端上，然后將文書副本響應給瀏覽器。

②第二個編輯人員通過瀏覽器客戶端打開該想定文書，服務端與其建立長連接后將該文書副本響應給該瀏覽器客戶端。當有人編輯文書時，編輯后的文書會被與之前的副本進行比對，并將修改結(jié)果發(fā)送給服務端，服務端收到后更新文書副本，然后通過長連接將修改結(jié)果通知給其他正在編輯該文書的客戶端，其他客戶端收到后更新本地文書副本。

③當有2個以上客戶端同時編輯某一處內(nèi)容時，服務端通過操作轉(zhuǎn)換（Operational Transformation，OT）技術解決編輯沖突，避免產(chǎn)生數(shù)據(jù)不一致問題。

④在一個編輯人員退出編輯后，會與服務端斷開長連接，此時不會對文書副本進行保存。直到最后一個編輯人員退出對該文書的編輯，服務端會在10 s后將文書副本保存到本地磁盤或云服務器上，進行持久化。如果在這10 s期間有人再次打開編輯該文書，則取消保存操作。這樣實現(xiàn)是為了減少I/O操作，節(jié)省系統(tǒng)資源，降低開銷。

2.2.2操作轉(zhuǎn)換技術

OT是協(xié)同技術中用來保持不同的數(shù)據(jù)副本一致性的一種方法，在不同的終端，根據(jù)操作順序的不同，對操作進行調(diào)整，以保持數(shù)據(jù)一致性。協(xié)同編輯沖突問題示例如圖2所示。

用戶1往索引0處輸入" "，用戶2往索引3處輸入" "，由于存在網(wǎng)絡延遲，不同用戶的操作可能在各端有不同的執(zhí)行順序，從而產(chǎn)生了不同的結(jié)果。OT正是解決這個問題，操作轉(zhuǎn)換不是一個算法，而是對一類算法的統(tǒng)稱。解決的問題是：基于同一個狀態(tài)的2個操作，如何調(diào)整一個操作的參數(shù)，使得它可以在另一個操作之后執(zhí)行，表達同樣的用戶意圖。在引入操作轉(zhuǎn)換之后，就解決了協(xié)同編輯中數(shù)據(jù)一致性的問題。OT操作轉(zhuǎn)換示例如圖3所示，用戶的修改操作經(jīng)過一定算法的操作轉(zhuǎn)換之后，使得用戶1和用戶2最終的結(jié)果保持一致。

2.3分布式文件系統(tǒng)

如果默認情況下將文書存儲和應用服務器放在一起，在文書資源的不斷擴展下，代碼和靜態(tài)資源耦合在一起，使得管理混亂，并且文書訪問會占據(jù)一定的資源，影響應用服務的正常運行。因此引入獨立文書服務器，前端通過統(tǒng)一資源定位器（Uniform Resource Locator，URL）的形式訪問該服務器，獲取文書資源。但是，單機存在性能瓶頸，而且容災、垂直擴展性較差，分布式文件系統(tǒng)則解決了這些問題。分布式文件系統(tǒng)（Distributed File System，DFS）是指文件系統(tǒng)管理的物理存儲資源不一定直接連接在本地節(jié)點上，而是通過計算機網(wǎng)絡與節(jié)點相連[5-6]。文件存儲的位置和后端代碼不再耦合在一個服務器上，文件將單獨存儲在其他服務器上，消除了對應用服務器的資源競爭，分布式文件系統(tǒng)一般分為3個子系統(tǒng)，仲裁系統(tǒng)相當于文件服務器的大腦，根據(jù)一定的算法來決定文件存儲的位置，文件存儲系統(tǒng)負責保存文件，容災系統(tǒng)負責文件系統(tǒng)之間的相互備份。

3系統(tǒng)體系結(jié)構(gòu)

3.1系統(tǒng)軟件層次架構(gòu)

想定文書協(xié)同編輯系統(tǒng)采用了B/S架構(gòu)，文書數(shù)據(jù)存儲在分布式文件系統(tǒng)上，文書存儲的URL路徑持久化在關系型數(shù)據(jù)庫中，據(jù)此技術構(gòu)成和功能需求，將系統(tǒng)劃分為4個層次，包括展現(xiàn)層、業(yè)務邏輯層、數(shù)據(jù)訪問層和數(shù)據(jù)存儲層。系統(tǒng)軟件層次架構(gòu)如圖4所示。

（1）展現(xiàn)層

想定文書協(xié)同編輯系統(tǒng)的展示界面，通過瀏覽器的形式將操作頁面展示給用戶，編輯人員可以通過瀏覽器直接和展現(xiàn)層界面進行交互。

（2）業(yè)務邏輯層

業(yè)務邏輯層是整個系統(tǒng)功能實現(xiàn)的核心層，主要通過算法計算處理協(xié)同編輯系統(tǒng)的各個功能邏輯，其中包括想定文書沖突操作轉(zhuǎn)換、文書變動實時通知、文書存儲、文書副本拷貝、文書導入導出等。業(yè)務邏輯層將處理好的數(shù)據(jù)交給展現(xiàn)層。

（3）數(shù)據(jù)訪問層

數(shù)據(jù)訪問層是訪問數(shù)據(jù)存儲層的方式，業(yè)務邏輯層通過URL的方式訪問數(shù)據(jù)存儲層中文書系統(tǒng)的資源，通過HTTP請求的方式將文書資源存儲到分布式文件系統(tǒng)中，通過結(jié)構(gòu)化查詢語言（Structured Query Language，SQL）語句與數(shù)據(jù)存儲層中的關系型數(shù)據(jù)庫進行數(shù)據(jù)增、刪、改、查的操作。

（4）數(shù)據(jù)存儲層

數(shù)據(jù)存儲層有2種存儲方式：分布式文件系統(tǒng)用來存儲文書資源，通過URL來訪問；關系型數(shù)據(jù)庫則用來存儲文書的URL訪問路徑。

3.2系統(tǒng)總體結(jié)構(gòu)

系統(tǒng)的總體結(jié)構(gòu)主要分為4個組件：客戶端頁面、想定文書協(xié)同編輯應用服務器、分布式文件系統(tǒng)存儲服務器和關系型數(shù)據(jù)庫。系統(tǒng)總體結(jié)構(gòu)如圖5所示，描繪了整體結(jié)構(gòu)和各組件之間的關系。

客戶端頁面通過瀏覽器展示，各瀏覽器客戶端與想定文書協(xié)同編輯應用服務器建立長連接，完成實時協(xié)同編輯；當應用服務中沒有要編輯的文書副本時，先從關系型數(shù)據(jù)庫中查詢文書的URL路徑，然后根據(jù)URL路徑從分布式文件系統(tǒng)中拷貝文書副本。當最后一個用戶退出文書編輯頁面后，應用服務默認10 s后調(diào)用文書保存操作，將文書副本保存到文件存儲服務中，然后將返回的新URL存儲到數(shù)據(jù)庫中；用戶在瀏覽器可以通過URL直接訪問分布式文件系統(tǒng)中的資源，將想定文書下載到本地。

4結(jié)束語

本文提出的B/S架構(gòu)的想定文書協(xié)同編輯系統(tǒng)，滿足了共享性強、實時性強、可擴展性高、可移植性高的想定編輯新需求，順應現(xiàn)代化指揮作戰(zhàn)趨勢，真正地實現(xiàn)了想定文書實時在線協(xié)同編輯。目前，本系統(tǒng)已得到技術驗證并且投入到實際應用中去，為想定協(xié)同編輯的研究方法提供了新的思路。

參考文獻

[1]中國人民解放軍軍事科學院.中國人民解放軍軍語[M].北京：軍事科學出版社，2011.

[2]畢學軍，張揚，劉海寧，等.電子對抗仿真想定編輯的協(xié)同技術[J].兵工自動化，2012，31（8）：69-71，77.

[3]劉波.關于B/S和C/S架構(gòu)的分析[J].人民檢察，2004（9）： 77-78.

[4]王虎.基于B/S模式的信息管理平臺[D].天津：天津大學， 2018.

[5]王雪濤，劉偉杰.分布式文件系統(tǒng)[J].科技信息（學術研究）， 2006（11）：406-407.

[6]肖蓉.分布式文件系統(tǒng)負載均衡技術探討[J].電子世界，2020， 591 （9）：51-52.