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

嚴(yán) 勇，趙長寬

（1.北京航天發(fā)射技術(shù)研究所，北京100076；2.東北大學(xué) 計算中心，遼寧 沈陽110819）

0 引 言

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

1 相關(guān)研究

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

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

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

在組件技術(shù)中，消息傳遞一般作為網(wǎng)絡(luò)通信的基礎(chǔ)，遠(yuǎn)程調(diào)用和通知是組件通訊基礎(chǔ)，消息隊列是組件技術(shù)中的常用技術(shù)，訂閱－發(fā)布還未引入組件通信?；隈詈戏治?，CORBA的通知服務(wù) （notification service）采用事件管道 （event channel）和消息隊列類似，因此本文重點分析消息隊列通訊模式。

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

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

2 動態(tài)組件通信模式

2.1 通信框架

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

圖1 消息中心通訊

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

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

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

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

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

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

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

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

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

圖2 3種消息通訊方式

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

2.2 組件注冊

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

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

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

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

圖3 通訊地址各字段含義

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

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

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

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

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

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

圖5 通訊地址應(yīng)用舉例

2.3 消息隊列

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

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

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

圖6 組件優(yōu)先級分布

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

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

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

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

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

式中：n——表示每次消息處理引擎處理的消息數(shù)量；t0——表示消息處理引擎每次調(diào)度時間間隔。

圖8 等待時間計算模型

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

2.4 關(guān)聯(lián)消息

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

圖9 關(guān)聯(lián)消息對

3 實驗與結(jié)果分析

結(jié)合發(fā)射平臺數(shù)字化設(shè)計系統(tǒng)項目建設(shè)需要，基于RCP（rich client platform）技術(shù)構(gòu)建了多學(xué)科設(shè)計優(yōu)化系統(tǒng)，并對本文提出的方法進行驗證。

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

3.1 實驗結(jié)果

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

消息中心部分，消息中心的主要類圖結(jié)構(gòu)，如圖12所示，核心部分由MessageTransfer、MessageRequest、Cons trainRequestPair這3個類構(gòu)成，其中MessageTransfer實現(xiàn)消息中心，MessageRequest實現(xiàn)消息的封裝，Constrain－RequestPair負(fù)責(zé)關(guān)聯(lián)消息。

圖10 多學(xué)科優(yōu)化系統(tǒng)組成

3.2 實驗分析

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

圖13 多學(xué)科設(shè)計優(yōu)化系統(tǒng)主界面

4 結(jié)束語

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

［1］ZHOU Zhiying.Modern software engineering：New technoloy volume［M］.Beijing：Science Press，2000：116－123 （in Chinese）.［周之英.現(xiàn)代軟件工程 （下）：新技術(shù)篇 ［M］.北京：科學(xué)出版社，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）.［馬明旭，王成恩.復(fù)雜產(chǎn)品多學(xué)科設(shè)計優(yōu)化技術(shù) ［J］.機械工程學(xué)報，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）.［湯曉安，李國正.支持功能重配的導(dǎo)彈集成優(yōu)化設(shè)計平臺研究 ［J］.系統(tǒng)仿真學(xué)報，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）.［王成恩，劉震.航空發(fā)動機渦輪設(shè)計集成技術(shù) ［J］.東北大學(xué)學(xué)報，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.