松耦合組件的通信模式研究

嚴 勇，趙長寬

（1.北京航天發射技術研究所，北京100076；2.東北大學 計算中心，遼寧 沈陽110819）

0 引 言

當前的計算機應用環境是由大型主機、工作站、微機和嵌入式設備等多種計算機硬件，各種各樣的軟件，通過網絡鏈接起來的復雜系統。軟件應用環境的復雜性，對軟件開發提出了更高的要求。軟件開發不僅需要滿足用戶的需求，還要充分考慮歷史軟件資源的重用，并實現與多種軟件的集成。例如在開發多學科設計優化系統中，必須考慮分布式計算、分布式組件和多種軟件集成等諸多問題。因此具有可重用、可配置、松耦合的等優秀特性的組件技術，在軟件開發中獲得的廣泛應用。在構建松耦合系統的系統中，如何解決組件通信問題非常重要。目前組件通信主要采用通知和消息隊列，其要求參與通信的消息發送者和接收者已知，且彼此存在。而在分布式計算環境下，參與計算的組件動態加入，并接受信息。在時間上，通信的雙方是異步的，消息發出者預先并不知道具體的消息接收者，并且消息之間可能存在一定的關聯。在異步通信模式下，還存在如何實現與即將加載的組件通訊；如何與擔任某種角色的組件通信等問題。另外，根據不同的計算任務定義，消息之間存在一定的關聯。如何處理關聯信息，也成為組件通信中的一個重要問題。由于現有的組件通信模式沒有完全解決上述問題，因此需要繼續深入研究。結合多學科設計優化系統研制需要，針對此問題提出一種新的組件通信模式，并從通信方法、組件注冊、消息隊列和關聯消息4個方面進行了說明，同時結合多學科設計優化系統研制開展了驗證工作。

1 相關研究

組件技術引入的最初動機是解決多語言、多廠商和跨平臺軟件設計，實現普適性的代碼重用。其出發點是實現軟件領域的集成電路 （IC），實現軟件的封裝和即插即用［1］。因此在基于組件技術開展的軟件設計中，一個基本的設計原則是緊內聚和松耦合，以實現組件的獨立性。

由于組件以松耦合方式存在，在空間上，可能屬于不同的計算機或進程；在時間上，可能是異步的。因此組件的通信成為一個重要的設計問題。為了解決基于組件的松耦合系統設計中的通信問題，已經出現了通知 （notifications）和消息隊列 （message queuing）等通信設計模式［2］。在目前的主流組件技術中，CORBA采用消息通知模式［3－4］，COM／DCOM采用消息隊列模式［5］，EJB采用的JMS也是一種消息隊列機制［6］。通知和消息隊列技術的前提是，消息發送者預先知道消息的接收者。而在分布式計算系統設計中，由于承擔計算任務的組件是動態加入的，其在接收以消息方式傳送的任務時，并不知道消息的發送者。

針對復雜軟件系統的解耦耦合問題，Patrick提出從空間、時間和同步過程3個維度進行分析。空間解耦是指消息傳遞的彼此不認知，發送消息與接收消息通過不同的服務實現，兩者一般不存在引用關系，并且接收者不知道消息的發出者。時間解耦是指發送者與接收者不需要同時活動。同步解耦是指消息發送過程和消息接收過程均是異步的。并將當前通行模式歸納為消息傳遞 （message passing）、遠程調用 （RPC）、通知 （notifications）、共享空間 （shared spaces）、消息隊列 （message queuing）和訂閱－發布 （publish／subscribe），并從空間、時間和同步過程3個維度進行分析，其結論是：消息傳遞在空間和時間上耦合的，只是在消息的發送過程中部分解耦；一般的遠程調用，在空間和時間上耦合，僅僅實現消息的發送過程中的部分同步解耦；異步遠程調用在空間和時間上耦合，實現了同步解耦；通知在空間和時間上耦合，實現同步解耦；共享空間實現了空間和時間解耦，并實現消息發送過程部分解耦；消息隊列實現了空間、時間的解耦，以及發消息發送過程部分解耦。只有訂閱－發布完全實現在空間、時間和同步解耦［7］。

在組件技術中，消息傳遞一般作為網絡通信的基礎，遠程調用和通知是組件通訊基礎，消息隊列是組件技術中的常用技術，訂閱－發布還未引入組件通信。基于耦合分析，CORBA的通知服務 （notification service）采用事件管道 （event channel）和消息隊列類似，因此本文重點分析消息隊列通訊模式。

