WebLogic Server 9.0：JMS增強功能(圖)

2019-11-18 12:24:29

字體：大中小

來源：轉載

供稿：網友

　　BEA WebLogic Server 9.0新增了大量java Message Service（JMS）功能和增強。可分為兩大類：針對治理員的更改，比如JMS資源、新增的存儲和轉發功能以及全新的持久性存儲子系統；針對開發人員的更改，比如JMS 1.1支持、Unit-of-Order增強以及消息驅動bean方面的改進。本文從專業的角度介紹了對任何要移植到WebLogic Server 9.0的開發團隊都會產生影響的要害性更改。
　　
　　針對治理員的JMS更改
　　
　　針對治理員的更改主要有4個。第一個與JMS資源的配置和部署方式有關。第二個是目的地治理，包括人們期待已久的查看隊列或主題內容的功能。第三個是新增的存儲-轉發功能。最后是整個JMS子系統的基礎——WebLogic Persistent Store。
　　
　　JMS資源的模塊化配置
　　
　　在WebLogic Server 9.0出現之前，像隊列和主題這樣的JMS資源只能連接到特定的JMS服務器上。即便在控制臺中也是這樣：控制臺中的隊列和主題都被視為單個JMS服務器的分支。JMS資源是由WebLogic治理員在應用程序部署之前創建的。這在WebLogic Server 9.0中有了根本改變。
　　
　　JMS資源現在是作為可部署資源創建的。根據weblogic-jmsmd.xsd模式定義，它們位于分離的xml文件中。這些資源可與應用程序一起配置，也可單獨配置。
　　
　　JMS資源可被創建為系統模塊（也稱為環境相關）或應用程序模塊。應用程序模塊的治理方式與標準J2EE模塊類似，并且可以像其他J2EE應用程序一樣部署為獨立模塊，或者作為J2EE應用程序的一部分。系統模塊與應用程序模塊的主要區別就是其所有者。系統資源模塊由WebLogic治理員擁有并進行修改，可供所有應用程序使用。應用程序資源模塊由WebLogic開發人員擁有并進行修改，開發人員將JMS資源模塊打包到應用程序的EAR文件中。
　　
　　可使用WebLogic控制臺或WebLogic Scripting Tool（WLST）治理系統模塊。每個資源由兩部分構成：
　　
　　第一個文件是config/config.xml配置文件，其中給出了資源的定義。
　　
　　第二個XML文件位于域主目錄下的config/jms目錄中，其中包含JMS資源的具體信息。
　　
　　通過示例可以更好地理解這些內容。我創建了一個名為MikesTestModule的系統模塊。其中包含兩個實體：名為MIKES_TEST_QUEUE的隊列及名為MIKES_TEST_TOPIC的主題。下面的代碼片斷描述了域的config/config.xml文件中的系統模塊：
　　
　　<jms-system-resource>
　　<name>MikesTestModule</name>
　　<target>AdminServer</target>
　　<sub-deployment>
　　<name>MIKES_TEST_QUEUE</name>
　　<target>MyJMSServer</target>
　　</sub-deployment>
　　<sub-deployment>
　　<name>MIKES_TEST_TOPIC</name>
　　<target>MyJMSServer</target>
　　</sub-deployment>
　　<descriptor-file-name>jms/MikesTestModule-jms.xml
　　</descriptor-file-name>
　　</jms-system-resource>
　　
　　請注重元素<descriptor-file-name/>。它引用了包含各個JMS實體的具體信息的文件。引用的config/jms/MikesTestModule-jms.xml文件如下所示：
　　
　　<weblogic-jms xmlns="http://www.bea.com/ns/weblogic/90">
　　<queue name="MIKES_TEST_QUEUE">
　　<message-logging-params>
　　<message-logging-enabled>true</message-logging-enabled>
　　<message-logging-format>%headers%,%PRoperties%
　　</message-logging-format>
　　</message-logging-params>
　　<jndi-name>mike.test.queue</jndi-name>
　　</queue>
　　<topic name="MIKES_TEST_TOPIC">
　　<jndi-name>mike.test.topic</jndi-name>
　　</topic>
　　</weblogic-jms>
　　
　　通過創建一個遵循weblogic-jmsmd.xsd模式（與上例中config/jms/MikesTestModule-jms.xml文件的模式相同）的XML文件，即可配置應用程序模塊。根據說明文檔中的論述，應用程序模塊必須包含在應用程序EAR文件中，并在weblogic-application.xml文件中進行引用。部署了包含JMS應用程序模塊的EAR文件之后，為資源定義持久性存儲就是治理員的任務了。
　　
　　對系統模塊和應用程序模塊的選擇取決于IT團隊的經驗。在需要與其他消息傳遞產品交互的環境中，采用系統模塊部署通常最為適合，而僅在內部使用WebLogic JMS隊列或主題的應用程序則更適合采用應用程序模塊。
　　
　　系統模塊和應用程序模塊都是由以下實體中的一項或多項組成的：
　　
　　JMS隊列和JMS分布式隊列
　　JMS主題和分布式主題
　　配額
　　模板
　　連接工廠
　　外部服務器
　　目的地要害字
　　存儲-轉發導入的目的地
　　遠程存儲-轉發上下文
　　存儲-轉發錯誤處理
　　
　　然后，模塊中的各實體將一個現有的JMS服務器作為目標。有些實體（如：連接工廠）也可以以WebLogic服務器或集群為目標。
　　
　　圖1展示了顯示MikesTestModule示例模塊的治理員控制臺，該模塊有兩個實體，均以名為MyJMSServer的JMS服務器為目標。
　　　 WebLogic Server 9.0：JMS增強功能(圖)（圖一）

