場景：
在一個集成環境中存在不同應用，這些應用的提供者不同且這些應用運行在各種各樣的平台上。其中的一些
應用程序生產消息，其他很多應用程序消費這些消息。
例如，某金融方面應用程序集成了貿易工具、投資管理應用、模型和風險分析工具、貿易指示以及自動收報機。
市場活動導致系統的交換。例如，一個貿易系統通過發送消息到其他貿易應用程序來實現賣出事務的操作。貿易
系統各自連接每一個貿易應用程序。在應用程序較少的時候這些操作能夠執行，但是隨着應用程序數量的增加，
系統負擔將越來越重。而實際上，增加或刪除貿易程序不應該影響貿易的處理過程。
問題：
隨着集成環境越來越復雜，如何才能降低添加或刪除應用所帶來的開銷？
約束：
添加一個應用程序到集成環境或刪除集成環境中的一個應用需要平衡下列約束：
1. 應用程序間的通信通常需創建程序間的依賴，發送端必須能與接收端通信，接收端必須能識別從所有發送
端發來的消息。這些依賴轉化成不同應用間的耦合。
2. 當采用點對點的方式來連接時，耦合數隨着應用程序的增加呈平方增長。例如，三個已連接的應用程序
需要三個連接，但是10個應用程序需要45個連接。而連接數越來越多，維護管理、修改和集成的難度越來越大。
3. 通常，應用程序集成解決方案有不同接口。修改應用程序的接口難度是很大的，即使能改變一個應用程序
的接口，改變所有應用的接口幾乎是不可能的。
4. 一些集成解決方案由一組固定的程序組成。一個集成解決方案很難擴展或修改需求，當他不需要適應新
應用時。
解決方案：
通過一個邏輯組件，即消息總線來完成所有應用程序的連接，一個消息總線明確消息傳遞的發送方和接
收方。一個消息總線包含三個關鍵的元素：
1. 一組達成一致的消息計划。
2. 一組公共命令消息。
3. 共享通信基礎框架來發送總線消息到接收端。
使用消息總線時，應用程序發送消息不再單獨連接其他應用程序，只需要將消息發布到消息總線上，消息總線將
消息發送到所有其他監聽總線上消息的應用上。同樣，應用程序不再直接接收來自其他發送者的消息，而是從
消息總線上獲取消息。實際上，消息總線減少了每個應用輸出端的數量，由多個減少到一個。
通常，總線不保證消息秩序。內部的優化、路由選擇、緩沖等甚至優先傳輸機制可能影響消息具體傳遞到
接收端的方式。因此，消息到達的順序是不確定的。例如，發送端能夠插入有序的數據到消息中，然后接收端
可以使用這些數據並進行重排，邏輯順序可以由總線提供，且邏輯順序對於應用程序可以是透明的。然而，
這種附加的邏輯不是必須的。
下圖一描述了一個集成環境下使用消息總線的形式。通過總線發送消息的應用程序必須准備好消息，以便消息符合總線期望的消息類型。類似的，應用程序接收消息時必須能夠理解消息類型。如果集成環境中所有的應用程序都實現
了總線接口，增加或移除應用程序對總線沒有影響。
消息總線與應用程序間共享的基礎通信框架可以使用消息路由來實現，而消息路由可以使用訂閱發布機制來實現。
如下圖，展示了消息總線與訂閱發布模式的關系。
期待將某一特殊的消息總線運用在訂閱發布的實現中，對消息總線架構產生了深遠的影響。實現訂閱發布模式
包含三類方式：http://www.cnblogs.com/svenzhang9527/p/7351769.html
消息總線與基於鏈表的訂閱發布模式
Message Bus with List-Based Publish/Subscribe
基於鏈表的訂閱發布模式本質包含兩點，一是維護包含發布主題和訂閱者信息的鏈表，二是當事件發生時，通知
該鏈表中的元素處理事件信息。
為了使用包含基於鏈表的訂閱發布機制的消息總線，當系統發送命令消息到消息總線時，消息總線檢查所有感
興趣的消息總線訂閱方，並給每個消息總線發送一個原始消息的拷貝。任何同消息有關的數據都使用通用格式，以便
所有系統都能理解命令和數據，並給出合理回復。
消息總線與基於廣播的訂閱發布模式
Message Bus with Broadcast-Based Publish/Subscribe