基于消息隊列的通信模式下，消息發送者異步將消息填加到隊列，消息接收者從隊列中接收消息，消息接收過程僅僅依賴消息在隊列中順序，而不依賴于其它預先定義的結構。消息隊列一般采用FIFO （first－in first－out）隊列或優先級順序 （priority－based order）隊列。由于消息接收過程依賴于消息的順序，因此不能解決接收過程的同步解耦。

另外在消息隊列中，需要將全部組件注冊到消息處理器中，成為其監聽器，各組件往消息處理器中發不同的消息，由消息處理器來選擇相應的監聽器 （即組件）進行處理。并且此類消息通訊必須提前將組件注冊為監聽器，由組件本身從消息隊列中挑選要處理的消息［8］。這無法滿足與未加載組件通訊或組件間點對點通訊的要求。同時也無法解決關聯消息的處理。

2 動態組件通信模式

2.1 通信框架

針對組件通信的耦合問題，本文提出以消息中心為核心的通訊機制，其基本思想是：各個參與通訊的組件均在消息中心注冊，并通過消息中心實現消息的傳遞，如圖1所示。首先所有組件在消息中心建立賬號，即一種運行時唯一的ID，亦稱為通訊地址。通訊地址的編碼方案在2.2節詳細介紹。除此之外，組件還要指定功能角色，從而方便通過功能角色實現消息傳遞，同時也兼顧延遲加載組件的通信問題。

圖1 消息中心通訊

下面針對組件通信中的3種典型情景進行分析：

情景1：消息發出者和消息接收者均激活，并且消息發出者明確知道消息發送給那個接收者。

假設組件1需要與組件4傳遞消息，組件1知道組件4的通訊地址，具體的通訊過程如下：①組件1首先創建消息，將需要組件4處理的任務封裝在內；②組件1請求消息中心傳遞此消息；③消息中心根據消息提供的目的通訊地址，通過查詢注冊內容，并調用組件4的消息處理程序；④組件4處理消息，并將結果填充組件1傳遞的消息，并請求消息中心傳遞此消息；⑤組件1獲取消息，并查看處理結果。

情景2：消息發出者和消息接收者均激活，但是消息發出者僅僅知道將消息發送到那類功能角色的接收者。

假設組件1需要將消息發送到特定功能角色的組件，組件4是此類組件，具體的通訊過程如下：①組件1首先創建消息，將需要功能角色組件處理的任務封裝在內；②組件1請求消息中心傳遞此消息；③消息中心根據功能角色組件的注冊情況，查找相應的功能角色組件，并確定接收者通訊地址；④根據接收者通訊地址，通過查詢注冊內容，并調用組件4的消息處理程序；⑤組件4處理消息，并將結果填充組件1傳遞的消息，并請求消息中心傳遞此消息；⑥組件1獲取消息并查看處理結果。

情景3：消息發出者僅僅知道將消息發送到那類功能角色的接收者，并且此類功能角色組件不激活。

假設組件1需要將消息發送到特定功能角色的組件，組件4是此類組件，具體的通訊過程如下：①組件1首先創建消息，將需要功能角色組件處理的任務封裝在內；②組件1請求消息中心傳遞此消息；③消息中心根據功能角色組件的注冊情況，查找相應的功能角色組件，并確定接收者通訊地址，如果查到相應組件，進入步驟⑤，否則進入步驟④；④將消息存儲于消息隊列中，并執行步驟③；⑤根據接收者通訊地址，通過查詢注冊內容，并調用組件4的消息處理程序；⑥組件4處理消息，并將結果填充組件1傳遞的消息，并請求消息中心傳遞此消息；⑦組件1獲取消息，并查看處理結果。

由于消息中心所涉及的組件很多，組件可能激活，也可能不激活，所以提供點對點和消息隊列兩種方式實現通信。點對點方式則采用直接調用消息處理程序的方式進行。消息中心采用消息隊列的方式進行，即通過消息隊列來存放要處理的消息。

為了保證重要消息的及時傳遞，須在反復不斷地掃描消息隊列之外，優先處理級別較為重要的消息。需要采用消息隊列機制處理的消息包括廣播消息和駐留消息兩種。其中廣播消息主要用于向全體組件進行廣播，基本上用于表現組件自身的狀態或行為發生變化；駐留消息則為未加載的動態組件提供，通信過程如圖2所示。

圖2 3種消息通訊方式

在此通信模式下，消息傳遞通過消息中心傳遞，在空間上，消息發出者和接收者不存在參考關系。在時間上，消息發送過程是異步的，消息發出者不要接收者的確認。消息接收過程，消息接收不依賴于消息隊列順序，因此解決了消息隊列模式的存在的同步耦合問題。并且解決動態加載組件的通信問題。

