1.訊息傳送機制基礎

近年來，系統的複雜性和先進性增長非常顯著，對於系統的可靠性、可伸縮性和靈活性等的要求要比以前要高。為了適應這種對更好更快的系統日益增長的需求，體系結構師、架構師和開發者已經開始利用訊息傳送機制，作為解決這些複雜問題的一種方式。

儘管近年來JMS API未發生顯著的變化，但訊息傳送機制的使用方式有了很大的變化。解決可靠性和可伸縮性問題，已經廣泛使用了訊息傳送機制。與此同時，它還被用於解決許多商業應用程式和非商業應用遇到的大量問題。

異構整合是訊息傳送機制在其中起到關鍵作用的一個領域，越來越多的公司都正面臨著在企業內部、跨企業整合異構系統和應用程式的問題。訊息傳送機制還具有非同步處理請求的能力，它能夠為系統體系結構師和開發者提供解決方案，減輕和消除系統瓶頸，提高終端使用者的生產率和系統的整體可伸縮性。

應用程式到應用程式之間的訊息傳送系統，在應用於業務系統時，通常被稱為企業訊息傳送系統，或面向訊息的中介軟體(MOM)。企業訊息系統允許兩個或更多的應用程式以訊息的形式來交換訊息，此時，一條訊息就是業務資料和網路路由頭的一個自包含的資料包，根據其業務場景可以是任何內容。

通過使用面向訊息的中介軟體，訊息通過網路從一個應用程式傳送到另一個應用程式中，企業中介軟體產品能夠確保訊息在應用程式中間正確地分發。此外，對於那些需要可靠地大量交換訊息的企業，這些產品能夠為其提供容錯和負載均衡，可伸縮性和事務型的支援。

所有的企業訊息傳送系統廠商都為應用程式開發者提供了一個API，用於傳送和接收訊息。當訊息傳送系統廠商各自實現自己的網路協議、路由以及管理工具時，提供的開發者語義

JMS是一種廠商無關的Java API，可以供多個不同的企業訊息廠商使用。JMS和JDBC非常相似，應用程式開發者能夠重用同樣的API來訪問不同型別的系統。

1.1訊息傳送機制的優點

訊息傳送機制可以解決諸多的體系結構性挑戰，比如異構整合，可伸縮性，系統瓶頸，併發處理，以及整體體系結構靈活性和敏捷性。

異構平臺的通訊和整合可能是訊息傳送機制最為典型的應用範例，使用訊息傳送機制可以向在完全不同的平臺上實現的應用程式和系統請求呼叫服務。許多開源訊息傳送系統和商業訊息傳送系統使用了一種整合訊息橋，能夠使用

在應對異構系統的整合問題方面，已經有很多種解決方案。早期的FTP和其他檔案傳輸手段的“人力網路”方法，使用資料庫在兩個異構系統之間共享資訊，遠端過程呼叫RPC，這些解決方案都有各自的優缺點，只有訊息傳送機制提供的去耦解決方案，能夠真正實現跨應用程式或子系統共享資料和功能。Web Service已經作為異構系統整合的另一種可能的解決方案脫穎而出，不過Web Service在可靠性方面的欠缺，使得訊息傳送機制成為一種更佳的整合選擇。

無論何時，只要您的某個程序跟不上對它訪問請求的速度，就會產生系統和應用程式之間的瓶頸問題。在IT系統中，某些元件只能夠處理數量有限的請求，而且它很快變成系統瓶頸。IT系統內部，訊息傳送機制可以用於緩解乃至消除系統瓶頸。與一個同步元件處理眾多請求時，眾多請求一個接著一個積聚阻塞不同，這時請求會發送到一個訊息傳送系統，該系統將該請求分發給多個訊息偵聽器元件。如此一來，就可以緩解單獨採用點對點同步連線帶來的系統瓶頸，某些情況下可以消除這些瓶頸。

