1、概述
異構集成（heterogeneous integration）是消息傳送機制在其中起關鍵作用的一個領域。無論它的成因是合併、併購、業務需求，或者僅僅是技術方向上的一個變化，越來越多的公司都正面臨着在企業內部、跨企業集成異構系統和應用程序的問題。
消息傳送機制還具有異步處理請求的能力，它爲系統體系機構師和開發者提供的解決方案，能夠減輕或消除系統瓶頸，並提高最終用戶的生產率和系統的整體可伸縮性。由於消息傳送機制能夠實現組件之間的高度去耦，因此，使用這種機制的系統還具有高度的體系結構靈活性和敏捷性。
通過使用面向消息的中間件，消息通過網絡從一個應用程序傳送到另一個應用程序之中。企業中間件產品能夠確保消息在應用程序中間的正確分發。此外，對於那些需要可靠地大量交換消息的企業，這些產品通常爲它們提供了容錯和負載均衡、可伸縮性和事務性的支持。
2、消息傳送模型
MS支持兩類消息傳送模型：點對點模型和發佈/訂閱模型。有稱這些消息傳送模型爲消息傳送域。點對點消息傳送模型和發佈/訂閱消息傳送模型經常分別縮寫p2p和Pub/Sub。
發佈/訂閱模型設計用於一對多（one-to-many）消息廣播，而點對點模型則設計用於一對一（one-to-one）消息傳送。如下圖
2.1、點對點模型
點對點消息傳送模型允許JMS客戶端通過隊列（queue）這個虛擬通道來同步和異步發送、接受消息。在點對點模型中，消息生產者稱爲發送者（Sender），而消息消費 者則稱爲接受者（receiver）。點對點消息傳送模型的一個突出特點就是：發送到隊列的消息被一個而且僅僅一個接受者所接受，即使可能由多個接受者在同一個隊列中偵聽統一消息是，也是如此。
點對點消息傳送模型即支持異步“即發即棄（fire and forget）”消息傳送方式，又支持同步請求/應答消息傳送方式。點對點消息傳送模型比發佈/訂閱型具有更強的耦合性，發送者通常會知道消息將被如何使用，而且也會知道誰將接受該消息。
點對點模型支持負載均衡，它允許多個接受者偵聽同一隊列，並以此來分配負載。如圖1-4所示，JMS提供者者負責管理隊列，確保每條消息被組內下一個可用的接受者消費以此，而且僅僅一次。
2.2、發佈/訂閱模型
在發佈/訂閱模型中，消息會被髮布到一個名爲主題的虛擬通道中。消息生產者稱爲發佈者（publisher），而消息消費者稱爲訂閱者（subscriber）。與點對點模型不同，使用發佈/訂閱模型發佈到一個主題的消息，能夠由多個訂閱者所接受。有時候，也稱這項技術爲廣播（broadcasting）消息。每個訂閱者都會接受到每條消息的一個副本。總地來說，發佈/訂閱消息傳送模型基本上是一個基於（push）的模型，其中消息自動地消息者廣播，他們無須請求或輪詢主題來獲得新消息。
發佈/訂閱模型的去耦能力要比p2p模型更強，消息發佈者通常不會意識到有多少個訂閱者或那些訂閱者如何處理這些消息。
在發佈/訂閱消息傳送模型內部，有多種不同類型的訂閱者。非持久訂閱者是臨時訂閱類型，它們只是在主動偵聽主題時才接受消息。而另一方面，持久訂閱者將接受到發佈的每條消息的一個副本，即便在發佈消息，它們處於“離線”狀態時也是如此。
3、JMS API
JMS自身並不是一種消息傳送系統；它是消息傳送客戶端和消息傳送系統通信是所需接口和類的一個抽象。與JDBC抽象訪問數據庫、JNDI抽象訪問命名和目錄服務的方式一樣，JMS抽象可以訪問消息提供者。使用JMS，應用程序的消息傳送客戶端可以實現跨消息服務器產品的移植。
JMS API可以分爲3個主要部分：公共API、點對點API和發佈/訂閱API。在JMS1.1中，公共API可被用於向一個隊列或一個主題發佈消息，或從其中接受消息。點對點API專門用於使用隊列的消息傳送，而發佈/訂閱API則專門用於使用主題的消息傳送。
在JMS功能API內部，和發佈和接受JMS消息有關的JMS API接口主要有7個：
- ConnectionFactory
- Destination
- Connection
- Session
- Message
- MessageProducer
- MessageConsumer
在這些公共的接口中，ConnectionFactory和Destination必須使用JNDI從提供者處獲得。其他接口則可以通過工廠方法在不同的API接口中創建。這7個主要的JMS公共API接口之間的關係如下圖：
3.1、點對點 API
點對點消息傳送模型API特指JMS API之內基於隊列的接口。下面是用於向一個隊列發送和從一個隊列接受消息的接口：
*QueueConnectionFactory
* Queue
* QueueConnection
* QueueSession
* Message
* QueueSender
* QueueReceiver
與在JMS公共API中一樣，QueueConnectionFactory和Queue對象必須通過JNDI從JMS提供者處獲得。大多數接口名稱僅僅是在公共API接口名稱之前添加Queue一詞而已。下圖顯示了基於隊列的JMS API接口之間的流程和關係。
3.2、發佈/訂閱 API
發佈/訂閱消息傳送模型內部使用的接口如下：
*TopicConnectionFactory
* Topic
* TopicConnection
* TopicSession
* Message
* TopicPublisher
* TopicSubscriber下圖是基於主題的JMS API接口的關係和流程：
4、企業消息傳送模型
消息傳送機制的一個基本思想就是：規定應用程序之間的同行應該採用異步方式。將各部分之間連接在一起的代碼會假定這是一條單向消息，它不需要立即從另一個應用程序那裏得到響應。一旦一條消息被髮出，消息傳送客戶端就能夠轉向其他任務，他不必等待對這條消息的響應。這是RPC和異步消息傳送之間的主要區別，而且，它對於理解消息傳送系統的優點來說至關重要。
在一個異步消息傳送系統當中，每個子系統都不存在和其他系統的耦合。下圖是典型的架構：
