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應用系統的實現原理及采用的要害技術。
JMS應用系統有4個部分:①JMS提供者(JMS PRovider),是一個邏輯數據存儲體,并提供治理工具和控制特性;②JMS客戶端,是用Java語言編寫的發送或接收消息的組件或應用;③消息,是JMS客戶端間被傳遞的承載信息的對象;④被治理對象,是系統治理員為客戶端預置的JMS對象,包括目的地對象和連接工廠對象,其中目的地對象是客戶端間的消息中介。這4個部分通過JNDI相關聯:治理員通過治理工具把目的地對象和連接工廠對象綁定到一個JNDI API命名空間中,JMS客戶端就可以在命名空間中查找這些對象,并通過JMS提供者建立與這些對象的邏輯連接,從而彼此之間實現通信(圖1)。JMS支持2種消息傳遞域:點到點、發布/訂閱,與之相對應的消息目的地對象也有2種:隊列、主題。
通常,無論是消息發送方還是接收方,桌面應用都不容許消息丟失或重復,JMS消息提交機制是基于這個要求的,它們從不同方面保證該要求的實現:①在接收方控制消息的確認。通過確認保證一個接收者對一個消息只消費一次,在非事務性的會話中,消息確認方式取決于create×××session方法第二個參數的值;在事務性會話中,無論由Bean治理事務還是由Bean容器治理事務,消息確認都由Bean容器自動完成。②在發送方指定消息的提交模式和生存期。提交模式有兩種:PERSISTENT(穩定存儲)和NON_PERSISTENT(非穩定存儲),穩定存儲保證在故障情況下消息不會丟失;生存期決定一個消息在存儲中介中的存在壽命,JMS提供者會自動摧毀到期的消息。③創建持久定閱的接收方。在發布/訂閱系統中,持久訂閱者可以接收到在訂閱者關閉階段消息發送方發布的消息。
但是Web應用系統在消息接收方有Web特有的用戶環境要求:①若干個用戶共用一個JMS客戶端組件,因此消息就應向一個消息接收者提交而不需確認,具有容器自動確認功能的Bean是無法實現這一要求的;在一個組件內假如把會話設置成事務性的,而這個組件的容器又不具有事務治理能力,則這個組件就能做到"接收而不確認",在Web應用系統中只有Servlet組件符合這一要求。②JMS客戶端的消息接收者經常關閉,為了接收在關閉期間發送來的消息,消息接收者必定是基于主題的持久定閱者,所以面向Web的JMS應用系統必定采用發布/訂閱消息傳遞域。
CWNF是一個面向Web的JMS校務系統,用于校園發布通知及征求意見等校務工作,通知分為2類:普通通知和征求意見性通知。
該系統用戶分成3類,用戶不同,處理模型也不同,基本情況如下:①發布用戶,擁有通知發布權,向主題發布通知;②署名用戶,查閱通知,也可發表對征求意見性通知的反饋意見;③匿名用戶,只查閱通知。
系統中的數據因此有2類:通知、反饋。接收方接收的數據將形成一個xml文檔對象,以便發往Web瀏覽器顯示;基于這樣的要求,考察下面2個問題:①系統中各方之間的數據關系,②各方數據的形式。
主要的數據關系有3個:①通知發送方與通知接收方的數據關系,②反饋發送方與反饋接收方的數據關系,③通知接收方與反饋接收方的數據關系。(如圖2)在發送方,數據(通知或反饋)是一件一件的發送,在接收方,數據(通知或反饋)則是批接收,是對應發送方數據的集合,因此在發送方沒有必要把數據直接加工成XML文檔對象形式,只要生成能構成XML文檔對象的元素對象即可;而通知接收方與反饋接收方的數據關系則是:每一條征求意見性通知都有相關的一個反饋集合。
新聞熱點
疑難解答