和緩解系統瓶頸類似，訊息傳送機制還可以用於提高系統的整體可伸縮性和吞吐量，同時還能有效地縮減響應時間。通過引入能夠併發處理不同訊息的多個訊息接收者，訊息傳送系統的伸縮性得以實現。

提高整體可伸縮性的另一種方法，就是要儘可能使用系統的非同步方式，如此一來，按照這種方式的元件去耦就會允許系統水平增長。

我們設想這樣一種場景：終端使用者通過基於Web的使用者介面，向系統傳送一個請求，這個介面需要花好幾分鐘執行，在此期間，終端使用者一直等待結果，而無法完成其他工作。通過使用非同步訊息傳送機制，終端使用者能夠向系統傳送一個請求，並立即得到響應，表明該請求已經被接收。現在，當執行長時間執行請求時，終端使用者可以在系統上繼續做其他工作，一旦該請求處理完畢，就立即告知使用者，回傳處理結果。通過使用訊息傳送機制，終端使用者就能夠以更短的等待時間來完成更多的工作，使終端使用者能夠有更高的生產率。

不過，作為這種靈活性和生產率提升之間的折中平衡，增加了系統的複雜性。

使用訊息傳送機制作為企業體系結構整體方案的一部分，為未來的體系結構靈活性和敏捷性留有更大的空間和餘地。這些優良特性是通過使用抽象和去耦來實現的。

體系結構敏捷性是對不斷變化的環境快速響應的能力。通過使用訊息傳送機制來抽象和去耦元件，能夠快速地響應軟體，硬體，甚至是業務的變化。

1.2企業訊息傳送

企業訊息傳送算不上新概念，訊息傳送系統，比如商業的IBM MQ, Sonic MQ, msMQ, 以及Tibco Rendezvous等已經存在多年，而Active MQ等幾種開源訊息傳送系統也已經進入市場，並在企業生產環境中使用。此外，面向服務體系架構（SOA）的推出，已經促生了企業服務匯流排（ESB）的新型訊息傳送產品。儘管大多數企業服務匯流排允許使用基於HTTP的通訊，基於訊息傳送的系統仍然繼續保持了在大多數生產企業系統當中的標準地位。

企業訊息傳送的一個關鍵概念就是：訊息是通過網路從一個系統非同步地傳送給其他系統的，非同步傳送一條訊息意味著傳送者不必等待接收者接收或處理該訊息；它可以自由地傳送訊息並持續進行處理。非同步訊息可以作為獨立的自主單元，每條訊息都是自包含的，帶有處理其業務邏輯所必須的所有資料和狀態資訊。

非同步訊息傳遞機制中，應用程式使用一個簡單的API來構建一條訊息，將該訊息轉發給面向訊息的中介軟體，傳送給一個或多個預定接收者。訊息是自描述的，包含必要的上下文，允許接收者獨立地完成它們的工作。

訊息傳送系統由訊息傳送客戶端和幾種訊息傳送中介軟體伺服器組成，客戶端向訊息傳送伺服器傳送訊息，該伺服器隨後再將那些訊息分發給其他客戶端。

使用集中式體系結構的企業訊息傳送系統，依賴於一臺訊息伺服器。訊息伺服器負責從一個客戶端向其他訊息傳送客戶端傳送訊息。訊息伺服器可實現傳送客戶端和其他接收客戶端之間的解耦。客戶端僅僅能看到訊息傳送伺服器，而不會看到其他客戶端，這就允許在不會影響系統整體的情況下新增和刪除客戶端。

集中式體系結構是一種星形拓撲結構，星形體系結構適合於一個最小數量的網路連線，它仍然允許系統的任何部分和其他部分通訊。集中式訊息伺服器可以是按照邏輯單元方式執行的一個分散式叢集。

當前，所有的分散式體系結構都在使用網路層IP組播。基於組播的訊息傳送系統沒有集中式伺服器。一些伺服器功能（永續性，安全，事務）作為一個客戶端的本地部分嵌入進來，而此時訊息路由則利用IP組播協議委託給網路層。

