問
什麼是 Java 消息服務？
答: Java 消息服務(Java Message Service
JMS) API 是一個用於訪問企業消息傳遞系統的 API
是 Java
Platform
Enterprise（J
EE）的一部分
Java 消息服務使得編寫那些需要異步發送及接收重要業務數據和事件的業務應用變得容易
Java 消息服務定義了一個公共的企業消息傳遞 API
該 API 設計來被大范圍的企業消息傳遞產品容易而有效地支持
Java 消息服務不僅支持消息隊列
還支持消息傳遞的發布/訂閱模式
問
Java 消息服務是另一種郵件 API 嗎？
答: 不是
術語
消息傳遞
在計算機領域的定義很廣
它被用來描述不同的操作系統概念
用於描述電子郵件和傳真系統
如果使用了 JMS API
它被用來描述企業應用之間的異步通信
JMS 消息是指由企業應用（而不是人）消費的異步請求
報告或事件
它們包含了協同這些系統所需的重要信息
包含了描述特定業務活動的精確格式化的數據
通過這些消息的交換
每個應用可以跟蹤企業的進展
問
Java 消息服務是一種產品嗎？
答: 不是
Java 消息服務是一個用於企業消息傳遞的公共 API 的規范
使用它需要一個由企業消息傳遞供應商提供的 JMS 提供者
問
可從哪裡獲得 Java 消息服務規范？
答: Java 消息服務
規范可從 處獲得
在線的 JMS API 文檔也可在這個鏈接地址中找到
問
Java 消息服務有何引人注目的？
答: Java 消息服務引人注目的原因是
它是第一個得到廣泛行業支持的企業消息傳遞 API
通過提供適應廣泛企業消息傳遞系統的標准消息傳遞概念和約定
它簡化了企業應用的開發
它利用現有的
經過企業驗證的消息傳遞系統
問
開發人員為何應該使用 Java 消息服務？
答: 因為 Java 消息服務能使下面的工作變得簡單
編寫可移植的
基於消息的業務應用
通過加入新的能夠與現有非 JMS 客戶端完全協作的 JMS 客戶端
以擴展現有的基於消息的應用
問
為了學習使用 Java 消息服務
程序員需要具備什麼？
答: 基於消息的應用和基於遠程過程調用的應用是根本不同的
一旦開發人員理解了如何最好地使用這兩個技術
JMS API 就使得編寫基於消息的應用跟學習幾個附加接口一樣容易
問
Java 消息服務和企業 JavaBeans 組件有何關系？
答: 自從 J
EE
版本發布以來
企業 JavaBeans 組件已經能夠使用 JMS API 來同步地發送和接收企業消息
J
EE
版本現在已可獲得
它提供了一種新的允許企業應用異步地接收消息的企業 Bean
即消息驅動 Bean
問
Java 消息服務 API 與 Java 命名和目錄接口(JNDI) API 之間有何關系?
答: 跟其他 Java 企業 API 一樣
JMS API 使用 JNDI API 來進行管理
JMS API 將 ConnectionFactories 和 Destinations 定義為被管理對象
它們被配置並放入到 JNDI 命名的上下文中
然後 JMS 客戶端查找和使用這些預先配置好的對象
這樣保證了 JMS 應用易於部署和管理
問
Java 消息服務 API 與 Java 數據庫連接（JDBC）API 之間有何關系？
答: JMS 客戶端或許也使用 JDBC API
在同一個事務中它們可能既使用 JMS API 也使用 JDBC API
大多數情況下
通過把這些客戶端實現為企業 Bean
JMS 客戶端可自動完成
JMS 客戶端可能也使用 Java 事務 API
問
Java 消息服務與 Java 事務 API 及 Java 事務服務之間有何關系？
答: Java 事務 API (Java Transaction API
JTA) 提供了一個用於劃分分布式事務的客戶端 API
以及一個用於訪問資源以能夠參與分布式事務的 API
JMS 客戶端可能使用 JTA 來劃分分布式事務
JMS 提供者通過 JTA 可以自如地支持分布式事務
Java 事務服務 (Java Transaction Service
JTS) 能和JMS API一道用來形成分布式的事務
該事務結合了消息收發與數據庫更新以及其他 JTS 能識別的服務
當 JMS 客戶端在應用服務器（比如 J
EE 服務器）中運行時
這些服務應該被自動處理
可是
也有可能需要 JMS 客戶端去明確編寫它們
問
在哪裡可以找到 JMS API 討論組？
在 處可找到一個 JMS API 論壇
要加入這個論壇
您必須是 Java Developer Connection 的成員
問
為什麼 JMS API 發展成為一種在企業內部組件間提供通信的技術
而不是用於在企業間通過 Internet 進行企業－企業（B
B）的通信？
答: 提供基於 Internet 的 JMS API 消息傳遞的主要問題是
JMS API 供應商們必須使用一種共同的通信格式
並且 JMS 規范必須指定一個路由器－路由器 API
B
B 消息傳遞是一個重要的領域
有它自己獨特的要求
該領域正被一些不斷湧現的標准所占據
比如電子商務 XML計劃
即 ebXML (參見 )
SUN 公司在這一方面起到了積極的作用
現在
ebXML 計劃定義了一個消息傳遞服務
它支持通過Internet 的 XML 消息傳遞
當前的 ebXML 規范著重於
通過使用多種傳輸協議
比如 HTTP
mail 和 FTP
通過 Internet 提供終端間的點到點異步通信
ebXML 還計劃提供發布/訂閱式的 XML 消息傳遞
Sun 公司和它的合作伙伴正在定義一個新的 Java API for Messaging
即 JAXM (參見 JSR #
Java APIs for XML Messaging
)
它支持 ebXML 消息服務規范
早先版本的 JAXM 可以從 Java Developer Connection 的 The M Project
Early Access 處得到
總之
JMS API 是特意設計為在企業內部使用的
而獨立企業之間通過 Internet 進行的 XML 消息傳遞將得到 ebXML 計劃和新的支持不同 ebXML 規范的 Java API（包括 JAXM）的支持
技術問題
問
JMS API 需要哪一種 JDK 版本？
答: JMS API 需要 JDK/JRE
x 或者更高的版本
問
JMS API 是否提供了一個分布式 Java 事件模型的版本？
答: 一般來講
JMS API 可以被用作通知服務
但是
它沒有定義 Java 事件的分布式版本
一個實現分布式 Java 事件的可選方案是作為 JavaBeans 組件
該組件通過 JMS API 透明地向事件產生 Bean 和事件監聽 Bean 分布事件
問
為什麼有兩個各自分開的 JMS API 域
即點到點和發布/訂閱
而不合為一個域呢？
答: 即使有許多類似之處
提供獨立的域仍然很重要
這意味著廠商不必被強迫支持不屬於他們的域內的設備
客戶端代碼也更加輕便靈活
因為產品更充分地支持一個域（相對於支持一個合並域中較少定義的子集而言）
問
為什麼 JMS API 不指定一套 JavaBeans 組件？
答: JMS API 是一個低級的 API
就像其他低級的 Java API 一樣
它無助於直接表現為 JavaBeans 組件
問
JMS API 如何與 CORBA 通知服務相結合？
答: 通知服務為 CORBA 事件服務增加了過濾功能
傳輸保證語義
持久性連接和事件網絡的集結
它從 CORBA 消息服務（該服務定義了異步 CORBA 方法調用）獲得傳輸保證語義
Java 技術與 CORBA 很好的結合在一起
它提供了 Java IDL 和 COS Naming 技術
另外
OMG 最近定義了 RMI over IIOP
預計大多數 Java 對 IIOP 的使用將通過 RMI
預計大多數 Java 對 COS Naming 的使用將通過 JNDI API（Java 命名和目錄服務）
JMS API 是 Java 特定的 API
它設計位於大范圍現有和未來的面向消息中間件（Message Oriented Middleware
MOM）系統的上層（正如 JNDI API位於現有命名和目錄服務的上層一樣）
問
為什麼 JMS API 不提供端到端的同步消息傳輸和傳輸通知?
答: 作為一個實現可靠應用的機制
一些消息傳遞系統提供到目的地的同步傳輸
一些系統為客戶端提供了不同形式的傳輸通知
這樣客戶端就能檢測出被刪除或忽略的消息
這不是由 JMS API 定義的模型
JMS API 消息傳遞通過一次並且只有一次的 PERSISTENT 消息傳輸語義來提供有保障的傳輸
另外
消息消費者可以通過使用 CLIENT_ACKNOWLEDGE 模式或事務會話來確保可靠的消息處理
這樣使用最小的同步實現了可靠的傳輸
這是大多數廠商和開發者都喜歡的企業消息傳遞模型
JMS API 沒有定義系統消息（如傳輸通知）的模式
如果應用需要消息收到的確認回復
可以定義一個應用級的確認消息
這些問題放到發布/訂閱應用的上下文中考察
將能更清楚地理解
在這個上下文中
同步傳輸和/或系統接收確認對於實現可靠的應用並不是一個有效的機制（因為
按照定義
生產者不會
也不想負責端到端的消息傳輸）
問
為什麼 JMS API 不提供群體發送(send
to
list)機制？
答: 當前
JMS API 提供大量的消息傳送選擇
但是
消息在同一時刻只能發送到一個目的地
群體發送的好處是
程序員只需做很少的工作
並且還有 JMS 提供者對發送同樣的消息到多個目的地的情況進行優化的潛力
群體發送機制不利的方面是
目的列表在效果上是由客戶端實現並維護的集合
這將增加 JMS 客戶端管理的復雜度
不使用提供群體發送機制的 JMS API
而推薦提供者支持配置代表一個群體的目的
這允許客戶端通過一次發送便可以到達所有的消費者
同時保證群體被正確地管理
問
為什麼 JMS API 不提供訂閱通知？如果發布者
From:http://tw.wingwit.com/Article/program/Java/JSP/201311/19688.html