　　圖1. 顯示模塊實體
　　
　　將可部署的JMS資源與WebLogic 8中的配置進行比較，其優勢清楚可見：
　　
　　治理員或部署人員將應用程序及其全部資源從一個環境移植到另一個環境時更為輕松。需要的手動配置更少，當資源是應用程序模塊時更是如此。
　　
　　資源與資源配置的分離使應用程序需求分得更清楚（如：一個隊列，或者隊列的配置方式）。
　　
　　假如應用程序在內部（此時消息不以其他應用程序為目標）使用了一些隊列，應用程序模塊就顯得尤為便利了；這些模塊可為治理員和部署人員節省大量時間。例如，根據構建過程中所生成的wlw-manifest.xml文件的定義，基于BEA WebLogic Workshop的Web應用程序需要至少兩個JMS隊列才能正常工作。使用可部署資源時，這些隊列將隨應用程序一起部署，因此部署人員不會再忘記創建它們了。
　　
　　在部署開始之前——而不是部署過程中，即可檢查各個文件的模式。任何曾經修改config.xml文件卻因括號放置位置不當而使服務器在啟動時就悲慘地發生故障的人都會對此深有體會。
　　
　　總體來說，定義JMS資源的新方法最終將使治理員和部署人員的工作更為輕松。
　　
　　治理JMS目的地
　　
　　BEA WebLogic Server 9.0引入了一個控制臺應用程序，它答應JMS治理員查看目的地內容，并創建新消息或刪除執行中的消息。這項特性本身就足以使您升級到WebLogic Server 9.0！圖2展示了示例隊列中執行中的消息。
　　　 WebLogic Server 9.0：JMS增強功能(圖)（圖二）

　　圖2. 在JMS目的地中查看消息
　　
　　如圖2所示，隊列的內容現在是可治理的。您可以創建新消息（本例中已實現了這一功能）、導入或導出消息、刪除單個消息或者刪除整個隊列。這項功能需要在產品環境中謹慎地構建安全性后才能使用，但它簡化了應用程序的開發與測試。
　　
　　最后，您還可以查看各個消息的頭部和內容。圖3所示為圖2中第二條消息的顯示結果。
　　　 WebLogic Server 9.0：JMS增強功能(圖)（圖三）

