基于Push—Model的遙感生態產品生產監控的設計與實現
2014-04-29 00:44:03喬保軍王玉璟徐勇
計算機時代 2014年3期
喬保軍 王玉璟 徐勇
摘 要： 針對生態環境遙感產品生產系統的架構，結合遙感生態產品的特點，提出了以多線程方式為運行機制的Push-Model的產品生產監控系統，用以實時、有效地對產品生產過程進行進度監控和人工交互消息的控制。生產監控系統的實現與運行，證實了該方案下產品生產監控信息的實時性及人工交互消息控制的有效性。
關鍵詞： Push-Model； 生態產品； 消息控制； 生產監控
中圖分類號：TP399 文獻標志碼：A 文章編號：1006-8228（2014）03-20-04
0 引言
近年來，衛星遙感應用作為我國太空經濟的重要組成部分，在解決我國經濟社會發展中的資源環境瓶頸問題、防災減災和生態建設方面，顯示出越來越重要的作用。為實現我國環境大范圍、全天候、全天時的動態監測，建立業務化的國家環境監測體系，滿足我國環境與災害監測預報小衛星星座的要求，國家環境保護部提出了環境與災害監測預報小衛星星座環境應用系統軟件工程。生態環境遙感產品生產系統是環境應用系統的主要組成部分之一。
在生態環境遙感產品生產系統中，監控系統作為其重要組成部分，不僅對生產過程進行進度監控，而且為人工交互消息的控制提供操作接口。監控消息的獲取模式有多種，其中Push模式有實時推送、無縫連接及安全性等多方面的特點[1]，并在WAP、Android、網絡數據分發等方面有優越的應用[2-8]。為了保證監控客戶端能實時地查看進度信息，在生產服務器端使用了Push模式來推送進度信息。本文結合遙感生態產品生產的實際需求，根據Push模式的特點，設計出的監控系統在實際應用過程中能很好地滿足項目需求。
1 遙感生態產品生產監控的系統模型
基于Push-Model的遙感生態產品生產監控系統的部署架構如圖1所示。
圖1 遙感生態產品生產監控系統部署架構圖
遙感生態產品生產系統由多臺生產服務器、調度服務器客戶端組成，監控系統作為其中的一個邏輯子系統貫穿于整個生態產品生產系統中。
生產服務器（ParaServer） 由于遙感生態產品數據多、數據所含的信息量大，系統處理遙感生態產品采用的算法仍為IDL（Interactive Data Language）語言所寫，生產服務器驅動遙感生態產品算法進行生產，在產品生產過程中，算法將執行過程的進度向生產服務器上報，生產服務器將進度組裝成進度消息推送給調度服務器。對需要人工交互的產品，生產服務器根據監控客戶端的操作來控制產品的生產過程及產品結果的質量。
調度服務器（DispatchServer） 調度服務器在監控系統中作為一個中間層部件存在，服務啟動后，開放端口循環監聽連接請求，同時該服務器維護生產服務器和監控客戶端兩個隊列。啟動生產服務器和監控客戶端后，調度服務器分別把其加入生產服務器隊列和監控客戶端隊列。生產服務器和監控客戶端有消息交互時，調度服務器負責該交互消息的轉發。
監控客戶端（MonitorClient） 監控客戶端為監控系統提供直觀的進度消息展示，并為人工交互控制生產過程提供界面操作接口，人工交互控制的選擇有制圖、簡報制作和歸檔三種類型。
在下文中我們用ParaServer代表生產服務器，DispatchServer代表調度服務器，MonitorClient代表監控客戶端。
2 遙感生態產品生產監控系統設計
從遙感生態產品的實際特點考慮，系統對非人工交互和人工交互兩類產品分別進行處理。這兩類產品的消息傳遞方式是一致的，不同的是人工交互產品需要人工通過MonitorClient對產品生產過程進行干預。
2.1 基于Push-Model的消息傳遞
ParaServer的算法驅動引擎驅動生態產品算法生產，產生進度值，最后把組裝的進度消息推送給DispatchServer，DispatchServer轉發給MonitorClient。由于MonitorClient在產品生產開始至結束這個時間段內，并不是一直在線（即連接在DispatchServer上），為了讓MonitorClient能準確連續地監控產品生產的進度，在ParaServer中添加了一個進度緩存器。ParaServer對新的進度消息Push之后，判斷當前的訂單是否完成生產，若已完成，則清空當前訂單的進度緩存；否則，把進度消息存入當前訂單的進度緩存中。
ParaServer中消息推送機制如圖2所示。
[算法驅動引擎][生態產品算
法生產產生
進度值][接收進度值][組裝成進度消息][Push] [ParaServer][當前訂單是
否生產完成] [Push之后] [是][清空][進度緩存][積累] [否] [轉發] [過程1][過程2] [DispatchServer] [接收消息，
解析展示][Send][MonitorClient]
圖2 ParaServer中消息推送機制
過程1表示MonitorClient在線時，ParaServer實時推送進度消息。
過程2表示MonitorClient在產品生產開始后至生產完成這個時間段內在線的前期進度消息獲取過程。為了MonitorClient得到完整的進度消息，進度緩存一次性地把歷史進度消息推送給MonitorClient，獲取歷史進度消息后，對新的進度消息，MonitorClient仍然遵從過程1的流程，即直接由ParaServer的算法驅動引擎Push進度消息。
2.2 利用隊列的人工交互消息控制
在人工交互消息控制過程中，當兩個以上的MonitorClient接收到同一個訂單的人工交互產品時，ParaServer采用的控制策略為先到先處理。ParaServer中維護了一個生產訂單狀態隊列，在與MonitorClient進行人工交互的過程中，根據人工交互消息調整狀態隊列中對應的訂單狀態。雖然人工交互的類型有多種，但是控制的流程是一致的。本例以制圖為例，來說明人工交互消息的控制流程。如圖3所示，消息a表示等待人工制圖消息，消息b表示該訂單正在人工制圖的消息，消息c表示開始人工制圖的消息，消息d表示制圖結束消息，為了突出ParaServer與MonitorClient的消息流通及控制過程，圖3中省略了DispatchServer轉發。
圖3 人工制圖消息的流程
人工制圖消息的流程說明：
第一步，ParaServer的生產過程中止，等待人工制圖，修改生產訂單狀態隊列中訂單的狀態；
第二步，通知MonitorClient，發送消息a；
第三步，MonitorClient接收并解析消息a，點擊MonitorClient界面中的【人工制圖】按鈕，向ParaServer發送消息c；
第四步，ParaServer接收并解析消息c，鎖定該訂單，修改訂單隊列中訂單狀態，向MonitorClient發送消息b；
第五步，MonitorClient接收并解析消息b，并從ParaServer中下載人工制圖需要的模板等文件；
第六步，在MonitorClient端，人工打開制圖模塊，開始人工制圖；
第七步，人工制圖操作結束，將制圖結果上傳到ParaServer中；
第八步，點擊MonitorClient界面中的【制圖完成】按鈕，向ParaServer發送消息d；
第九步，ParaServer接收并解析消息d，修改訂單隊列中訂單狀態，人工制圖流程結束。
在ParaServer中，人工制圖過程結束后，自動轉到下一個生產階段，因此人工制圖結束時不需要再向MonitorClient發送制圖結束的消息。
2.3 多線程方式的運行機制
多線程方式作為一種多任務、并發的工作方式，有快速的響應能力、使CPU系統更加有效及改善程序結構等特點，應用范圍廣[9-11]。本系統中需要對消息進行大量的接收、解析、轉發處理，ParaServer端驅動生態產品算法生產，并將生產的進度推送出去，同時還接收并解析來自MonitorClient的人工交互控制的消息，這三種操作都是并行的。DispatchServer接收ParaServer與MonitorClient的連接并轉發消息，這兩種操作也是并行的。MonitorClient端實時監控生產進度，并在界面上展示，同時控制人工交互操作，這些任務都是并行的。因此為了滿足系統對進度監控的實時性及人工交互消息控制的有效性要求，系統采用了多線程方式的運行機制。
這種多線程的運行機制貫穿于系統的整個運行過程，Paraserver中的多線程保證了Push-Model下進度能實時傳遞到DispatchServer，DispatchServer中的多線程方式又可靠地保證了轉發給當前的MonitorClient。
3 遙感生態產品生產監控系統實現
消息是ParaServer、DispatchServer及MonitorClient通信的基礎，本節先給出了系統中消息格式的約定，再分別介紹了消息傳遞和人工制圖消息的控制。
3.1 消息格式約定
本系統底層采用的通信協議是TCP/IP協議[12]。為了保證消息的正確解譯，在系統的消息流通中，ParaServer、DispatchServer和MonitorClient約定了消息的格式。以下列舉幾個重要的消息，并詳細解釋其含義。
3.1.1 MonitorClient給DispatchServer的消息
消息1 開始監控消息
格式：BeginMonitor@orderNum#ParaServerIP
BeginMonitor：消息頭，MonitorClient在啟動監控時向DispatchServer發送此消息；
orderNum：訂單號（數據庫中的orderID）-子訂單序號（數據庫中的subOrderID）；
ParaServerIP：這一項可以為空，在沒有值的情況下，表示查詢正在調度隊列中的ParaServer；如果有值，則表示到該值所在的ParaServer查詢生產進度信息。
消息2 制圖消息
格式：ManualMapping@orderNum#*#*
ManualMapping：消息頭，點擊MonitorClient中【制圖完成】時發送此消息；
orderNum：訂單號（數據庫中的orderID）-子訂單序號（數據庫中的subOrderID）；
*：有兩個取值，F或者E，F表示人工制圖完成，所需文件已經上傳；E表示人工制圖文件上傳失敗；
*：根據第一個*的值來確定，當前一個參數為F時，為空；當前一個參數為E時，為上傳失敗的制圖文件名。
消息3 人工制作簡報消息
格式：ManualMakeReport@orderNum#*#*
ManualMakeReport：消息頭，點擊MonitorClient中【簡報完成】時發生此消息；
orderNum：訂單號（數據庫中的orderID）-子訂單序號（數據庫中的subOrderID）；
*：有兩個取值，F或者E，F表示人工制作簡報完成，所需文件已經上傳；E表示人工制作簡報上傳失敗；
*：根據第一個*的值來確定，當前一個參數為F時，為空；當前一個參數為E時，為上傳失敗的簡報文件名。
3.1.2 DispatchServer給MonitorClient的消息
消息4 回復開始監控單個任務的消息
格式：ReBeginMonitorOneTask@OrderNum#
ParaServerIP#PSFtpPort#PSMsgPort#IsOK
ReBeginMonitorOneTask：消息頭，MonitorClient向DispatchServer發送BeginMonitorOneTask時發送消息；
OrderNum：訂單號（數據庫中的orderID）-子訂單序號（數據庫中的subOrderID）；
ParaServerIP：生產該訂單的ParaServer的IP地址；
PSFtpPort： ParaServer的Ftp端口號；
PSMsgPort： ParaServer的TCP通信連接端口號；
IsOK：取值True或False，True表示可以開始監控；False表示ParaServer不能正常反饋進度消息。
消息5 單個任務監控消息
格式：ReOneTaskInfoPS@ClientIP#
OrderNum#ProduceBeginOrEndTime#*#
Progress#OverallProgress#Time
ReOneTaskInfoPS：消息頭，有新進度時PUSH此消息；
OrderNum：訂單號（數據庫中的orderID）-子訂單序號（數據庫中的subOrderID）；
ClientIP：MonitorClient的IP地址；
ProduceBeginOrEndTime：當progress<100時，子階段生產開始的時間；當progress=100，子階段生產結束的時間；
*：表示在生產過程中執行的不同步驟的縮寫字母，取值為D時表示數據解壓，其他值有：V-數據驗證、C-數據準備、P-開始生產、X-渲染、Z-制圖、J-簡報制作、Y-元數據生成、G-歸檔、F-生產結束、U-產品上傳；
Progress：表示對應的每種情況的進度信息；
OverallProgress：任務總體進度；
Time：此子生產階段的用時。
3.2 消息傳遞的可視化
為了直觀地感知系統的消息過程，在MonitorClient端設計了一個系統消息的可視化區域。在此區域中，實時地詳細記錄系統在運行中傳遞的每一條消息。可視化界面如圖4所示。消息傳遞實現的思想如下。
ParaServer中自定義類StaticQueue.cs來表示新消息產生時，消息的流動去向。類中首先維護一個訂單狀態的隊列OrderStateList，其類型為由.Net類庫提供的多線程同時訪問的鍵值對的線程安全集合ConcurrentDictionary，參數類型為
圖4 進度消息的實時記錄
ParaServer中產生消息后處理的核心代碼由自定義的HelpTools類中NoticeAllClient方法實現。調用的核心源碼為：
if（OrderStateList.ContainsKey（orderID_subOrderID））
{ HelpTools.NoticeAllClient（orderID_subOrderID， msg）； //通知現
在所有正在監聽該訂單的客戶端
OrderStateList[orderID_subOrderID].Add（msg）；
}
3.3 人工制圖消息的控制
在ParaServer中，由自定義接口InterfaceCMD來表示所有消息處理的入口，再由實現該接口的自定義類CmdManualMappingPS處理該消息。由于不同的遙感生態產品生產過程不同，因此，在用MonitorClient監控時，界面上顯示的內容會有差異。為了最大限度地降低生產過程中意外消息的干擾，及加強消息控制的有效性，MonitorClient端采用漸進式的操作按鈕接口可用的設計。當生產過程進行到需要某一個人工交互的過程時，MonitorClient端只有與該過程相關的操作按鈕接口可用，這樣就避免了誤操作。
圖5 等待人工制圖
任務訂單L201110200002964-0009的產品生產過程執行到人工制圖這一步驟，如圖5所示，此時，只有【人工制圖】和【制圖完成】兩個跟制圖消息相關的操作按鈕可用。點擊右上方的工具欄中的【人工制圖】，即向ParaServer發送消息：
Mapping@L201110200002964-0009，表示該MonitorClient將處理此訂單的人工制圖過程；點擊【制圖完成】結束此次人工交互過程，向ParaServer發送消息：
ManualMapping@L201110200002964-0009#F#
系統中人工交互消息控制的原理同上。圖6展示的是歸檔的消息控制，訂單L201110200002964-0009生產完成后得到的一個xml形式的產品結果。若是產品需求人員對此結果滿意，則可以點擊工具欄的【歸檔】對結果進行保存；否則，可以點擊【放棄歸檔】，ParaServer將刪除對此次產品生產的所有生產結果。
圖6 產品xml結果展示
4 結束語
本文針對生態環境遙感產品生產系統的架構，對其產品生產監控提出了一種解決方案。提出了以ParaServer、DispatchServer和MonitorClient三種獨立運行部件為基礎的監控系統模型，實現了遙感生態產品生產系統中的監控功能。提出使用多線程運行機制與Push模式相結合的方式監控ParaServer的狀態，并通過對ParaServer中訂單狀態隊列的設計來解決人工交互消息的控制問題。
在后續完善過程中，我們將ParaServer與MonitorClient的消息通信部分單獨提取出來，封裝成獨立的模塊，以提高本系統監控Push-Model的復用性。本系統的消息格式約定多，在系統實現過程中，調試難度大。項目后期我們將在系統中加入日志功能，以解決調試難的問題。
參考文獻：
[1] 李慶誠，商盛立.手持閱讀終端電子資源Push系統設計與實現[J].計
算機工程與設計，2009.30（6）：1483-1487
[2] 姚華銀，潘雪增，平玲娣.WAP2.0PUSH代理網關的設計與實現[J].計
算機應用與軟件，2005.22（12）：82-84
[3] 鄒海，李強，邱慧麗.基于Android C2DM服務的云端推送研究與實現[J].
計算機技術與發展，2012.22（7）：29-32
[4] 陶孜謹，龔正虎，盧澤新.兩種新的push-pull平衡的大數據量無線傳
感器網絡數據分發算法[J].計算機研究與發展，2008.45（7）：1115-1125
[5] 曹海兵，夏英等.Push型LBS應用的實現技術研究[J].計算機應用研
究，2006.10：232-233
[6] 盧曉聰，范通讓，李英.WAP Push在電子政務系統中的應用[J].河北
省科學院學報，2011.28（2）：15-20
[7] Xian-He Sun，Surendra，Yong Chen.Server-Based Data Push
Architecture for Multi-Processor Environments[J]. Journal of Computer Science and Technology，2007.22（5）：641-652
[8] 劉軍霞，熊選東，付建丹.基于發布/訂閱的推模式服務調用[J].計算機
系統應用，2012.21（12）：196-199
[9] 劉權勝，楊洪斌，吳悅.同時多線程技術[J].計算機工程與設計，
2008.29（4）：963-967
[10] 吳建軍.多線程技術的Office對象模型閱卷系統[J].計算機系統應
用，2011.20（3）：18-22
[11] 蔣溢，黃進，王化晶.基于多線程技術的聊天系統研究[J].計算機工程
與設計，2008.29（15）：4064-4066
[12] 劉爽，史國友，張遠強.基于TCP/IP協議和多線程的通信軟件的設
計與實現[J].計算機工程與設計，2010.31（7）：1417-1420
