http://docs.oracle.com/cd/E19148-01/820-0533/aeraq/index.html

由于業務、機構和技術是不斷變化的，因此為其服務的軟件系統必須適應這樣的變化。在合并、添加服務或擴展可用服務之后，公司可能無力負擔重新創建信息系統所需的成本。正是在這個關鍵時刻，才需要集成新組件或者盡可能高效地擴展現有組件。要集成異類組件，最方便的方法不是將它們重新創建為同類元素，而是提供一個允許它們進行通信（不考慮它們之間的差異）的層。該層被稱作中間件，它允許獨立開發且運行于不同網絡平臺上的軟件組件（應用程序、Enterprise Java Bean、Servlet 和其他組件）彼此交互。當能夠進行這樣的交互時，網絡才成為計算機。

如圖 1–1?所示，在概念上，中間件位于應用程序層與平臺層（操作系統和底層網絡服務）之間。

圖 1–1 中間件

分布于不同網絡節點上的應用程序使用應用程序接口進行通信，而不必關心托管其他應用程序的操作環境的細節，也不必關心將它們連接到這些應用程序的服務。此外，通過提供管理接口，可以使這個新的互連應用程序虛擬系統安全可靠。可以對性能進行度量和調整，也可以在不丟失任何功能的情況下進行擴展。

中間件可以劃分為以下幾類：

• 基于遠程過程調用 (Remote Procedure Call, RPC) 的中間件，允許一個應用程序中的過程調用遠程應用程序中的過程，就好像它們是本地調用一樣。該中間件實現一個查找遠程過程的鏈接機制并使調用方能夠以透明方式使用這些過程。以前，這種類型的中間件處理基于過程的程序；現在，它還包括基于對象的組件。

• 基于對象請求代理 (Object Request Broker, ORB) 的中間件，使應用程序的對象能夠在異類網絡之間分布和共享。

• 面向消息的中間件或基于 MOM 的中間件，使分布式應用程序可以通過發送和接收消息來進行通信和交換數據。

所有這些模型都使一個軟件組件可以通過網絡影響另一個組件的行為。它們的區別在于基于 RPC 和 ORB 的中間件會創建緊密耦合組件系統，而基于 MOM 的系統允許組件進行更松散的耦合。在基于 RPC 或 ORB 的系統中，一個過程調用另一個過程時，必須等待調用的過程返回才能執行其他操作。正如前面所提到的，在這些模型中，中間件在一定程度上充當超級鏈接程序，在網絡上查找被調用過程，并使用網絡服務將函數或方法參數傳遞到被調用過程，然后返回查找結果。

基于 MOM 的系統允許通過異步交換消息來進行通信，如圖 1–2?所示。

圖 1–2 基于 MOM 的系統

面向消息的中間件使用消息傳送提供者來協調消息傳送操作。MOM 系統的基本元素是客戶端、消息和 MOM 提供者，后者包括 API 和管理工具。MOM 提供者使用不同的體系結構路由和傳送消息：它可以使用集中式消息服務器，也可以將路由和傳送功能分布在每個客戶端上。某些 MOM 產品結合了這兩個方法。

使用 MOM 系統，客戶端可以進行 API 調用，以便將消息發送到由提供者管理的目的地。該調用會調用提供者服務以路由和傳送消息。在發送消息之后，客戶端會繼續執行其他工作，并確信在接收方客戶端檢索該消息之前，提供者一直保留該消息。基于消息的模型與提供者的協調耦合在一起，使得創建松散耦合的組件系統成為可能。這樣的系統可以繼續可靠地工作，即使在有個別組件或連接失敗時也不會停機。

由消息傳送提供者協調客戶端之間的消息傳送的另一個優點是：通過添加管理界面，可以監視和調整性能。這樣，客戶端應用程序便不必關心發送、接收和處理消息之外的任何問題。對于互操作性、可靠性、安全性、可伸縮性和性能之類的問題，應當由管理員通過編碼實現 MOM 系統來解決。

至此，我們已經介紹了使用面向消息的中間件連接分布式組件的很多優點。下面將介紹其缺點。缺點之一源自松散耦合本身。在 RPC 系統中，只有在被調用函數完成任務之后，才能返回調用函數。在異步系統中，調用方客戶端會繼續為接收方裝入工作，直到處理裝入工作所需的資源耗盡且被調用組件發生故障。當然，可以通過監視性能和調整消息流來盡量減少或避免這些情況，但對于 RPC 系統卻不必這樣做。有一點很重要，那就是了解每種系統的優缺點。每種系統所適合執行的任務都不同。有時，您需要結合兩種系統才能完全獲得所需的行為。

圖 1–3?顯示 MOM 系統如何使兩個基于 RPC 的系統進行通信。該圖的左側顯示在不同的網絡節點上分布客戶端、服務器和數據存儲庫組件以提高性能的應用程序。這是一個折扣機票預定系統：最終用戶為使用此服務支付一定的費用，使用該服務可以找到特定目的地和時間的最低費用。數據存儲庫保存有關注冊用戶和參與此折扣計劃的航空公司的信息。服務器上的邏輯功能根據用戶的請求在所參與的航空公司中查詢價格、對信息進行排序并向用戶提供三個最低報價。該圖的右側展示了基于 RPC 的系統，表示所參與的任一航空公司的機票/預定系統。該圖的右側將為折扣系統所連接到的任意多個航空公司進行復制。對于每個這樣的航空公司，數據存儲庫都將保存有關可用航班的信息（座位、飛行時間和價格）。服務器組件將更新這些信息以響應最終用戶輸入的數據。航空公司的服務器還訂閱 MOM 服務，接收折扣預定系統的信息請求，并返回座位和價格信息。如果用戶決定購買 PanWorld 航空公司的折扣機票，則該系統的服務器組件將更新數據存儲庫中的信息，然后為請求者生成機票或者向折扣服務發送一條消息以生成機票。

圖 1–3 結合 RPC 和 MOM 系統

此示例說明 RPC 和 MOM 系統之間的一些區別。前面已經提到了其中一個區別就是分布式組件耦合的方式。另一個區別是，RPC 系統通常用于分布和連接客戶端與服務器組件（在這些組件中，客戶端通常是最終用戶），而在 MOM 系統中，客戶端通常是只能通過消息傳送進行交互操作的異構軟件組件。

MOM 系統較為嚴重的問題是 MOM 作為專用產品來實現。如果您的公司依賴于 SuperMOM-X，但最近收購了一家使用 SuperMOM-Y 的公司，會出現什么情況？要解決此問題，需要一個標準的消息傳送接口。如果 SuperMOM-X 和 SuperMOM-Y 均實現了此接口，則針對一個系統開發的應用程序也可以運行在另一個系統上。這樣的接口應該易于學習，同時提供足夠的功能來支持復雜的消息傳送應用程序。1998 年推出的 Java 消息服務 (Java Message Service, JMS) 規范就是為了實現這樣的目的。下一節將介紹 JMS 的基本功能，并說明包含現有專用 MOM 產品的通用元素的標準是如何制訂的。這些標準既允許差異存在，又使得進一步發展成為可能。

http://blog.csdn.net/freezgw1985/article/details/5771956

總結

以上是生活随笔為你收集整理的面向消息的中间件 (Message-Oriented Middleware, MOM)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。