　　圖3. 查看消息具體信息
　　
　　這里有兩個細節應該注重。首先，JMS目的地可以暫停。任何曾經碰到過消息循環問題（消息驅動bean（MDB）獲取消息、拋出異常、回滾消息、下一個MDB獲取消息……如此反復）的用戶都會喜歡上這一功能。治理員現在可以暫停目的地，查看出問題的消息，然后采取恰當的措施。您可以將JMS目的地暫停為以下的一種或幾種狀態：
　　
　　為生產而暫停：任何生產者嘗試發送已提交的消息時都會導致異常。
　　
　　為插入而暫停：禁止使用任何執行中的消息（如事務中的消息）和完全提交的消息。任何包含在執行中事務中的消息都不會出現在隊列中，雖然答應事務成功完成。在隊列恢復之前，消息不可用。
　　
　　為消費而暫停：任何消費者都不會接收到消息。假如指定了超時設置，那么在消費恢復之前，所有同步接收者都會超時或阻塞。所有MDB也會暫停。答應所有執行中的事務都正常完成。
　　
　　這幾種暫停狀態均可在啟動時及運行時被激活。
　　
　　最后值得注重的就是改進的記錄功能。WebLogic Server 9.0中包含全新的WebLogic Diagnostic Service，JMS資源也可參與其中。可啟動或關閉對各個JMS實體的記錄，這使治理員擁有了細粒度控制權。默認情況下，日志保存在servers/<server_name>/logs/jmsServers/<jms_server_name>/jms.messages.log中，其中<server_name>表示WebLogic Server名稱，而<jms_server_name>表示JMS服務器的名稱。日志頭部可設置為包含某些或全部標準JMS頭部，還可包含任何定制的屬性。下面是一個日志片斷，它顯示了一個消息的生產和移除。
　　
　　####
　　<May 11, 2005 10:07:10 PM EDT>
　　<>
　　<>
　　<1115863630224>
　　<141490>
　　<ID:<225269.1115863629999.0>
　　> <test-message-6>
　　<MikesTestModule!MIKES_TEST_QUEUE>
　　<ProdUCed>
　　<weblogic>
　　<>
　　<
　　<?xml version="1.0" encoding="UTF-8"?>
　　<mes:WLJMSMessagexmlns:mes="http://www.bea.com/WLS/JMS/Message">
　　<mes:Header/>
　　</mes:WLJMSMessage>>
　　####
　　<May 11, 2005 10:08:07 PM EDT>
　　<>
　　<>
　　<1115863687830>
　　<202875> <ID:<225269.1115863629999.0>>
　　<test-message-6> <MikesTestModule!MIKES_TEST_QUEUE>
　　<Removed> <weblogic> <>
　　<<?xml version="1.0" encoding="UTF-8"?>
　　<mes:WLJMSMessage xmlns:mes="http://www.bea.com/WLS/JMS/Message">
　　<mes:Header/>
　　</mes:WLJMSMessage>>
　　
　　存儲-轉發
　　
　　WebLogic Server 9.0現在能將消息轉發到遠程WebLogic JMS服務器上，即便此時該服務器不可用。存儲-轉發（store-and-forward，SAF）服務看上去就像是經過大力改進的WebLogic Message Bridge。SAF與Message Bridge的區別表現在以下三個方面：
　　
　　與Message Bridge相比，SAF更快、更具可伸縮性，但非WebLogic版本或WebLogic Server 9.0之前版本的目的地依然支持Message Bridge。
　　
　　SAF支持下面介紹的Unit-of-Order特性。
　　
　　WebLogic Server 9.0使用SAF服務為Web Services Reliable Messaging（WSRM）提供可靠性。
　　
　　SAF機制由三個部分組成：
　　
　　源JMS目的地，JMS生產者將消息發送到這里。
　　
　　SAF發送和接收代理，處理服務器和集群之間的消息傳輸。SAF接收代理僅用于WSRM。
　　
　　JMS模塊，其中包含SAM導入的目的地、SAF遠程上下文以及SAF錯誤處理。遠程上下文包含遠程服務器的URL及安全憑證。導入的目的地是遠程目的地的本地表示。錯誤處理定義了發生錯誤時要采取的行動。
　　
　　圖4展示了SAF服務移動消息的方式。在本例中，JMS生產者將消息放置在一個本地JMS目的地（隊列或主題）中，并繼續其工作。消息會被轉發或為本地SAF發送代理所獲取。代理隨后將消息轉發給遠程SAF接收代理，假如它不可用，則消息將存儲在本地服務器上直到遠程系統恢復正常。假如本地服務器在SAF代理能夠轉發消息之前發生故障，則消息將一直持續到JMS服務器恢復正常。一旦消息抵達遠程導入的目的地，JMS消費者就可獲取消息。在整個WebLogic JNDI樹中，JMS目的地和導入的目的地都是可用的。
　　　 WebLogic Server 9.0：JMS增強功能(圖)（圖四）