與集中式體系結構不同，分散式體系結構不需要用於訊息路由的伺服器，網路會自動處理路由。然而，每個客戶端仍然需要具有像伺服器那樣的功能，比如訊息永續性和僅一次傳遞之類的訊息傳送語義。

一個分散式體系結構通常意味著使用IP組播協議，而一個集中式體系結構則意味著TCP/IP在不同元件之間實現的基礎。一個訊息傳送系統廠商的體系結構還可能會將兩種方式結合起來，客戶端可以使用TCP/IP連線到一個守護程序，它使用IP組播組依次和其他守護程序通訊。

本文中使用集中式體系結構作為企業訊息傳送的邏輯視角。

1.3訊息傳送模型

JMS支援兩種訊息傳送模型：點對點(p2p)模型和釋出/訂閱(pub/sub)模型。釋出/訂閱模型設計用於一對多訊息廣播，而點對點模型則設計用於一對一訊息傳送。

從JMS的視角來看，訊息傳送客戶端成為JMS客戶端，而訊息傳送系統成為JMS提供者。一個JMS應用程式是由多個JMS客戶端和一個JMS提供者所組成的業務系統。

生產訊息的JMS客戶稱為訊息生產者，而接收訊息的客戶端稱為訊息消費者，一個JMS客戶端既可以是訊息生產者又可以是訊息消費者。

點對點訊息傳送模型允許JMS客戶端通過佇列這個虛擬通道來同步和非同步傳送、接收訊息。傳統上，點對點模型是一個基於拉取和輪詢的訊息傳送模型，這種模型從佇列中請求訊息，而不是自動地將訊息推送到客戶端。點對點傳送模型的一個突出特點是，傳送到佇列的訊息被一個且僅一個接收者接收，即便可能有多個接收者在同一佇列中偵聽同一訊息。

點對點傳送模型既支援非同步“即用即棄”訊息傳送方式，又支援同步“請求應答”傳送方式。點對點模型比釋出/訂閱模型具有更強的耦合性，傳送者通常會知道訊息怎樣使用，而且也知道訊息被誰接收。

點對點模型支援複雜均衡，允許多個接收者偵聽同一佇列，並以此來分配負載。JMS提供者負責管理佇列，確保每條訊息被組內下一個可用的接收者消費一次，且僅一次。JMS規範規定在多個接收者中間分發訊息的規則，儘管某些JMS廠商已經選擇實現此規則來提升負載均衡能力。

釋出/訂閱模型中，訊息會被髮布到一個名為主題的虛擬通道中。與點對點模型不同，使用釋出/訂閱模型釋出到一個主題的訊息，能夠由多個訂閱者所接收，有時也稱這項技術為廣播訊息。每個訂閱者都會得到這個訊息的一個副本。總地來說，釋出/訂閱訊息傳送模型基本上是一個基於推送的模型，其中訊息自動向消費者廣播，無需請求和輪詢主題來獲得訊息。

釋出/訂閱模型的去耦能力要比p2p模型更強，訊息釋出者通常不會意識到有多少訂閱者或那些訂閱者如何處理這些訊息。在釋出/訂閱訊息傳送模型中，有多種不同型別的訂閱者，非持久訂閱者是臨時訂閱型別，只在主動偵聽主題時才接收訊息；持久訂閱者將接收到釋出的每條訊息的一個副本，即便釋出訊息時它們處於離線狀態。

1.4JMS API

JMS自身並不是一種訊息傳送系統；它是訊息傳送客戶端與訊息傳送系統通訊時所需介面和類的一個抽象。與JDBC訪問資料庫，JNDI抽象訪問命令目錄介面服務一樣，JMS抽象可以訪問訊息服務提供者，使用JMS，應用程式的訊息傳送客戶端可以實現跨訊息伺服器產品的移植。

JMS規範是一個具有單向優勢的，健壯的規範，包括了一組豐富的訊息傳送語義，並和簡單而靈活的API結合，用於將訊息傳送合併到應用程式中。