2.2 組件注冊

組件注冊的目的是讓消息中心知道組件的存在，以便于實現消息通訊，注冊過程如下：①首先為組件指定功能角色名稱，一般情況下可以使用帶限定名稱的類名；②向消息中心申請相應的通訊地址，它可以是靜態的地址或運行時地址；③以當前的通訊地址為關鍵件注冊組件；④處理駐留消息；⑤處理廣播消息。

由于通訊地址是由數字組成并且唯一，故靜態地址在保證組件唯一性方面存在一定難度，主要原因在于外來的組件很難保證其通訊地址不與已有組件的沖突，如果采用UUID格式［9］，又有點浪費資源，同時也不利于操作。為此，采用運行時地址分配方案將有助于解決上述問題。

本方案將利用組件的功能角色名稱來生成通訊地址，基本思想是利用編碼技術，將變長度的字符串轉化成一個整數來表示，并要求變長度字符串滿足特定格式。字符串應該具備 “XXXXX.XXXXX.XXXXX……”類似格式，其中 “XXXXX”由小寫字母組成，實質為帶包名的類名稱。為了保證能用一個整數去表示全部的組件功能角色名稱，必須采用不對稱方式對待功能角色名稱中的各段名字，同時對段數也做相應限制。

根據對功能角色名稱的使用統計，各字段的不同頻率依次由小到大。如圖3所示，字段1通常為 “com”，字段2代表公司名，字段3～字段n－2代表按層級區分的模塊名稱，字段n－1代表具體的功能實現類名，最后一個字段n代表實例序數。現在要確定的就是每個字段不同個數的取值范圍是多少，這里要求其最大化，以便于容納更多的功能。為保證各字段數據不互相影響，這里采用進制進行處理，可選的常用進制為2、8、10、16等。這里采用10，主要考慮其容易理解。

圖3 通訊地址各字段含義

由于字段1只占用1位可以不用考慮，字段n指定占用10個位置，其它各字段都占用10m個位置 （這里m為整數，要求m至少為2）。現在來計算一下m和n的具體數值。參見下面的不定方程 （其中Imax表示最大整數）

在32位計算機上，最大的整數為Imax＝232，則由上述方程 （1）可得

代入n≥5到式 （2），可得：m≤2.8。由此可確定m＝2，再代入式 （2），可得：n≤6.3。

由此可知n＝5或6。為保證組件開發的靈活性，適當放寬字段數量，決定n＝6。最終的字段及其取值范圍，如圖4所示。

實際的編碼過程是按組件提供的功能角色名稱以 “.”區分，建立編碼樹，如圖5所示。假設由兩個公司開發出7個功能插件位于7個模塊中。那么，類 “ClassName3”的第1個實例編碼為 “1010202031”，類 “ClassName7”的第3個實例編碼為 “1020405073”等。組件注冊信息的存儲通過映射表實現，并以組件的通訊地址作為鍵值。

圖4 實際通訊地址各字段含義和其取值范圍

圖5 通訊地址應用舉例

2.3 消息隊列

消息的處理是通過 “消息中心”將要處理的消息調度到 “消息中心”隊列中，然后由消息處理引擎 （參見圖2）按照一定的規則依次處理隊列中消息。可選用的規則包括3種：①先進先出 （FIFO）；②先進后出 （FILO）；③按組件優先級處理等。方式①和方式②對于那些執行效率要求不高的或有某些特殊要求的場合，是一種較為簡單的調度方式；方式③是現在大多數應用所采用的任務調度方式，它又分為兩種：靜態優先級和動態優先級，這種方式將消息分為不同的級別，優先級高的消息先得到執行。本文采用動態優先級。

現在評估一下在動態優先級的執行隊列中，一個組件最大調度時間是多少？先假設隊列的長度 （容納消息的最大個數）為L，消息的優先級數為R，一個消息被每被掃描N次，其級別便會自動上升一級直到最大，消息處理引擎每次將會處理隊列中的全部最高級消息，消息處理引擎每個t0時間便會開始執行隊列處理，那么一個消息最大調度時間T計算如下

然而在實際過程中，我們要研究通常級別的消息在隊列中處理的時間。一般情況下，我們假定不同組件其級別分布服從正態分布，參見圖6。在圖中，曲線下的面積便是隊列緩沖區大小，優先級從左到右由高變低。

圖6 組件優先級分布

