作者：朱騏
作者簡介
朱騏，男，江蘇南京人，講師，主要研究方向：信息系統與集成技術。您可以通過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種：隊列、主題。
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樣式定義如下：
...
...
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有關代碼如下：
4 結束語
JMS應用系統與資料庫系統有相似性，從數據方面看，JMS消息體的數據類型支持文本和對象，所以JMS更靈活，與XML集成應用的空間更大；但從管理上看，JMS Provider向管理員提供的管理功能遠遠低於DBMS提供的管理功能，因此在面向Web的應用中，JMS宜作為中小流量、管理員參與度較低的信息系統解決方案。
CWNF校務系統經校園網實驗性運行，效果良好，驗證了面向Web的JMS應用是可行的。