　　圖4. 存儲-轉發消息流
　　
　　所有持久性消息都以Exactly-once的服務質量（QOS）交付，并確保有序。在一個Unit-of-Order中發送的非持久性消息以At-most-once的服務質量交付，假如發生故障，到達時可能會次序混亂。SAF隊列和主題可以以三種QOS水平之一進行定義：Exactly-once（僅發送一次）、At-least-once（至少發送一次）或At-most-once（最多發送一次）。
　　
　　SAF架構的要害之處在于JMS生產者和消費者均沒有任何指示SAF服務已包含的標志。
　　
　　WebLogic持久性存儲
　　
　　WebLcogic 9.0帶來了一個全新的統一持久性存儲子系統，在整個WebLogic服務器中，只要需要持久性，就會用到這一子系統。SAF代理、JMS服務器、可靠的Web服務、診斷服務和JTA日志都使用持久性存儲。
　　
　　每個WebLogic Server實例都帶有默認的文件存儲庫，位于data/store/default目錄下。任何需要持久性但未顯式配置持久性存儲庫的子系統都將使用默認存儲庫。多個子系統可使用同一存儲庫，只要它們均以同一服務器為目標即可。存儲庫既可基于文件，也可基于JDBC，惟一的例外就是默認存儲庫，它必須是文件存儲庫。
　　
　　擁有多個存儲庫以及答應多個應用程序訪問同一存儲庫的能力使治理員設計其WebLogic域時具有很大的靈活性。例如，一個存儲庫可能保存在高可用的基于SAN的磁盤上，而另外一個存儲庫則可能基于JDBC。前者性能較高，但必須手動進行故障轉移（假設為集群環境）。后者性能較低，但可支持自動化的故障轉移。治理員可以根據客戶需求，確定對于每個應用程序哪種存儲庫最適合。
　　
　　提升持久性存儲庫性能的一個訣竅就是利用存儲庫的事務支持。例如，假設同一事務內包含一個JMS服務器和一個EJB計時器。若JMS服務器和EJB計時器使用同一存儲庫，事務可為一階段的，只需寫入存儲庫一次。但假如它們各自使用了存儲庫，事務就是兩階段的，需要對每個存儲庫執行兩次寫操作，此外還要對事務日志執行一次寫操作，總共5次寫操作。這聽起來很讓人吃驚，對于每秒要處理大量事務的系統，這樣的差異對性能的影響是非常顯著的。
　　
　　針對開發人員的JMS更改
　　
　　BEA WebLogic Server 9.0為開發人員設計了一些非常有趣的新特性，包括對JMS 1.1的支持、Unit-of-Order功能、MDB增強和基于XML的消息傳遞。在使用WebLogic Server 9.0時應牢記，您無需為了使應用程序在WebLogic Server 9.0中運行而更改JMS代碼，除非您要使用新特性。
　　
　　JMS 1.1支持
　　
　　WebLogic 9完全支持JMS 1.1。根據Sun Microsystems的說明文檔，JMS 1.1促成了“PTP和Pub/Sub域編程接口的統一”。其結果就是您可以創建一個處理會話，然后在同一個事務中，從隊列中接收消息并將其發送到某個主題。這在JMS 1.0中是無法實現的。JMS 1.1的重要之處就在于它對JMS 1.0的向下兼容性。Unit-of-Order功能
　　
　　具有遺留系統的組織經常發現有些消息傳遞是依靠于順序的。過去（在J2EE出現之前）只有一個消息消費者時，順序不是問題，但出現了MDB和集群之后，這就成為人們面臨的一項巨大挑戰。WebLogic Server 9.0提供了Unit-of-Order功能，部分地解決了這一問題。這項功能尤其適用于來自同一生產者的一組信息必須順序處理的情況。
　　
　　例如，生產者A在一個Unit-of-Order中發送消息X、Y和Z。MDB獲取消息X并對其進行處理。消息Y和Z一直在隊列中，直到MDB實例提交事務為止。只有在MDB提交消息X之后，才可以處理消息Y，依此類推。
　　
　　Unit-of-Order有以下幾個局限性：
　　
　　Unit-of-Order不能對整個隊列操作，只能針對一組消息操作。
　　
　　Unit-of-Order是JMS的擴展，這意味著Unit-of-Order不能用于其他消息傳遞環境。
　　
　　有趣的是，Unit-of-Order功能可處理分布式隊列。同一個Unit-of-Order中的所有消息都將發送到同一個分布式目的地成員處。
　　
　　創建Unit-of-Order的方法有兩種，可通過編程創建，也可通過WebLogic控制臺創建。WebLogic提供了weblogic.jms.extensions.WLMessageProducer類，該類實現了avax.jms.MessageProducer接口。BEA添加了兩個方法：getUnitOfOrder()和setUnitOfOrder()。您可以使用這兩個方法來設置或獲取當前Unit-of-Order的名稱。WebLogic治理員可為會話（通過連接工廠）和目的地配置Unit-of-Order。通過setUnitOfOrder()方法可進行重寫。
　　
　　有關Unit-of-Order中的消息何時交付的規則是非常復雜的。黃金法則就是假如消息生產者關閉，則當前消息處理完成；假如一個事務提交了，則所有消息均已發送。每種消息確認模式都各不相同，說明文檔中對其進行了具體介紹。
　　
　　MDB增強
　　
　　WebLogic Server 9.0中的消息驅動bean（MDB）工具進行了重要的改進。一些增強尤為突出，排在前三位的增強處理的是消息循環問題——MDB容器試圖交付消息，交付失敗，消息回滾，容器重試……無限循環。
　　
　　第一個改進就是治理員可暫停MDB，而無需取消應用程序的部署，見本文前面“治理JMS目的地”一節。
　　
　　與第一個增強相關，在MDB拋出異常后，將消息處理自動暫停一段（可配置的）時間。
　　
　　當消息發生循環時，MDB容器禁止記錄每次異常。而是僅記錄一次，再記錄下異常發生的次數。
　　
　　現在可為MDB的每個實例創建獨有的client-id，從而幫助持久性訂閱者，而在WebLogic 8.1中是為MDB的每個類型創建client-id。
　　
　　J2EE 1.4規范規定，MDB可以從服從JCA 1.5的適配器接收消息。您可以在weblogic-ejb-jar.xml部署描述符中設置resource-adapter-jndi-name參數，從而利用此特性。
　　
　　在BEA網站中可找到MDB增強的完整列表。
　　
　　XML消息傳遞
　　
　　BEA在WebLogic Server 8.1中引入了一個XML消息類型擴展，并在WebLogic Server 9.0中對其進行了增強。weblogic.jms.extensions.XMLMessage實現了javax.jms.TextMessage接口，并公開了與org.w3c.dom.Document對象一起傳送的setDocument()和getDocument()方法。該擴展是很有價值的，但假如您接合的是非WebLogic系統，那么情況可能有所不同。結束語
　　
　　WebLogic Server 9.0中的新特性為數眾多，限于篇幅，不再一一介紹。這里介紹了一些要害的特性，包括改進的WebLogic控制臺、MDB增強和全新的存儲-轉發服務。希望讀完本文后，讀者可以大致了解WebLogic Server 9.0為應用程序和J2EE環境帶來的變化。

上一篇：封裝JNDI操作LDAP服務器的工具類(4)

下一篇：Myeclipse4.0 Tomcat5.0 j2sdk1.5搭建J2EE一