再過Δt時間后，圖6中的曲線便會向做移動，移出部分可以認為是已經調度處理的消息，那么我們假定還會新進一定數量消息，它們級別服從正態分布。參見圖7，實線的曲線向右移動了一段距離，移出部分由虛線所代表的新進消息代替，此時，要考察的消息也會由I移到II，此時我們考察的消息前邊還有s1＋s2面積所代表的消息數量。那么，我們要計算的是，何時II能移動到與y軸重合，所花去的時間就是我們要考察消息排隊等待的時間。

為了能夠計算這個時間，我們有兩種不同的方式去執行隊列，一種就是上面提到的消息處理引擎全部執行隊列中最高級別的組件，另一種就是每次只執行其中一定數量的組件，也是按級別由高到低進行處理。對于第一種方式來說，我們要考察消息排隊等待的時間 （τ）為

圖7 經過Δt時間后隊列中組件級別分布情況

式中：R——消息級別總數；N——消息級別進級掃描次數；t0——消息處理引擎執行時間間隔。

假定N＝1，參見圖8，在t時刻隊列中的優先級分布情況為Ft（x），豎虛線代表Δt時間后，隊列優先級升級后的情況，以及新進隊列組件優先級分布情況為gΔt（x），由此可以列出方程式 （5）

式中：n——表示每次消息處理引擎處理的消息數量；t0——表示消息處理引擎每次調度時間間隔。

圖8 等待時間計算模型

從式 （5）中可以看出，Δx是Δt的函數，Δt小于或等于t0。排隊等待τ可以由方程 （6）獲得，此方程是一個非常復雜的方程組，可以通過差分方法近似求得。由于不是本文的重點內容，求解方法簡述如下：先根據消息優先級統計數據求得μ和σ，取Δt為t0，通過式 （5）計算出g和F來，在通過式 （5）的變參數積分方程獲得Δx，由此我們可以通過一系列的Δt求得Δx1、Δx2、…、Δxm，再按式（7）獲得差值，當出現由負號變成正號時的m值，我們可以通過τ＝mt0求得消息排隊時間

2.4 關聯消息

在松耦合情況下，一個比較難處理的問題就是組件之間任務如何關聯［10］。例如：當一個組件需要另外一個組件提供運行結果，但是它并不能明確確定該組件何時能提供。針對這種情況下，本文采用解決方案是在發送的消息上提供關聯信息，即建立關聯消息對。如圖9所示，在消息中設定一個指針，指向下一個相關聯的消息。并在消息處理中心對消息隊進行處理，以保證關聯消息的正確。并在消息上設置同步鎖，實現兩個消息關聯。

圖9 關聯消息對

3 實驗與結果分析

結合發射平臺數字化設計系統項目建設需要，基于RCP（rich client platform）技術構建了多學科設計優化系統，并對本文提出的方法進行驗證。

在當前的復雜產品設計中，由于越來越多的產品要求其功能緊密集成，這就促使在產品的研發階段必須要求各專業緊密協作、相互配合，在單一學科專業的優化設計的基礎上，實現整體的多學科設計優化。多學科設計優化設計實現復雜系統的整體最優，同時兼顧各個子系統之間的約束和耦合關系［11］。多學科設計優化設計系統是按照多學科設計優化思想開發的分布式計算軟件平臺系統［12］。由于在多學科設計優化系統設計中，必然涉及與來自不同學科專業領域的多種設計、分析和仿真軟件的信息集成［13］。為了實現系統的開放性，基于組件技術實現多種軟件的封裝，并基于松耦合方式實現系統設計，是系統設計的基本方法［14］。其基本思路是將不同的計算軟件封裝成不同的計算組件，將設計任務賦予具體的組件實例，通過流程將不同的組件實例按照設計過程要求，組成求解流程，通過多學科優化求解實現分布式計算和全局尋優。

3.1 實驗結果

本系統設計實現的多學科優化設計系統組成如圖10所示，將NX、ProE Ansys、Adams等典型專業設計分析軟件封裝成分析組件，通過可視化流程將組件實例的組裝實現特定設計過程，通過多學科優化設計求解器實現迭代計算尋優，通過消息中心實現組件消息傳遞。系統可視化流程模塊基于Eclipse RCP［15］技術構建，系統技術架構如圖11所示。

消息中心部分，消息中心的主要類圖結構，如圖12所示，核心部分由MessageTransfer、MessageRequest、Cons trainRequestPair這3個類構成，其中MessageTransfer實現消息中心，MessageRequest實現消息的封裝，Constrain－RequestPair負責關聯消息。