JMS API分成3個部分：公共API，點對點API和釋出/訂閱API。

公共API中包含的JMS API介面主要有：

lConnectionFactory

lDestination

lConnection

lSession

lMessage

lMessageProducer

lMessageConsumer

這些公共介面中，ConnectionFactory和Destination必須使用JNDI從提供者處獲得，其他介面可以在工廠方法在不同的API中建立。

點對點訊息模型API特指JMS API以內基於佇列的介面，而不是公共API介面。

由於基於主題的JMS API類似於基於佇列的API。釋出/訂閱模型使用主題、釋出者和訂閱者這些術語，而p2p模型使用佇列、傳送者和接收者。

1.5實際場景

面向服務體系結構（SOA）作為一種體系結構，定義了從對應的企業服務實現中抽象出來的業務服務，因此，SOA已經促生了一種稱為企業服務匯流排（ESB）的新型別中介軟體。大多數成熟的ESB產品都使用了訊息傳送機制，儘管某些ESB產品能夠支援傳統的非JMS型HTTP傳送，但是大多數企業級的產品實現都採用訊息傳送作為通訊協議。

在需要將業務服務從其底層實現中完全抽象出來的SOA內部構建抽象層時，訊息傳送是一種極好的手段。使用訊息傳送機制，業務服務無需關心對應的實現處於何種環境。業界對於SOA的熱衷和應用，反而又掀起了普遍使用訊息傳送解決方案的熱潮。

事件驅動體系結構作為一種體系結構，建立在下面的前提上：程序和事件編排是動態的和非常複雜的，因而通過一箇中央控制組件來進行控制或實現是不可行的。當系統中發生一個活動時，該程序向系統傳送一個事件，指示一個活動的發生。這個事件可能會啟動其他程序，且程序之間去耦。

訊息傳送機制是基於事件驅動體系結構系統的基礎。通常來說，事件一般是以空負載的訊息模式傳送的，這些訊息會在訊息頭中包含和事件有關的一些資訊，儘管某些訊息會將應用程式資料作為事件的一部分進行傳送。基於EDA的體系結構大多使用釋出/訂閱模型，作為在系統內廣播事件的手段。

大多數公司經由合併、收購、移植和錯誤決策後，最終會擁有種類繁多的異構業務支撐平臺、產品和語言。訊息傳送機制在這些異構平臺之間的通訊中起到了關鍵的作用。

儘管Java平臺可以使用JMS API，而其他平臺，比如.NET和C++都無法使用。許多商業訊息傳送系統廠商和開源消傳送系統廠商都會支援JMS API和一個本機API。這些提供者都會有一個內建的訊息傳送橋，允許JMS提供者將一條JMS訊息轉換為內部訊息，反之亦然。例如ActiveMQ就提供了一個訊息傳送橋，用於將MSMQ訊息轉換為JMS格式。

大多數成熟的組織都同時擁有遺留應用系統和新的應用系統，這些系統都是獨立實現的，無法實現互操作。很多時候，各個組織都會有將這些應用系統整合起來的強烈需求，以便能夠在大規模企業執行中共享資訊並實現協作，這些應用系統的整合稱為企業應用整合（EAI）。

雖然EAI使用了大量廠商提供的和自己開發的解決方案，但是，企業訊息傳送系統仍然是大多數解決方案的主流。企業訊息傳送系統允許煙囪式應用系統和事件進行通訊並傳送資料，並保持物理上的獨立，資料和事件可以通過主題或佇列以訊息的形式進行交換，它們提供了可以實現各個參與應用系統解耦的一個抽象。

XML和現代訊息傳送系統已經從根本上改變了在如今稱為企業到企業的系統中，如何進行業務資料交換和互動的狀況。使用訊息傳送系統是現代B2B解決方案的主流趨勢，因為它允許各個組織相互協作，而無需將它們的業務系統緊密整合起來。

JMS訊息傳送系統能夠確保地理上分散的業務資料交換的安全性和可靠性。

