對于Java消息服務中常見問題的解答

2019-11-18 13:07:35

字體：大中小

來源：轉載

供稿：網友

　　問. 什么是 java 消息服務？
　　
　　答: Java 消息服務(Java Message Service，JMS) API 是一個用于訪問企業消息傳遞系統的 API。是 Java 2 Platform, EnterPRise（J2EE）的一部分。
　　
　　Java 消息服務使得編寫那些需要異步發送及接收重要業務數據和事件的業務應用變得輕易。Java 消息服務定義了一個公共的企業消息傳遞 API，該 API 設計來被大范圍的企業消息傳遞產品輕易而有效地支持。Java 消息服務不僅支持消息隊列，還支持消息傳遞的發布/訂閱模式。
　　
　　問. Java 消息服務是另一種郵件 API 嗎？
　　
　　答: 不是。術語“消息傳遞”在計算機領域的定義很廣。它被用來描述不同的操作系統概念，用于描述電子郵件和傳真系統；假如使用了 JMS API，它被用來描述企業應用之間的異步通信。
　　
　　JMS 消息是指由企業應用（而不是人）消費的異步請求、報告或事件。它們包含了協同這些系統所需的重要信息，包含了描述特定業務活動的精確格式化的數據。通過這些消息的交換，每個應用可以跟蹤企業的進展。
　　
　　問. Java 消息服務是一種產品嗎？
　　
　　答: 不是，Java 消息服務是一個用于企業消息傳遞的公共 API 的規范,使用它需要一個由企業消息傳遞供給商提供的 JMS 提供者。
　　
　　問. 可從哪里獲得 Java 消息服務規范？
　　
　　答: Java 消息服務 1.0.2 規范可從 http://java.sun.com/prodUCts/jms/docs.Html 處獲得。在線的 JMS API 文檔也可在這個鏈接地址中找到。
　　
　　問. Java 消息服務有何引人注目的？
　　
　　答: Java 消息服務引人注目的原因是：它是第一個得到廣泛行業支持的企業消息傳遞 API。通過提供適應廣泛企業消息傳遞系統的標準消息傳遞概念和約定，它簡化了企業應用的開發。它利用現有的，經過企業驗證的消息傳遞系統。
　　
　　問. 開發人員為何應該使用 Java 消息服務？
　　
　　答: 因為 Java 消息服務能使下面的工作變得簡單：編寫可移植的，基于消息的業務應用。通過加入新的能夠與現有非 JMS 客戶端完全協作的 JMS 客戶端，以擴展現有的基于消息的應用。
　　
　　問. 為了學習使用 Java 消息服務，程序員需要具備什么？
　　
　　答: 基于消息的應用和基于遠程過程調用的應用是根本不同的。一旦開發人員理解了如何最好地使用這兩個技術, JMS API 就使得編寫基于消息的應用跟學習幾個附加接口一樣輕易。
　　
　　問. Java 消息服務和企業 JavaBeans 組件有何關系？
　　
　　答: 自從 J2EE 1.2 版本發布以來，企業 JavaBeans 組件已經能夠使用 JMS API 來同步地發送和接收企業消息。J2EE 1.3 版本現在已可獲得，它提供了一種新的答應企業應用異步地接收消息的企業 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 客戶端在應用服務器（比如 J2EE 服務器）中運行時，這些服務應該被自動處理；可是, 也有可能需要 JMS 客戶端去明確編寫它們。
　　
　　問. 在哪里可以找到 JMS API 討論組？
　　
　　在 http://java.sun.com/j2ee/community/forums/index.html 處可找到一個 JMS API 論壇。要加入這個論壇，您必須是 Java Developer Connection 的成員。
　　
　　問. 為什么 JMS API 發展成為一種在企業內部組件間提供通信的技術，而不是用于在企業間通過 Internet 進行企業－企業（B2B）的通信？
　　
　　答: 提供基于 Internet 的 JMS API 消息傳遞的主要問題是，JMS API 供給商們必須使用一種共同的通信格式，并且 JMS 規范必須指定一個路由器－路由器 API。
　　
　　B2B 消息傳遞是一個重要的領域，有它自己獨特的要求。該領域正被一些不斷涌現的標準所占據，比如電子商務 xml計劃，即 ebXML (參見 http://www.ebxml.org/),SUN 公司在這一方面起到了積極的作用?，F在，ebXML 計劃定義了一個消息傳遞服務，它支持通過Internet 的 XML 消息傳遞。
　　
　　當前的 ebXML 規范著重于，通過使用多種傳輸協議，比如 HTTP、mail 和 FTP，通過 Internet 提供終端間的點到點異步通信。ebXML 還計劃提供發布/訂閱式的 XML 消息傳遞。Sun 公司和它的合作伙伴正在定義一個新的 Java API for Messaging，即 JAXM (參見 JSR #000067, Java APIs for XML Messaging 1.0), 它支持 ebXML 消息服務規范。早先版本的 JAXM 可以從 Java Developer Connection 的 The M Project 1.0 Early access 處得到。
　　
　　總之, JMS API 是特意設計為在企業內部使用的，而獨立企業之間通過 Internet 進行的 XML 消息傳遞將得到 ebXML 計劃和新的支持不同 ebXML 規范的 Java API（包括 JAXM）的支持。
　　
　　技術問題
　　
　　問. JMS API 需要哪一種 JDK 版本？
　　
　　答: JMS API 需要 JDK/JRE 1.1.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 不提供訂閱通知？假如發布者

上一篇：TOMCAT 3.1的安裝與配置簡要介紹

下一篇：JACOB配置方法及兩個常見錯誤解決