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