jmsjava
㈠ java消息服務的JMS消息模型
除了消息頭中定義好的標准屬性外，JMS 提供一種機制增加新屬性到消息頭中，這種新屬性包含以下幾種： 1. 應用需要用到的屬性；2. 消息頭中原有的一些可選屬性；3. JMS Provider 需要用到的屬性。標準的 JMS 消息頭包含以下屬性：
JMSDestination：消息發送的目的地；
JMSDeliveryMode：傳遞模式， 有兩種模式：PERSISTENT 和NON_PERSISTENT，PERSISTENT 表示該消息一定要被送到目的地，否則會導致應用錯誤。NON_PERSISTENT 表示偶然丟失該消息是被允許的，這兩種模式使開發者可以在消息傳遞的可靠性和吞吐量之間找到平衡點；
JMSMessageID：唯一識別每個消息的標識，由JMS Provider 產生；
JMSTimestamp：一個消息被提交給JMS Provider 到消息被發出的時間；
JMSCorrelationID：用來連接到另外一個消息，典型的應用是在回復消息中連接到原消息；
JMSReplyTo：提供本消息回復消息的目的地址；
JMSRedelivered：如果一個客戶端收到一個設置了JMSRedelivered 屬性的消息，則表示可能該客戶端曾經在早些時候收到過該消息，但並沒有簽收(acknowledged)；
JMSType：消息類型的識別符；
JMSExpiration：消息過期時間，等於 QueueSender 的 send 方法中的 timeToLive 值或 TopicPublisher 的publish 方法中的 timeToLive 值加上發送時刻的 GMT 時間值。如果 timeToLive 值等於零，則 JMSExpiration 被設為零，表示該消息永不過期。如果發送後，在消息過期時間之後消息還沒有被發送到目的地，則該消息被清除。
JMSPriority：消息優先順序，從 0-9 十個級別，0-4 是普通消息，5-9 是加急消息。JMS 不要求 JMS Provider 嚴格按照這十個優先順序發送消息，但必須保證加急消息要先於普通消息到達。 JMS API 定義了 5 種消息體格式，也叫消息類型，你可以使用不同形式發送接收數據並可以兼容現有的消息格式，下面描述這 5 種類型：
TextMessage：java.lang.String 對象，如 xml 文件內容；
MapMessage：名/值對的集合，名是 String 對象，值類型可以是 Java 任何基本類型；
BytesMessage：位元組流；
StreamMessage：Java 中的輸入輸出流；
ObjectMessage：Java 中的可序列化對象；
Message：沒有消息體，只有消息頭和屬性。 Java 消息服務支持兩種消息模型：Point-to-Point 消息(P2P)和發布訂閱消息 (Publish Subscribe messaging，簡稱Pub/Sub)。JMS 規范並不要求供應商同時支持這兩種消息模型，但開發者應該熟悉這兩種消息模型的優勢與缺點。P2P 消息模型是在點對點之間傳遞消息時使用。如果應用程序開發者希望每一條消息都能夠被處理，那麼應該使用 P2P 消息模型。與 Pub/Sub 消息模型不同，P2P 消息總是能夠被傳送到指定的位置。
Pub/Sub 模型在一到多的消息廣播時使用。如果一定程度的消息傳遞的不可靠性可以被接受的話，那麼應用程序開發者也可以使用 Pub/Sub 消息模型。換句話說，它適用於所有的消息消費程序並不要求能夠收到所有的信息或者消息消費程序並不想接收到任何消息的情況。
㈡ 1. 解釋java的關鍵字的作用JVM, JNDI, JMS, JTA, JDK,JAF,RMI
JVM：Java
Virtual
Machine（Java虛擬機）http://ke..com/view/160708.htm
JNDI：Java命名系統介面http://ke..com/view/209575.htm
JMS：Java消息服務http://ke..com/view/157103.htm
JTA：Java事務API
http://ke..com/view/512788.htm
JDK：Java
Development
Kit
http://ke..com/view/25214.htm
JAF：JavaBeans
Activation
Framework
http://ke..com/view/1280380.htm
RMI：Remote
Method
Invocation，遠程方法調用http://ke..com/view/99017.htm
㈢ JAVA中的JMS是什麼意思它起了什麼作用
. JMS基本概念
JMS(Java Message Service)是訪問企業消息系統的標准API,它便於消息系
統中的Java應用程序進行消息交換,並且通過提供標準的產生、發送、接收消息的介面簡化企業應用的開發。
2. JMS基本功能
JMS是用於和面向消息的中間件相互通信的應用程序介面。它既支持點對點(point-to-point)的域，又支持發布/訂閱(publish/subscribe)類型的域，並且提供對下列類型的支持：經認可的消息傳遞,事務型消息的傳遞，一致性消息和具有持久性的訂閱者支持。JMS還提供了另一種方式來對您的應用與舊的後台系統相集成。
3. WebLogic JMS Server介紹
WebLogic Server8.1符合JAVA規范,並通過Sun Microsystems J2EE 1.3認
證.作為WebLogic的一部分,當然WebLogic JMS Server也完全遵從JMS規范,還支持集群,並可以應用於實際企業系統.下圖是WebLogic JMS Server體系結構.圖中可以看到WebLogic JMS Server主要組件有: WebLogic JMS servers(用於消息通信),Java客戶端,JNDI(用於域名查找), 後備存儲(用於持久消息存儲,基於文件或者JDBC資料庫).
二. WebLogic JMS特性
1. 消息通信模型
JMS 支持兩種消息通信模型：點到點（point-to-point）（PTP）模型和發布/訂閱（Pub/Sub）模型。除了下列不同之外，這兩種消息通信模型非常地相似：
PTP 模型規定了一個消息只能有一個接收者;Pub/Sub 模型允許一個消息可以有多個接收者。
2. 消息組成
消息傳遞系統的中心就是消息。
一條 Message 分為三個組成部分：
· 頭（header）是個標准欄位集，客戶機和供應商都用它來標識和路由消息。
· 屬性（property）支持把可選頭欄位添加到消息。如果您的應用程序需要不使用標准頭欄位對消息編目和分類，您就可以添加一個屬性到消息以實現這個編目和分類。提供 set<Type>Property(...) 和 get<Type>Property(...) 方法以設置和獲取各種 Java 類型的屬性，包括 Object。JMS 定義了一個供應商選擇提供的標准屬性集。
· 消息的主體（body）包含要發送給接收應用程序的內容。每個消息介面特定於它所支持的內容類型。
JMS 為不同類型的內容提供了它們各自的消息類型，但是所有消息都派生自 Message 介面。
· StreamMessage：包含 Java 基本數值流，用標准流操作來順序的填充和讀取。
· MapMessage：包含一組名/值對；名稱為 string 類型，而值為 Java 的基本類型。
· TextMessage：包含一個 String。
· ObjectMessage：包含一個 Serializable Java 對象；能使用 JDK 的集合類。
· BytesMessage：包含未解釋位元組流: 編碼主體以匹配現存的消息格式。
· XMLMessage: 包含XML內容。擴展TextMessage,XMLMessage 類型的使用，使得消息過濾非常便利。
3. 消息確認模式
非事務性會話中，應用程序創建的會話有5 種確認模式,而在事務性會話中，確認模式被忽略。
五種確認模式說明:
· AUTO_ACKNOWLEDGE：自動確認模式。一旦接收方應用程序的方法調用從處理消息處返回，會話對象就會確認消息的接收。
· CLIENT_ACKNOWLEDGE：客戶端確認模式。會話對象依賴於應用程序對被接收的消息調用一個acknowledge()方法。一旦這個方法被調用，會話會確認最後一次確認之後所有接收到的消息。這種模式允許應用程序以一個調用來接收，處理並確認一批消息。注意：在管理控制台中，如果連接工廠的Acknowledge Policy（確認方針）屬性被設置為"Previous"（提前），但是你希望為一個給定的會話確認所有接收到的消息，那麼就用最後一條消息來調用acknowledge()方法。
· DUPS_OK_ACKNOWLEDGE：允許副本的確認模式。一旦接收方應用程序的方法調用從處理消息處返回，會話對象就會確認消息的接收；而且允許重復確認。在需要考慮資源使用時，這種模式非常有效。注意：如果你的應用程序無法處理重復的消息的話，你應該避免使用這種模式。如果發送消息的初始化嘗試失敗，那麼重復的消息可以被重新發送。
· NO_ACKNOWLEDGE：不確認模式。不確認收到的消息是需要的。消息發送給一個NO_ACKNOWLEDGE 會話後，它們會被WebLogic 伺服器立即刪除。在這種模式下，將無法重新獲得已接收的消息，而且可能導致下面的結果：1. 消息可能丟失；和（或者）另一種情況：2. 如果發送消息的初始化嘗試失敗，會出現重復消息被發送的情況。
· MULTICAST_NO_ACKNOWLEDGE：IP組播下的不確認模式，同樣無需確認。發送給一個MULTICAST_NO_ACKNOWLEDGE會話的消息， 會共享之前所述的NO_ACKNOWLEDGE 確認模式一樣的特徵。這種模式支持希望通過IP 組播方式進行消息通信的應用程序，而且無需依賴會話確認提供的服務質量。注意：如果你的應用程序無法處理消息的丟失或者重復，那麼你應該避免使用這種模式。如果發送消息的初始化嘗試失敗的話，重復的消息可能會被再次發送。
註：在上表的5 種確認模式中，AUTO_ACKNOWLEDGE ，DUPS_OK_ACKNOWLEDGE 和
CLIENT_ACKNOWLEDGE 是JMS 規范定義的，NO_ACKNOWLEDGE 和MULTICAST_NO_ACKNOWLEDGE是WebLogic JMS 提供的。
㈣ 什麼是JMS消息服務（Java Message Service）
JMS(Java Message Service)是訪問企業消息系統的標准API,它便於消息系統中的Java應用程序進行消息交換,並且通過提供標準的產生、發送、接收消息的介面簡化企業應用的開發。
1.JMS應用由以下幾部分組成：
JMS provider ：是一個消息系統，它實現了JMS 介面並提供管理和控制的功能。
JMS clients ：是用Java語言寫的一些程序和組件，它們產生和使用消息。
Messages ：是在JMS clients之間傳遞的消息的對象。
Administered objects ：是由使用JMS clients 的人生成的預選設置好的JMS 對象。有兩種這樣的對象：destinations和connection factories。
2.JMS基本功能
JMS是用於和面向消息的中間件相互通信的應用程序介面。它既支持點對點(point-to-point)的域，又支持發布/訂閱 (publish/subscribe)類型的域，並且提供對下列類型的支持：經認可的消息傳遞,事務型消息的傳遞，一致性消息和具有持久性的訂閱者支 持。JMS還提供了另一種方式來對您的應用與舊的後台系統相集成。
㈤ java jms為什麼引入消息中間件
mom4j
mom4j是一個完全實現JMS1.1規范的消息中間件並且向下兼容JMS1.0與1.02.它提供了自己的消息處理存儲使它獨立於關系數據與語言,所以它的客戶端可以用任何語言開發.
OpenJMS
OpenJMS是一個開源的Java Message Service API 1.0.2 規范的實現,它包含有以下特性：
*. 它既支持點到點（point-to-point）（PTP）模型和發布/訂閱（Pub/Sub）模型。
*. 支持同步與非同步消息發送
*. JDBC持久性管理使用資料庫表來存儲消息
*. 可視化管理界面。
*. Applet支持。
*. 能夠與Jakarta Tomcat這樣的Servlet容器結合。
*. 支持RMI, TCP, HTTP 與SSL協議。
*. 客戶端驗證
*. 提供可靠消息傳輸、事務和消息過濾
UberMQ
UberMQ完全實現了Java Message Service 規范。UberMQ是因為現有的許多JMS提供商已經違背了分布式計算的核心原則：快速與簡單而開發的。
Hermes JMS
利用它提供的Swing UI可以很好的實現監控JMS providers。
ActiveMQ
ActiveMQ是一個開放源碼基於Apache 2.0 licenced 發布並實現了JMS 1.1。它能夠與Geronimo，輕量級容器和任Java應用程序無縫的給合。
Somnifugi
Somnifugi使得工作在同一個java虛擬機中的線程能實現消息互發。
MantaRay
MantaRay基於peer-2-peer 技術。它具有以下特性:
1.它既支持點對點(point-to-point)的域，又支持發布/訂閱(publish/subscribe)類型的域。
2.並且提供對下列類型的支持：經認可的消息傳遞,事務型消息的傳遞，一致性消息和具有持久性的訂閱者支持。
3.消息過濾體制。
4.能與WebLogic and WebSphere 給合。
5.支持TCP, UDP 與 HTTP傳輸協。
Presumo
Presumo也是一個實現Java Message Service API的JMS消息中間件。
JORAM
JORAM一個類似於openJMS分布在ObjectWeb之下的JMS消息中間件。
JMS4Spread
JMS4Spread是一個消息系統.它部分地實現了Java消息服務(JMS) API.
-------------------------------------------------------------------------------------------
開源JMS簡單比較
我考慮在公司的項目中採用JMS來降低伺服器之間的耦合性，但為了降低成本，商業軟體是不考慮的，於是只能在開源的並且對商業友好的JMS伺服器中選擇一個了。選擇條件主要基於：
支持JMS 1.1規范
持久化，能滿足商業應用所需的穩定性
滿足項目的性能需求
最好本身提供JNDI服務
最好支持JMX
最好本身提供一個友好的管理工具
最好提供一份完整的文檔
准備進行選擇的JMS伺服器有：OpenJMS、UberMQ、ActiveMQ、MantaRay、JORAM
OpenJMS：老牌的JMS伺服器了，也是我最早知道的開源JMS伺服器，不過只支持JMS 1.02，已經很長時間沒有更新了，因此不予考慮。
UberMQ：採用NIO的JMS伺服器，以前我學習NIO的時候看過它的代碼，寫的蠻不錯的，也支持JMS 1.1。由於採用了NIO，所以具有很高的彈性，在滿足項目的性能需求上沒有什麼問題；本身也提供JNDI服務，但是遺憾的是我bind其他類型的數據時會出錯；提供admin和viewer兩個管理工具，但是在管理工具里不能創建ConnectionFactory和Destination並綁定到JNDI；文檔不太完整；最頭痛的對於持久化支持不好，如果關閉JMS伺服器再開啟，所有保存在JMS中的信息就全部丟失了，這點沒有辦法滿足商業應用所需的穩定性。
ActiveMQ：最近比較活躍的一個JMS伺服器，主頁上的介紹說在協議配置上可以選擇支持NIO，但是我仔細看它所支持的協議，卻並沒有提到如何配置，並且在實際的測試中也並沒有發現其有採用NIO的跡象，多連接一個Client端，伺服器端就增多了一個線程。滿足JMS 1.1，有多種方法進行持久化；本身不提供JNDI，也沒有對JMX的支持，本身不帶管理工具，採用Hermes進行管理（這個我會在以後提到），文檔也相對較少。
MantaRay：也是比較活躍的一個JMS伺服器，採用的是P2P模型，但是我不喜歡這種模型，對於JMS服務來說，很大的一個特點就是客戶端可以不用永遠在線，比如在更新某一個客戶端時需要暫停服務，等服務再度開啟時，這段時間內所接收到的信息並不會丟失，保存在伺服器上，所以我並不能看到P2P模型應用在JMS伺服器上的優勢，況且採用JMS服務就是為了解除耦合，速度並不是唯一需要考量的事情。出於我不喜歡其所採用模型，並且在運行其所帶的示例時都出現了示例時都出現了問題，兩個客戶端互發互收，但是彼此之間都收不到消息，於是不予考慮。
JORAM：支持JMS 1.1，可以持久化到文件，本身提供JNDI服務和提供對JMX的支持，自帶的管理工具可以添加ConnectionFactory和Destination並綁定到JNDI，這點對實現動態管理來說非常有用；文檔非常完備，100多頁的PDF，包含了各種配置和調整信息。其穩定性考慮的尤其好，不僅考慮到JMS伺服器的集群，甚至連JNDI的集群也考慮進去（盡管暫時對我而言還用不上），這點對於商業應用而言應該會有加分。
ActiveMQ是Apache License，JORAM是LGPL，這兩者對於商業應用都是友好的；UberMQ和MantaRay採用是Dual License，UberMQ的Dual License是只要你不分發，就可以允許使用；而MantaRay是商業使用需要應用一個商業的License。
比較上面的這些JMS伺服器，最終我是選擇了JORAM，其滿足了我的絕大部分要求，唯一比較遺憾的是其採用傳統的IO模型，每連接一個Client端會在伺服器端增加兩個線程，這點稍微影響了伺服器的彈性。不過考慮到我們的項目應用，這點暫時可以不用考慮，實在壓力過大了，最多到時候採用JMS集群唄：）
開源JMS再比較
四月份時我曾經比較了那時活躍度比較高的一些開源JMS——《開源JMS簡單比較》，時隔四個月，重新回顧這些項目，發現與四個月以前的比較有一些出入，在這里再進行一些比較：）
比較的項目沒有變化，OpenJMS、UberMQ、ActiveMQ、MantaRay、JORAM，這段時間內沒有出現什麼JMS新秀，JBoss計劃在今年第四季度發布JBoss Messaging，但只要還是捆綁發行，我對其就沒什麼興趣。
在上次的比較中，OpenJMS已經有比較長的一段時間沒有更新了，但最近的四個月似乎又活躍了起來，其預備發行的0.7.7版計劃支持JMS 1.1（這個來的太晚了些），其主頁上的Changelog表明了接下來的這個版本有著較大的變化。這對那些以前將OpenJMS應用在項目中的人來說是一個不錯的消息，但對正在選擇JMS的人而言，OpenJMS的這些改進來的還是稍稍晚了些。
UberMQ這段時間沒有更新，我對它的評價與以前一樣，沒有任何變化。
MantaRay在其主頁上更新了一系列的Flash Demos，通過這些Demo，我更堅定了我的看法——MantaRay並不適合用於企業的JMS服務。
P2P這個詞雖然熱，但是不是什麼地方都需要P2P的，在我看來JMS就是用於解除各個應用之間的耦合，速度是個關鍵指標，但比起這個關鍵指標更重要的是它存在的意義。我更傾向於採用MantaRay在Flash中所反對的那種模型，通過中心伺服器進行轉發，可以存放離線消息以及解除耦合。更何況，企業應用中很少有類似MantaRay演示DEMO中出現的那種網路拓撲圖，並不是任何兩個節點之間都是互聯互通的。當然，如果MantaRay能夠做一些改進，先嘗試採用點對點模型，如果點對點失敗，這時將消息發送到中心伺服器上（但這一切必須對用戶透明），我會比較贊成，既具有傳統優勢，又能提高消息發送接收速度。
至於上篇文章中提到的運行其自帶的示例出現了問題，這次在Flash演示中終於找到了答案。看來MantaRay真應該提高其示常式序的易用性，這么復雜的操作，要是不看Flash演示，還真難想到該這樣操作：（
ActiveMQ是讓我感到驚訝的一個項目，上次對它的評價似乎有失偏頗。 ActiveMQ支持多種網路拓撲模型，既可以採用傳統JMS的Client-Server模型，也可以採用MantaRay的P2P模型，還可以僅僅支持同一JVM內的JMS應用。持久化機制一如既往的優秀，默認採用Apache Derby資料庫持久化，也可以配置為各種主流資料庫來持久。目前也提供了一簡單的JNDI實現，對於JMS應用而言，這已經夠用了。
但是其缺點也同樣明顯，本身不提供管理工具；示例代碼非常少；雖然主頁上的文檔看上去比較全面，但是一來缺乏一種有效的組織方式（文檔凌亂，用戶很難由淺入深進行了解，提高了門檻），二來文檔整體的專業性太強（不了解ActiveMQ？看文檔去吧，可是文檔是寫給了解ActiveMQ的用戶看的……），對於普通用戶而言，門檻有點高。
而且感覺ActiveMQ有點不安於JMS的本份，開始做一些周邊應用了，看其主頁就可以看出來，多了很多比較流行的詞彙。說不上這是優點還是缺點，但就我的角度而言，我更希望其專注於做好它的JMS。
JORAM在這段期間推出了4.3.x的版本，也是我們在應用中所採用的版本，我的評價和上次相比沒有什麼大的變化。主頁上說其速度有了提高，但我們應用中JMS數據量相對較少，沒有感覺出來。稍微遺憾的是在我們試用的過程中，從4.2.3升級到4.3，老版本的持久化消息都無法在新版本上識別出來，只能全部清空。在兼容性上，看來JORAM還得多下功夫。總而言之，我們在應用中採用JORAM，感覺就是波瀾不驚，沒碰到什麼大問題，也沒有什麼驚喜。
㈥ jms 是 java 消息隊列的標准，activemq 是具體實現，還是不太懂
jms 是java規定的系統應用之間的一種數據交換標准；
jdbc 是java規定系統應用與關系型資料庫系統之間的一套標准；
activemq 是對jms標準的一種實現；
好比於 mysql 驅動對 jdbc的標準的一種實現；
㈦ Java消息服務的JMS介面描述
JMS 支持兩種消息類型 PTP 和 Pub/Sub，分別稱作：PTP Domain 和 Pub/Sub Domain，這兩種介面都繼承統一的 JMS Parent 介面，JMS 主要介面如下所示：
JMS Parent PTPDomain Pub/Sub Domain
ConnectionFactory QueueConnectionFactory TopicConnectionFactory
Connection QueueConnection TopicConnection
Destination Queue Topic
Session QueueSession TopicSession
MessageProcer QueueSender TopicPublisher
MessageConsumer QueueReceiver,QueueBrowser TopicSubscriber
以下是對這些介面的簡單描述：
ConnectionFactory：連接工廠，JMS 用它創建連接；
Connection：JMS 客戶端到 JMS Provider 的連接；
Destination：消息的目的地；
Session：一個發送或接收消息的線程；
MessageProcer：由 Session 對象創建的用來發送消息的對象；
MessageConsumer：由 Session 對象創建的用來接收消息的對象。
㈧ java jms qm中的一些簡稱
你好，我也一直在用jms做東西，我給你系統地解釋一下吧
MDP：是message-driven bean的縮寫，也就是一個消息驅動的bean
QU：是Queue Usual，普通隊列的意思
Mbf：是Master Business Functions的縮寫，就是一個主業務函數
親，有任何問題可以繼續追問，請記得及時採納哦！
㈨ 『什麼是JMS（Java消息服務）』面試題目
JMS(Java Message Service)是訪問消息系統的標准API,它便於消息系統中的Java應用程序進行消息交換,並且通過提供標準的產生、發送、接收消息的介面簡化應用的開發。
JMS應用由以下幾部分組成：
JMS provider ：是一個消息系統，它實現了JMS 介面並提供管理和控制的功能。
JMS clients ：是用Java語言寫的一些程序和組件，它們產生和使用消息。
Messages ：是在JMS clients之間傳遞的消息的對象。
Administered objects ：是由使用JMS clients 的人生成的預選設置好的JMS 對象。有兩種這樣的對象：destinations和connection factories。
2.JMS基本功能
JMS是用於和面向消息的中間件相互通信的應用程序介面。它既支持點對點(point-to-point)的域，又支持發布/訂閱 (publish/subscribe)類型的域，並且提供對下列類型的支持：經認可的消息傳遞,事務型消息的傳遞，一致性消息和具有持久性的訂閱者支 持。JMS還提供了另一種方式來對您的應用與舊的後台系統相集成。
㈩ jms是什麼意思
Java Message Service的簡稱。
讀音：英 [ˈdʒɑːvə ˈmesɪdʒ ˈsɜːvɪs] 美 [ˈdʒɑvə ˈmesɪdʒ ˈsɜːrvɪs]
釋義：消息服務，使用Java消息服務。
語法：JMS即Java消息服務（Java Message Service）應用程序介面，是一個Java平台中關於面向消息中間件（MOM）的API，用於在兩個應用程序之間，或分布式系統中發送消息，進行非同步通信。Java消息服務是一個與具體平台無關的API，絕大多數MOM提供商都對JMS提供支持。
例句：
sts.
您已經成功地使用JMS協議和SOAP請求通信了。
(10)jmsjava擴展閱讀
JMS定義了五種不同的消息正文格式，以及調用的消息類型，允許你發送並接收以一些不同形式的數據，提供現有消息格式的一些級別的兼容性。
1、StreamMessage -- Java原始值的數據流
2、MapMessage--一套名稱-值對
3、TextMessage--一個字元串對象
4、ObjectMessage--一個序列化的 Java對象
5、BytesMessage--一個未解釋位元組的數據流