拍賣網站，股票證券交易這類應用都必須將資料以一對多的方式推送給堪稱海量的接收者。廣播訊息需要各個接收者逐一選擇路由和過濾，當輸出訊息以一對多方式進行傳送時，經常需要將對這種訊息的響應發回給廣播者。這是企業訊息傳送系統非常適用的一種情況，釋出/訂閱模型可以用於釋出訊息，p2p模型可以用於響應。

這種情況下，傳送可靠性的選擇成為關鍵因素，需要綜合利用訊息傳送機制的可靠性，因為釋出/訂閱模型分發速度很快但不可靠，而使用p2p模型是非常可靠的。

在JMS中，釋出/訂閱主題和p2p佇列是集中管理的，都稱為JMS受管物件。應用程式之間通訊時，並不用知道各個主題和佇列的網路位置，僅僅將主題和佇列物件作為識別符號使用而已。使用主題和佇列為JMS應用程式提供了一定程度位置的透明性和靈活性，使得在一個企業系統中新增和刪除參與者稱為可能。

1.6RPC和非同步訊息傳送

RPC是通常用於描述分散式計算模型的術語。基於元件的體系結構，比如EJB就是建立在這個模型基礎上的。對於許多應用程式來說，基於RPC的技術已經是，而且將繼續是切實可行的解決方案。

RPC試圖模仿在一個程序中執行的某個系統的行為。在呼叫一個遠端過程時，呼叫者將被阻塞，直到該過程完成並將控制權返回給呼叫者。從開發者的角度看，這種同步模型使得該系統就像是執行在一個程序中。RPC同步的本質特性，將客戶端和伺服器二者緊密地耦合在一起。因為客戶端被阻塞，無法繼續進行工作，直到伺服器做出響應為止。

RPC緊密耦合的本質特性導致出現了相互高度依賴的系統，其中一個系統的失效會對其他系統產生立竿見影的弱化影響。

雖然RPC在多數場景下表現優秀，但在系統對系統的處理過程中，它的同步、緊密耦合特性卻是一個嚴重的缺陷，因為系統對系統有很多垂直的應用程式整合在一起。

這些系統之間的連線管理是多對多的關係，當向混合系統中加入另一個應用程式時，不得不回頭來讓其他系統都知道它，而且協調應用程式的崩潰，升級問題。

正是RPC系統的同步、緊密耦合、相互依賴等本質特性，使得子系統中出現的故障最終會導致整個系統的失效。

訊息傳送機制的一個基本思想就是：規定應用程式之間的通訊應該採用非同步方式。沒有阻塞現象，一旦一條訊息被髮出，訊息傳送客戶端就能夠轉向其他任務，不必等待對這條訊息的響應。這是訊息傳送系統和RPC最本質的區別。

在一個非同步訊息傳送系統中，每個子系統都不存在與其他系統之間的耦合。它們通過訊息傳送伺服器進行通訊。當某個子系統出現故障，不會妨礙其他子系統的執行。

在網路化系統中會出現故障，這是不可避免的事實。其中的一個系統，會在其連續執行期間的某個時刻，發生不可預測的故障，或需要停機。考慮到這個因素，JMS提供了保證訊息傳送方式，確保即便發生故障，預定消費者也會接受到這條訊息。

保證傳送使用的是一種“儲存並轉發”的機制，這就意味著，如果預定消費者當前並不可用，底層訊息伺服器就會將輸入的訊息寫到一個持久儲存器中。隨後，當該接收應用程式變為可用時，儲存轉發會把預定消費者在不可用時錯過的所有訊息傳送給它們。

JMS不僅僅是另外一種事件服務。它的設計涵蓋了範圍極廣的企業應用程式，包括EAI, B2B和推送模型。通過非同步處理，儲存轉發和保證傳送機制，為保持業務連續執行並實現不間斷服務提供了很高的可用性。還通過釋出/訂閱功能和點對點功能，提供了整合靈活性。通過位置透明和管理控制，提供了一種健壯的、基於服務的體系結構。