JMS 1.1 通過統一的域簡化了消息傳遞

2019-11-18 12:28:52

字體：大中小

來源：轉載

供稿：網友

　　JMS 構成了企業 java 應用程序中消息傳遞的基礎，但它一直以來都將點對點消息傳遞和發布／訂閱消息傳遞當作完全獨立的域來對待，這兩種域的消息傳遞目標的類型截然不同。JMS 1.0.2 API 對同時使用這兩種域的應用程序只提供很有限的支持，對開發與這兩種域的目標能一起工作得同樣好的可重用框架則不提供任何支持。JMS 1.1 統一了這兩種域，從而克服了這一缺點。請與 J2EE 設計師和編寫者 Bobby Woolf 一道，他將帶您探討使用 JMS 的最新版來開發 JMS 客戶機代碼是多么輕易。
　　　Java 消息服務（Java Message Service，JMS）API 是 J2EE 平臺的構成元素。JMS 1.0.2 定義了兩種類型的消息傳遞域（它們是相互獨立的），即點對點和發布／訂閱。JMS 的最新版本，即版本 1.1，將成為 J2EE 1.4 的一部分，EJB 2.1 也將會需要它，JMS 統一了這兩個域。有了 JMS 1.1，客戶機就不再必須專門針對這個或那個域進行實現了。相反，JMS 客戶機可以實現為能與來自任一域的目標一起工作。這極大地簡化了 JMS API，并為開發者創建更通用、重用性更好的消息傳遞代碼提供了機會。一旦有實現 JMS 1.1 的 JMS 提供程序和 J2EE 容器可供使用，JMS 客戶機代碼的開發者就應該可以開始在他們的新代碼中使用版本 1.1 的 API，并且也可以從將他們現有的 JMS 1.0.2 代碼移植到新的 API 中受益。
　　
　　我們將直接進入對新規范的討論，所以，假如您要溫習一下 JMS，請參閱 JMS 快捷介紹。
　　
　　三組接口
　　在 JMS 1.0.2 中，三個通道接口 — Destination、Queue 和 Topic — 不幸地造成了 API 中的接口數量增加到三倍的后果。為了發送或接收消息，客戶機使用連接生成器來獲得一個連接，客戶機用這個連接來創建會話并獲得所期望的隊列和主題上的消息生產者和消費者。唯一的問題是每種目標都有它自己的生成器、連接、會話、生產者和消費者接口（基本上，就是它自己的接口域），表 1（出自 JMS Javadocs）總結了這一情況。
　　
　　表 1. 點對點和發布／訂閱接口的關系
　　
　　JMS 公共 PTP 域 Pub/Sub 域
　　ConnectionFactory QueueConnectionFactory TopicConnectionFactory
　　Connection QueueConnection TopicConnection
　　Destination Queue Topic
　　session QueueSession TopicSession
　　MessagePRodUCer QueueSender TopicPublisher
　　MessageConsumer QueueReceiver TopicSubscriber
　　
　　此外，為了與 XA（分布式）事務兼容，JMS 還提供了另一組接口。這意味著除了上表所示的 18 個接口之外，JMS 還有另外九個接口 — 生成器、連接和會話類型的 XA 版本 — 類型的數量達實際所需的三倍之多。
　　
　　JMS 1.1 的業界支持
　　Java 2 平臺，企業版（Java 2 Platform，Enterprise Edition）的下一個主要發行版（J2EE 1.4；目前處于公共草案狀態）將包含 JMS 1.1，所以諸如 IBM WebSphere 和 BEA WebLogic 之類的 J2EE 容器（應用程序服務器）將需要實現 JMS 1.1，從而才能被認證為與 J2EE 1.4 兼容。類似的，Enterprise JavaBeans 規范的下一個版本（EJB 2.1；目前也處于公共草案狀態）將需要 JMS 1.1，以支持其 JMS 消息驅動的 bean。而且 J2EE 1.4 將包含 EJB 2.1，因此這些規范和 JMS 1.1 將融合到一起。
　　
　　有許多產品都實現了 JMS 1.0.2，但支持 JMS 1.1 或打算支持 JMS 1.1 的情況如何呢？
　　
　　目前有兩個以盈利為目的的消息傳遞系統（AshnaMQ 2.1 和 Sun ONE Message Queue，Platform Edition 3.0）和一個開放源代碼的消息傳遞系統（JORAM 3.1.0）實現了 JMS 1.1，但沒有任何其它 JMS/J2EE 供給商，包括 IBM、BEA Systems、TIBCO Software 和 Sonic Software 已經公布打算在它們產品的未來發行版中支持 JMS 1.1。鑒于目前都支持 JMS 1.0.2 或 J2EE 1.2 或 1.3，提供對 JMS 1.1 的支持看來只是一個時間問題。
　　
　　在上述 27 個接口中，只有六個公共接口（在第一列中的那些）是發送和接收消息所真正需要的。Queue 和 Topic 有時對于區別點對點方式和發布／訂閱方式而言很有用。表中的其它十個接口和九個 XA 接口中的至少六個實際上是不需要的，至少對于編寫客戶機代碼來說是不需要的。
　　
　　舉例來說，使用 JMS 1.0.2，假如開發者要訪問一個 Queue，他將使用 QueueConnectionFactory 來獲取一個 QueueConnection，以創建一個 QueueSession，這個 QueueSession 用來創建一個 QueueSender 或 QueueReceiver。但這樣的代碼是特定于隊列的，將不能與 Topic 一起工作。這種辦法在 JMS 1.1 中也行得通，但直接使用 ConnectionFactory、Connection、Session 和 MessageProducer 或 MessageConsumer，會簡單些，這后一種辦法能與 Topic 和 Queue 一起工作。因此，開發者應使用公共接口并避免使用特定于域的接口，因為公共接口使得代碼更簡單、更通用，重用性也更好。
　　
　　非統一接口
　　在 JMS 1.0.2 中，客戶機代碼必須使用特定于域的隊列和主題接口。公共接口在很大程度上僅僅是一個形式，并不聲明客戶機所需要的許多方法。例如：Destination 壓根不實現任何方法；MessageProducer 不實現 send 方法；MessageConsumer 的確實現 receive，但 Session 客戶機無法創建 MessageConsumer；如此等等。
　　
　　這樣，對于一個要發送和接收 Queue 中的消息的客戶機，它必須使用表 1 的第二列中的類，而使用 Topic 的類似客戶機則必須使用表 1 的第三列中的類來實現很相似的代碼。公共接口中缺乏這種多態性使得不可能通過主題重用隊列客戶機，反過來重用也不可能，這導致了如清單 1 所示的那種重復性代碼。
　　
　　域統一化
　　JMS 1.1 中的主要變化是添加了新的 API，以支持能同時與點對點或發布／訂閱域一起工作的客戶機代碼。最新的發行版在公共接口中添加了一些方法，從而使主題和主題擴展具有多態性。
　　
　　例如，MessageProducer 如今實現了 send，所以，客戶機可以給目標發送消息而不必知悉該目標是一個隊列還是一個主題。類似地，MessageConsumer 聲明了 receive 方法，所以，相同的客戶機代碼不論是使用隊列接收程序還是主題訂閱程序都能工作。
　　
　　清單 2 顯示了如何使用這個統一接口獲取生產者和消費者。清單 1 所示的 JMS 1.0.2 代碼需要四個方法（一對用于隊列，另一對用于主題），而 JMS 1.1 代碼則只需要兩個方法（一對用于目標）。
　　
　　這些新的 API 使得開發者能夠編寫重用性好得多的 JMS 客戶機代碼。JMS 客戶機代碼只是訪問并使用目標而無須知道哪些目標是隊列，哪些目標是主題。被編寫用來訪問隊列的代碼還可以不加修改就以相同方式被重用來訪問主題，反之亦然。這對于 JMS 1.0.2 來說是不可能的。
　　
　　因為公共接口現在幾乎能夠執行它們的特定于域的擴展所能做的所有相同任務（例如，MessageProducer 幾乎可以做 QueueSender 和 TopicPublisher 能做的所有任務），所以，特定于域的子接口實際上已不再需要。這些接口在 JMS 的未來版本中很可能會被去掉。
　　
　　共享事務
　　將消息傳遞域統一起來的微妙但重要的結果是，隊列和主題現在可以通過同一個會話（從而在同一個事務中）進行訪問。在 JMS 1.0.2 中，QueueSession 可以訪問不止一個 Queue，TopicSession 可以訪問多個 Topic，但單個會話不能既訪問隊列又訪問主題。因為會話治理著事務，所以單個事務不能既用來控制隊列，又用來控制主題。
　　
　　在 JMS 1.1 中，不但單個 Session 可以訪問 Queue 或 Topic（任一類型的 Destination），而且單個會話實例可以用來操縱一個或多個隊列以及一個或多個主題，一切都在單個事務中進行。這意味著單個會話可以（例如）創建隊列和主題中的生產者，然后使用單個事務來同時發送隊列和主題中的消息。因為單個事務跨越兩個目標，所以，要么隊列和主題的消息都得到發送，要么都未得到發送。類似地，單個事務可以用來接收隊列中的消息并將消息發送到主題上，反過來也可以，如清單 3 所示。
　　
　　考慮一個客戶跟蹤應用程序，它給要使用客戶信息的其它應用程序（其中之一是送貨應用程序）提供信息。跟蹤應用程序可能需要告知其它應用程序某個特定客戶的地址已經變更。假如使用消息傳遞，則該應用程序將把這項變更發布到主題 CustomerChanges 上，所有要使用客戶信息的應用程序將訂閱這個主題。客戶跟蹤應用程序可能要求每個訂閱者回報該訂閱者是否能夠成功處理該項變更?？蛻舾檻贸绦驅⒅付ㄒ粋€隊列 ChangeProcessed，每個訂閱者應用程序將使用這個隊列來發送應答。
　　
　　訂閱者應用程序，如發貨應用程序將接收 CustomerChanges 主題上的變更消息，處理這個消息，然后發送一個應答到 CustomerChanges 隊列上。為了確保沒有任何變更被丟失，這三個步驟（接收請求、處理請求和發送應答）應該在單個原子事務中進行。這意味著發貨應用程序必須使用同一個會話來訪問 CustomerChanges 主題和 ChangeProcessed 隊列。在 JMS 1.0.2 中，會話不能既訪問主題又訪問隊列，但在 JMS 1.1 中則可以這樣做。
　　
　　結束語
　　JMS 1.0.2 受害于子類型的爆炸式增長；因為對于每一個類型，都有該類型本身的一個接口、一個隊列擴展和一個主題擴展。三倍的接口意味著開發者要學習三倍的 API?？蛻魴C代碼必須使用這個域或那個域，要么使用隊列那組擴展，要么使用主題那組擴展，所以針對一個而編寫的代碼不能用于另一個。
　　
　　JMS 1.1 統一了域，從而每個公共接口可以用來取代其特定于域的擴展。這意味著開發者要學習的接口更少了，并且同樣的客戶機代碼既可以用于隊列，又可以用于主題。此外，JMS 事務現在可以更輕易地跨越主題和隊列，這在域被統一起來之前是不可能的。

上一篇：使用JSF（Java Server Faces）開發(三)

下一篇：solaris上開發J2EE應用中文問題的解決