AMQ 是一個 系統間使用JMS協議進程遠程通信的 消息代理
企業消息軟件不僅是一種應用間的通信方式，也是集成的方式。一直以來沒有解決方案，apche amq就是一種解決方案。 提供了一個基於異步通信的鬆散耦合的，高可用，高性能，高可擴展的企業消息中間件(MOM)。
其作用是調解分佈式應用中的時間和消息，保證他們能夠到達預期的接收者手裏。所以高可用，高可擴展，高性能對他來講就至關重要了。
AMQ的特性
1. 順應JMS規範， 具有了JMS協議的一些優點和保障，包括同步及異步消息的傳遞，有且僅有一次消息傳遞，訂閱者消息持久性，以及更多。
2. 連通性： 更多的鏈接選項： http,https,tcp，廣播等等。 多種協議的連通性會減少其他平臺的接入。
3. 可插拔的持久性和安全性： 多種持久性方式和安全性選項，比如可以使用他自己的KahaDB超快速的方式，還可以使用JDBC，。 安全性可以使用屬性文件或者是JAAS登錄模塊。
4. 使用Java構建應用
5. 與常見的容器整合
6. 多語言支持的客戶端API
7. 集羣代理
8. 簡單的管理
why and when
鬆散耦合設計 和 AMQ
借用AMQ可以很好的把鬆散耦合引入系統中，以解決RPC調用的耦合問題， 這種異步通信的方式，使得系統之間不存在相互依存的關係。另外AMP的能力保證消息的發送及一定被接收，且不會重複發送。 發送者只發送不關心接收者。
緊耦合的缺點： 會造成阻塞，要等待應答才結束。 修改及新增功能的成本很高
鬆耦合：更容易擴展，大家都跟MOM打交道
什麼時候使用：
1. 最終一致性
2. 可用於不同語言間的通訊
3. 用來代替RPC風格的，因爲可以動態擴展可能會更快，不會造成RPC帶來的峯值的上限。
4. 鬆散耦合架構的系統，減少依賴關係，利用異步通信，實現事件驅動的架構(整個虛擬的業務都是這樣的)。 橫向擴展(僅僅通過增加消費節點的數量就能夠提高處理能力)
5. 爲了提高應用程序的可伸縮性 ， 跟上面一個意思啊
包下面自帶的例子的使用：
\apache-activemq-5.13.2\examples\openwire\advanced-scenarios
jms-example-queue這個工程，下面直接執行Consumer和Producer
說明企業消息
消息中間件是發送者和接收者的信息中介。
提供異步的鬆散耦合的，可靠的，可擴展的，安全的通信
分佈式應用程序或系統之間的方式。
信息通過消息中間件從一個應用傳遞給另外一個應用。這樣就使得發送者和接收者解耦。
因爲不限制同時發送和接收，發送者和接收者互相不認識，這樣成爲異步消息傳遞。
消息中間件還提供了消息持久性，複雜的消息路由，消息轉換。
持久性防丟和排錯。
複雜的路由有很廣闊的想象。
消息轉換，允許兩個應用通過同樣的格式通訊。
Active MQ提供了上面所有的支持。
什麼是JMS
各種消息中間件使用不同的API對外提供服務，知道JMS來了
目的是提供Java程序發送和接收消息的標準話的API。
最大限度的減少Java程序員開發複雜通訊程序所需要的知識，同時提供一定的可擴展性
類似於JDBC是一種高抽象的接口。
1998年開始2002年JMS1.1。提供瞭如下的概念：
1. JMS client Java開發的發送和接受消息的程序
2. Non-JMS client 使用JMS provider提供的原生的客戶端，而不是Java開發的。
3. JMS producer 創建和發送消息的程序
4. JMS consumer 接收和處理消息的程序
5. JMS provider JAVA開發的JMS協議的實現
6. JMS message 被JMS Client和producer發送和接收的消息。
7. JMS domains 消息類型。 點對點和發佈/訂閱模式
8. Administered objects 能夠通過JNDI訪問的一些預製的配置數據
9. Connection factory 從工廠得到到JMS提供者的鏈接
10. Destination 消息從那裏收，消息發到哪裏去。
JMS規範
JMSclient
客戶端通過JMS API跟JMS 提供者進行通訊， 類似於JDBC。
但是JMS provider一般不是存的JMS的，一般都是看上了他的額外的功能。因此在換中間件的時候有可能帶來額外的工作。
分爲了發送消息的生產者，和接收消息的消費者。 有可能兼具有二者的功能
1. JMS Producer
向目的地發送消息。用Session.createProducer() 創建，被MessageProducer.send()覆蓋
2. JMS Consumer
從目的地同步receive的，或者異步的MessageListener.onMessage()接收消息。
JMS Provider JMS Api的實現者
The JMS message
是JMS規範中最重要的概念。允許文本，二進制數據作爲體，以及頭，其消息格式如圖：
包含報頭和payload。 被設計成靈活和易於理解，唯一複雜的地方在於頭信息
大部分自動設置， 可以是標註的JMS或者是JMS Provider提供的方法
JMSDestination
JMSDeliveryMode
傳遞方式， 支持兩種：持久性和非持久性。
持久性：讓provider持久化消息。 犧牲性能，換取可靠性，在provider宕機之後不會丟失消息
非持久性，保證非持久化並且傳遞且只傳遞一次消息。 性能更好。
設置在provider對所有都生效。 但是會被單獨消息的設置覆蓋
JMSExpiration
消息過期時間。 producer.settimetolive方法設定所有該producer發出的，或者 MessageProducer.send()中設定該次發出的。 JMS使用當前時間+timetolive的設置來得到過期時間，因此如果時間設置的有問題，是有可能發不出去消息的。
默認是永不過期。
JMSMessageID
provider指定的唯一標示， 可以用在存儲中。 因爲生成這個有一定的開銷，可以通過producer.setdisablemessageid來建議provider忽略，但是僅僅是個建議。
JMSPriority
producer設置，優先級，10個級別，可以被單個消息的覆蓋。 跟java線程的優先級類似
JMSTimestamp
JMS producer發出消息的時間，可以建議忽略，且爲空值
jmsClient設置的：
JMSCorrelationID
通常用來關聯多個Message。例如需要回復一個消息，可以把JMSCorrelationID設置爲所收到的消息的JMSMessageID
JMSReplyTo
有時消息生產者希望消費者回復一個消息，JMSReplyTo爲一個Destination，表示需要回復的目的地。當然消費者可以不理會它
JMSType
Headers set optionally by the JMS provider:
JMSRedelivered
消息重發，沒有收到nok
JMS 屬性
頭中的附件參數。getpropertynames()得到一個枚舉 分爲了：自定義屬性，JMS定義屬性，provider定義屬性。
自定義屬性：
使用getbooleanproperty() /
setbooleanproperty()，getstringproperty() / setstringproperty()等方法任意定義。
JMS定義屬性：
JMSX開頭的一些屬性。有很多，用到再說
provider屬性：
JMS_
供應商自定義的。
Message selectors
有時客戶端訂閱到一個目的地，但是隻想接收指定的部分消息。 這樣可以每個消息都帶有一個標示，然後客戶端可以告訴provider只接收這樣標示的消息。
只能設置消息頭和屬性
public void sendStockMessage(Session session,
MessageProducer producer,
Destination destination,
String payload,
String symbol,
double price)
throws JMSException {
TextMessage textMessage = session.createTextMessage();
textMessage.setText(payload);
textMessage.setStringProperty(“SYMBOL”, symbol);
textMessage.setDoubleProperty(“PRICE”, price);
producer.send(destination, textMessage);
}
String selector = “SYMBOL = ‘AAPL’”;
MessageConsumer consumer =
session.createConsumer(destination, selector);
…
消息體
六種類型消息體：payload
Message base類，包含了head和屬性
TextMessae payload是String
MapMessage
ByteMessage
StreamMessage
ObjectMessage
JMS domains
支持兩種方式：point-to-point and publish/subscribe
點對點
- 消息一次且僅一次傳遞給一個消費
- 同步使用MessageConsumer.receive(),異步使用MessageConsumer setmessagelistener()
- 隊列存儲消息直到發出或者到期
- 多個用戶可以註冊到同一個隊列，會發送給一個消費者，並得到應答，是循環分配的
發佈訂閱模式
- 發送消息到主題，所有訂閱者都會收到
- 也有異步同步兩種
- 可以持久訂閱，當時短線的消費者會產生擠壓，等連上之後又會繼續消費掉
- 持久性與持久化 DURABILITY PERSISTENCE
有點差別，持久性是訂閱的一個屬性，僅有發佈\訂閱模式纔有，僅僅用於離線後是否仍然記錄那些消息沒有發給訂閱者
請求應答模式
雖然協議裏沒有，但是確實提供了一些消息頭能夠處理基本的請求/應答模式
JMSReplyTo 指定 應答需要發送的目的地。
應答的消息的JMSCorrelationID 指定爲請求消息的JMSMessageID 這樣把1請求和應答關聯起來， 有便利的類:QueueRequestor
Administered objects
管理對象。 本來應該由JMS管理員創建的一些包含特定的provider提供的配置信息。
用來隱藏特定的供應商的細節，有點像JNDI，或者dubbo.只關心接口不關心實現。
JMS定義了兩種這種對象：ConnecitonFactory和Destination
- ConnecitonFactory
client 通過這個創建到provider的鏈接。 這個鏈接可能會是比較大。所以使用一個連接池會是比較好的選擇。 一個Connection跟JDBC裏的Connection差不多。是一個操作數據庫的接口。
JMS Connection 用來創建JMS session與provider提供交互。 - Destination
封裝了provider特定的消費和發送地址。雖然由session創建但是生命週期跟connection相關。
臨時的destination的創建目的是用在請求/應答模式。該連接關閉就沒了。