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