圖10 多學科優化系統組成

3.2 實驗分析

圖13所示流程描述基于Pro／E的懸臂梁結構優化問題，優化設計目標是滿足結構強度要求條件下，質量最小。其中強度結算部分由ANSYS組件完成，優化求解由約束求解器組件完成，約束條件由腳本組件實現，結果輸出由圖形顯示組件實現。整個流程9個組件實例構成。上述組件的消息通信通過消息中心完成。在生產環境中，ANSYS一般部署專門的計算服務器，因此ANSYS組件的生存狀態取決于服務運行情況。通過消息中心機制，保證當服務器可用時，即可接收從 “寫出”組件或 “約束優化”等上游組件發送的消息任務，并將運算結果傳回。

圖13 多學科設計優化系統主界面

4 結束語

本文針對基于組件的松耦合系統設計中的組件通訊問題，提出一種新的以 “消息中心”為核心的組件消息通信模式。此通信模式解決了組件通信的中同步耦合問題。并對組件通訊地址編碼問題進行討論，在提出了基于功能角色的組件編碼技術。同時研究了消息隊列的排列問題，給出具有動態優先級的執行隊列的最大調度時間計算公式。最后結合航天科技集團信息化 “示范工程”中的子項目“發射平臺數字化設計系統”設計實踐，開展相關的驗證工作。實踐表明此技術是可行，并已應用于 “發射平臺數字化設計系統”中。

［1］ZHOU Zhiying.Modern software engineering：New technoloy volume［M］.Beijing：Science Press，2000：116－123 （in Chinese）.［周之英.現代軟件工程 （下）：新技術篇 ［M］.北京：科學出版社，2000：116－123.］

［2］SUN Changlin，Rajeev R.Compositional reasoning of performance in component－based distributed systems ［J］.Cluster Comput，2008，11 （4）：331－340.

［3］LU Hui－Chieh，CHU Yen－Ping.A generic application sharing architecture based on message－oriented middleware platform［J］.Computer Standards ＆ Interfaces，2008，30 （3）：191－199.

［4］Object Management Group，Notification service specification V 1.1 ［EB／OL］.http：／／www.omg.org／technology ／documents／corbaservices＿spec＿catalog.htm，2011.

［5］Message queuing architecture ［EB／OL］.http：／／technet.microsoft.com／zh－cn／library／cc754897（WS.10）.aspx，2011.

［6］Java message service specification－version 1.1 ［EB／OL］.http：／／www.oracle.com／technetwork／java／docs－136352.html，2011.

［7］Patrick Th Eugster，Pascal A Felber.The many faces of publish／subscribe ［J］.ACM Computing Surveys，2003，35 （2）：114－131.

［8］Silvestre B，Rossetto S.Flexibility andcoordinationineventbased，loosely coupled distributed systems ［J］.Computer Languages，Systems ＆Structures，2010，36 （2）：42－157.

［9］UUID structure ［EB／OL］.http：／／msdn.microsoft.com／enus／library／aa379358（v＝vs.85）.aspx，2011.

［10］LIU Yan，Ian Gorton.The architecture of an event correlation service for adaptive middleware－based applications ［J］.Journal of Systems and Software，2008，81 （12）：2134－2145.

［11］MA Mingxu，WANG Chengen.Multidisciplinary design optimization for complex product review ［J］.Chinese Journal of Mechanical Engineering，2008，44 （6）：15－26 （in Chinese）.［馬明旭，王成恩.復雜產品多學科設計優化技術 ［J］.機械工程學報，2008，44 （6）：15－26.］

［12］TANG Xiao－an，LI Guo－zheng.Research on integrated missile optimized design environment with configurable function［J］.Journal of System Simulation，2009，21 （7）：1933－1937（in Chinese）.［湯曉安，李國正.支持功能重配的導彈集成優化設計平臺研究 ［J］.系統仿真學報，2009，21（7）：1933－1937.］

［13］WANG Cheng－en，LIU Zhen.Integration technologies for design of aero－gas turbine ［J］.Journal of Northeastern University （Natural Science），2006，27 （5）：485－488 （in Chinese）.［王成恩，劉震.航空發動機渦輪設計集成技術 ［J］.東北大學學報，2006，27 （5）：485－488.］

［14］Heiko Koziolek.Performance evaluation of component－based software systems：A survey ［J］.Performance Evaluation，2010，67 （8）：634－658.

［15］Rich client platform （RCP）applications ［EB／OL］.http：／／www.eclipse.org／community／rcp.php，2011.