作者：朱騏
作者簡介
朱騏，男，江蘇南京人，講師，主要研究方向：信息系統與集成技術。您可以通過qizhu003@msn.com和作者取得聯系。
內容摘要
JMS面向Web的應用與面向桌面的應用相比，有特殊的用戶環境要求：同一個消息必須能被若干未知的用戶消費，因此在消息接收方必須有"接收而不確認"的提交機制；本文以CWNF校務系統為實現案例，討論面向Web的JMS應用系統消息提交原理及采用的關鍵技術。
消息傳遞是一種在軟件組件或應用之間進行分布式通信的松散耦合方法，與各種緊密耦合通信技術（如CORBA、Java
RMI、COM/DCOM）相比，不同之處在于：①消息系統是一種對等實施，通信雙方即消息的發送者和接受者都是該系統中的客戶端，彼此不呈C/S關系；
②通信雙方的工作是異步的；③基于消息格式一致，通信雙方只需一個中介來存儲并管理消息就可以實現通信，而緊密耦合技術則需要知道遠程方法在本地的接口。
因自身特點，消息傳遞技術在企業中和企業間有較廣泛的應用需求。
JMS（Java Message
Service）是J2EE企業平臺的Java消息服務，目前主流J2EE產品的JMS都實現了存儲功能，JMS客戶端通過JMS
API創建，彼此間通過目的地（Destination）對象進行通信；可是JMS消息系統多見于桌面應用，而Web應用鮮見，本文以筆者開發的CWNF
校務系統為案例，討論面向Web的JMS應用系統的實現原理及采用的關鍵技術。
1 面向Web的JMS應用系統實現原理
1.1 JMS應用系統消息傳遞原理
JMS應用系統有4個部分：①JMS提供者（JMS
Provider），是一個邏輯數據存儲體，并提供管理工具和控制特性；②JMS客戶端，是用Java語言編寫的發送或接收消息的組件或應用；③消息，是
JMS客戶端間被傳遞的承載信息的對象；④被管理對象，是系統管理員為客戶端預置的JMS對象，包括目的地對象和連接工廠對象，其中目的地對象是客戶端間
的消息中介。這4個部分通過JNDI相關聯：管理員通過管理工具把目的地對象和連接工廠對象綁定到一個JNDI
API命名空間中，JMS客戶端就可以在命名空間中查找這些對象，并通過JMS提供者建立與這些對象的邏輯連接，從而彼此之間實現通信（圖1）。JMS支
持2種消息傳遞域：點到點、發布/訂閱，與之相對應的消息目的地對象也有2種：隊列、主題。
1.2 Web應用的消息提交機制
通常，無論是消息發送方還是接收方，桌面應用都不容許消息丟失或重復，JMS消息提交機制是基于這個要求的，它們從不同方面保證該要求的實現：①在
接收方控制消息的確認。通過確認保證一個接收者對一個消息只消費一次，在非事務性的會話中，消息確認方式取決于create×××Session方法第二
個參數的值；在事務性會話中，無論由Bean管理事務還是由Bean容器管理事務，消息確認都由Bean容器自動完成。②在發送方指定消息的提交模式和生
存期。提交模式有兩種：PERSISTENT(穩定存儲)和NON_PERSISTENT(非穩定存儲)，穩定存儲保證在故障情況下消息不會丟失；生存期
決定一個消息在存儲中介中的存在壽命，JMS提供者會自動摧毀到期的消息。③創建持久定閱的接收方。在發布/訂閱系統中，持久訂閱者可以接收到在訂閱者關
閉階段消息發送方發布的消息。
但是Web應用系統在消息接收方有Web特有的用戶環境要求：①若干個用戶共用一個JMS客戶端組件，因此消息就應向一個消息接收者提交而不需確
認，具有容器自動確認功能的Bean是無法實現這一要求的；在一個組件內如果把會話設置成事務性的，而這個組件的容器又不具有事務管理能力，則這個組件就
能做到"接收而不確認"，在Web應用系統中只有Servlet組件符合這一要求。②JMS客戶端的消息接收者經常關閉，為了接收在關閉期間發送來的消
息，消息接收者必定是基于主題的持久定閱者，所以面向Web的JMS應用系統必定采用發布/訂閱消息傳遞域。
2 CWNF校務系統模型
CWNF是一個面向Web的JMS校務系統，用于校園發布通知及征求意見等校務工作，通知分為2類：普通通知和征求意見性通知。
該系統用戶分成3類，用戶不同，處理模型也不同，基本情況如下：①發布用戶，擁有通知發布權，向主題發布通知；②署名用戶，查閱通知，也可發表對征求意見性通知的反饋意見；③匿名用戶，只查閱通知。
2.1 數據與數據流模型
系統中的數據因此有2類：通知、反饋。接收方接收的數據將形成一個XML文檔對象，以便發往Web瀏覽器顯示；基于這樣的要求，考察下面2個問題：①系統中各方之間的數據關系，②各方數據的形式。
主要的數據關系有3個：①通知發送方與通知接收方的數據關系，②反饋發送方與反饋接收方的數據關系，③通知接收方與反饋接收方的數據關系。（如圖
2）在發送方，數據（通知或反饋）是一件一件的發送，在接收方，數據（通知或反饋）則是批接收，是對應發送方數據的集合，因此在發送方沒有必要把數據直接
加工成XML文檔對象形式，只要生成能構成XML文檔對象的元素對象即可；而通知接收方與反饋接收方的數據關系則是：每一條征求意見性通知都有相關的一個
反饋集合。
系統的數據流模型如下：
①通知發送方：表單數據→XML元素（通知）→主題(存儲)
②通知接收方：主題(存儲)→XML元素（通知）→XML文檔（通知）→XSL顯示（含表單）
③通知接收方到反饋接收方: XSL顯示（含表單）→主題（存儲）
④反饋接收方：主題(存儲)→XML元素（反饋）→XML文檔（反饋）→XSL顯示（含表單）
⑤反饋發送方：表單數據→XML元素（反饋）→主題(存儲)
2.2 組件模型
系統組件模型如圖3：主題CWNFTopic是消息傳遞中介，NoticerServlet組件向發布用戶發送表單，并從表單接收數據，然后生成
XML元素對象，該元素對象和其它一些數據被作為參數調用PublisherBean組件方法，向主題發送以該元素對象為消息體的消息；
ReaderServlet組件處理署名用戶和匿名用戶查閱通知的業務，它從表單獲得用戶將查閱什么方面通知的有關信息后，便使用receive方法限時
阻塞地從主題接收消息并對消息進行篩選，把篩選出的若干消息的消息體取出，然后加工成XML文檔對象（根元素是通知集），最后輸出。
FeedbackerPubServlet用于反饋發送方的業務處理，功能與NoticerServlet相似；
FeedbackerSubServlet用于反饋接收方的業務處理，功能與ReaderServlet相似；PublisherBean組件被
NoticerServlet組件和FeedbackerPubServlet組件調用，用于發送消息，容器管理發送事務，具有很高的可靠性。
3 關鍵的實現技術
3.1 JDOM建立、輸出XML文檔
JDOM是一個開放源代碼的純Java樹式API，用于分析、建立、處理和序列化XML文檔。在數據流模型中，XML元素和XML文檔都由JDOM
API建立，在發送方，通過用戶提交的表單取得名/值對若干，這些數據經過JDOM方法處理生成XML元素對象，元素對象被作為消息的消息體發往主題存
儲；在接收方，持久訂閱者接收到若干XML元素對象后，繼續通過JDOM方法建立XML文檔對象。且XML文檔向Web瀏覽器輸出也依賴于JDOM的
XMLOutputte對象方法：
XMLOutputter serializer=new XMLOutputter();
PrintWriter out=response.getWriter(); // out 是ServletResponse的輸出流對象
serializer.output(xmldoc,out); //通過out把XML文檔輸出到頁面
3.2 XSL定義XML文檔顯示樣式
XSL是可擴展的樣式單語言，通知集的XML文檔和反饋集的XML文檔都有相關的XSL文檔決定其頁面顯示，如通知集XML文檔的XSL樣式定義如下：
<?xml version="1.0" encoding="GBK"?>
<xsl:stylesheet>
<xsl:template match="/">
<HTML>
<BODY>
<DIV><xsl:apply-templates select="通知集"/></DIV>
</BODY>
</HTML>
</xsl:template>
<xsl:template match="通知集">
<xsl:for-each select="通知">
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
3.3 Servlet間數據的傳遞
3.3.1 注冊/登錄
用戶的一些處理工作需要注冊/登錄后才能進行，因此注冊/登錄的獲準信息必須能在有關Servlet組件之間傳遞。ServletContext 對象可設置和讀取屬性，使不同Servlet之間相互通信，在系統中被用于有關組件對用戶身份的驗證。
3.3.2 通知與反饋的數據關聯
每一條征求意見性通知都有一個相關聯的反饋集合，關聯可通過設置消息屬性實現。JMS消息（包括通知類消息）都有系統級JMSMessageID屬
性，其值是唯一的，可用于表征每一條征求意見性通知，因此對任何反饋消息也可以設置一個應用級屬性（CWNF中是FeedbackSN），讓它取與之相關
聯的征求意見性通知的JMSMessageID屬性值。這樣就建立了兩者間的數據關聯。
因此數據流模型"③通知接收方到反饋接收方:
XSL顯示（含表單）→主題（存儲）"的實現流程如下：用戶在頁面上選擇一條征求意見性通知后，該通知的JMSMessageID屬性值將被傳遞給
FeedbackerSubServlet組件，該組件將使用這個屬性值去匹配從主題取出的反饋消息的FeedbackSN屬性，從而篩選出相關聯的反饋
消息。
那么一條征求意見性通知的JMSMessageID屬性值又如何傳遞給FeedbackerSubServlet組件呢？通過
ServletContext對象只能傳遞可預知信息，CWNF的做法是：由XSL為每一條征求意見性通知設置一個獨立的表單，并把該通知的
JMSMessageID屬性值寫在表單的TEXTAREA元素框內，這樣用戶在表單上選擇一條征求意見性通知后，該通知的JMSMessageID屬性
值就隨表單一起提交給FeedbackerSubServlet組件。XSL有關代碼如下：
<xsl:if test="string(意見反饋)='on'">
<FORM method="post" action="http://localhost:6888/Feedbacker/servlet
/FeedbackerSubServlet">
<BUTTON type="submit">意見反饋</BUTTON>
<TEXTAREA name="序列號" rows="1" cols="40">
<xsl:value-of select="序列號"/>
</TEXTAREA>
</FORM>
</xsl:if>
4 結束語
JMS應用系統與數據庫系統有相似性，從數據方面看，JMS消息體的數據類型支持文本和對象，所以JMS更靈活，與XML集成應用的空間更大；但從
管理上看，JMS
Provider向管理員提供的管理功能遠遠低于DBMS提供的管理功能，因此在面向Web的應用中，JMS宜作為中小流量、管理員參與度較低的信息系統
解決方案。
轉載自：http://gceclub.sun.com.cn/yuanchuang/2004_Q4/jms.html