自從WebLogic 9.0發佈以來，很多人都這樣說：“給我3個升級到WebLogic 9.0的理由先。”由於WebLogic 9.0具有非常豐富的特性，且又是性能驅動的，因此我們能很容易地給出10個主要理由。
理由之 10 ：增強的 Web 服務和進入黃金時期的 SOA 架構
WebLogic 9.0交付了完整且全面集成的Web服務堆棧。BEA在Web服務領域的一些重要技術方面佔據了領先的地位，像基於註釋的Web服務編程和會話Web服務等。Web服務服從所有的基本J2EE規範和大多數的重要WS-*規範。對於異步、會話式、可靠且安全的Web服務的支持也得到了增強。
簡而言之，在新增的Web服務方面，用戶可以獲得：
- 下一代Web服務編程模型
- 會話式Web服務的性能提升
- 更靈活、安全和可靠的異步Web服務
- 對長期運行的異步可靠消息交換的支持
- 降低了複雜性
- 藉助於JSR-181基於JWS的Web服務而實現的最新型基於標準的編程模型
- 簡化的Web服務編寫
理由之 9 ： JMS -- WebLogic 9 中值得驕傲的增強
WebLogic Server 9.0在WebLogic JMS的配置、部署和動態管理方面引入了重要的改進。它對JMS 1.1規範提供官方支持。此外，在系統中添加了人們期待已久的消息排序高級特性。XML API的XML消息處理功能得到了增強。在WebLogic 9.0平臺上使用JMS非常輕鬆有趣、可靠且迅速。下面是現有新特性中的一些亮點。
自動化的 JMS 故障恢復
自動化的JMS故障恢復是業內期待已久的特性。JMS利用“Automatic WebLogic Server Migration”特性來提供自動化的JMS故障恢復。在整個WebLogic Server實例進行故障恢復時，JMS也將自動從故障中恢復過來。儘管其他的一些JMS服務器提供商已經利用一些複雜裝置提供了這樣的功能，但WebLogic 9.0的實現是最直觀而清晰的。
排序單元
消息排序是大多數消息處理應用程序的一項基本要求。WebLogic Server JMS即使在集羣環境中也能確保消息的順序處理。它甚至可以定義多個組來將消息分組，這樣每個組都擁有自己的處理順序（如圖1所示）。
存儲轉發 (SAF)
WebLogic存儲轉發(store and forward, SAF)服務使WebLogic Server能在通過WebLogic Server實例部署的應用程序間可靠地交付信息。SAF的強大功能使得我們可以很容易地將多個消息服務鏈接在一起（如圖2所示）。
理由之 8 ： 並行部署 -- 美夢成真
每個J2EE開發人員都經歷過發佈產品新版本的痛苦。經過無數開發週期和QA週期後，最後發現已經到了在應用服務器上部署新版本的時候。預定在一個週末關閉服務器，換上產品新版本，然後祈禱週一不會出問題。如果足夠幸運，只會出現一些小問題。然而如果不夠幸運的話，就不得不重新使用以前的應用程序，這甚至比部署新版本更痛苦，因爲有時並不能恢復所有的改動（如圖3所示）。
我們希望可以在應用服務器上使用多個版本，並且能在不中斷系統的情況下在版本之間進行切換。
現在我們的夢想成真了。並行應用程序部署能在無需中斷服務的情況下，控制基於Web的應用程序新版本的部署過程。應用程序的新版本與現有版本部署在一起 -- WebLogic將逐步移植交互。舊版本在當前所有客戶端完成工作之後解除部署。管理員顯式解除舊版本的部署，或者會達到配置好的超時。
回滾新版本很簡單：如果在新的應用程序版本中檢測出問題，只需停止重新部署過程即可。
對於新應用程序來說，管理員能以“管理模式”部署應用程序，這種模式對於非管理客戶端來說是不可訪問的，其目的是進行健全性檢查，以確保應用程序按照預期狀況正常運行，然後纔對客戶端開放。
以下是WebLogic 9並行部署方面的特性列表：
- 多個應用程序版本可以共存
- 在向用戶開放前測試版本
- 回滾以前的版本
- 自動引退：流暢、超時、即時
- 創建可識別版本的應用程序工件/資源
- 降低硬件、軟件、維護和支持成本
JSR-88是J2EE 1.4規範的一部分，JSR-88指定了一個標準API，用於J2EE應用程序的配置和部署。WebLogic 9不但實現了JSR-88，而且在J2EE的規定之外還提供了很多附加值。
理由之 7 ： WebLogic 診斷框架：降低 總擁有成本
WebLogic診斷框架(WebLogic Diagnostics Framework,WLDF)旨在通過顯著的診斷增強來降低客戶的總擁有成本(Total Cost of Ownership,TCO)。WLDF串連了所有的BEA WebLogic Server 9.0容器，從而創建了一個對數據集合進行有序控制的統一框架，這對於企業應用程序的良好運行是非常重要的。這個框架將跟蹤並存檔有意義的診斷數據，這些數據可用於監視和診斷運行中的服務器所出現的問題。WLDF是一個統一框架和公共API，因此可以輕易地把應用程序嵌入到框架中，以利用服務器的診斷功能。
WLDF由很多組件構成，這些組件協作起來收集、存檔並訪問有關其宿主服務器和應用程序的診斷信息。所有的框架組件都運行在服務器級別，並只識別服務器範圍。除Manager之外的所有組件一概都存在於服務器進程中，並參與到標準服務器生命週期中。框架的所有工件都在每個服務器的基礎上進行配置和保存。WLDF Manager提供了一個配置和控制界面，用於管理診斷框架。除此之外，WLDF Image Capture實用工具提供了一個模型，用於捕捉關鍵服務器狀態的診斷快照。它提供了一種侵入性最低的服務器診斷和故障排除方法。
以下是WLDF的特性列表：
- 引入了一個統一的診斷框架，該框架爲後續的BEA增強提供了藍本
- 提高了WLS和堆棧產品的總體可視化效果，以減少監視和診斷中的盲點
- 改進了對（診斷專家可用的）診斷數據的數量和質量的控制和實時可調性
- 引入了附加的診斷工具，以幫助理解和解決系統故障
- 提供了定義更清晰的界面和工具，用於幫助對客戶應用程序進行診斷
- 可跨WL平臺使用
- 有助於不依賴於支持團隊地發佈客戶工具補丁
- 應用程序和WLS類的工具
- 監視和通知功能，用於觸發警報
- 請求着色（跨JVM）：用於事件重建和關聯的診斷上下文
- 細粒度控制 -- 將容量調高或調低
- 藉助於控制檯擴展實現數據可視化：https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=s96
- 藉助於JMX而實現的編程式訪問
理由之 6 ：基於門戶的可擴展管理控制檯：可擴展控制檯！
WebLogic 9.0管理控制檯提供了一個完全經過重新設計的用戶界面，該界面是標準化的，並且其所有子系統都改善了外觀和導航體驗。它是構建在WebLogic Portal Framework之上的。儘管使用門戶放慢了管理控制檯的啓動過程，但也使其更加開放和易於擴展 -- 如果需要的話，應用程序能將擴展嵌入到控制檯。
其中的新特性包括：
- 改進的導航和用戶界面設計。
- 新增的用於控制域配置修改的“修改中心”。使用控制檯，管理員可以將修改“批處理”到WebLogic Server配置，從而可以進行可預料且可靠的修改。在管理員的命令下，一批中所有的配置修改被跨域分佈，並被應用到所有的服務器；如果有任何服務器不能接受這些配置，就將在整個域中進行回滾！然後它們就保持爲掛起狀態，等待來自管理員的進一步操作。
- 新增的應用程序部署和配置工具，包括對應用程序安裝、包含更多配置的界面以及用於生產應用程序的新部署和重新部署控件等的支持。附加的控制檯更新使用戶可以更輕鬆地在部署導出應用程序時爲部屬計劃變量賦值。
- WebLogic診斷服務，它具有很多在運行時環境下進行配置、收集和查看診斷信息的新特性。可以通過控制檯訪問此服務。參見包含更多可視性和運行時控件的集中式診斷服務（如圖4所示）。
- 管理控制檯如今能以類似於通常擴展門戶應用程序的方法進行擴展。除了添加和替換內容外，控制檯擴展還可以嚮導航樹添加節點並修改控制檯的外觀元素，例如顏色或商標圖片等（如圖5所示）。
通過管理控制檯，用戶能執行以下操作：
- 配置、啓動和關閉WebLogic Server實例
- 配置WebLogic Server集羣
- 配置WebLogic Server服務，例如數據庫連通性(JDBC)和消息處理(JMS)
- 配置安全性參數，包括管理用戶、組和角色等
- 配置和部署應用程序
- 監視服務器和應用程序性能
- 查看服務器和域日誌文件
- 查看應用程序部署部署描述符
- 編輯選中的運行時應用程序部署描述符元素
理由之 5 ：新的零宕機時間架構：城域網 / 廣域網集羣？
WebLogic 9.0通過引入城域網 / 廣域網（MAN/WAN）集羣，進一步擴展了零宕機時間的概念。它提供了增強的HTTP會話複製功能，這就使得在通過廣域網或城域網連接的WebLogic Server集羣中進行“災難恢復”成爲可能。
城域網中的 HTTP 會話複製
應用程序能將HTTP會話副本的備份配置到另一個WebLogic Server集羣中。一旦主WebLogic Server集羣不可用，HTTP客戶端就能轉到輔助WebLogic Server集羣（如圖6所示）。
此特性假設兩個WebLogic Server集羣間可以進行高速連接，並嚴重依賴於全局和局部負載平衡器的正確配置。
城域網中的 HTTP 會話複製
這對於災難恢復中心（DR站點）來說十分理想。應用程序能將HTTP會話副本的另一個備份配置到另一個WebLogic Server集羣中。WebLogic Server會異步將HTTP會話數據發送到另一個備份（可能保存在數據庫中）。一旦主WebLogic Server集羣不可用，HTTP客戶端能夠轉到輔助WebLogic Server集羣（如圖7所示）。
假設到另一個備份的複製是異步的，故障恢復的HTTP客戶端可能遇到過時的數據。此特性也同樣嚴重依賴於全局和局部負載並衡器的正確配置。
理由之 4 ：整體服務器的遷移：確保集羣化服務器的故障恢復
在集羣環境中如何使用單個的服務並確保故障恢復，這在J2EE領域中始終是一個難題。現在這個難題被解決了。
BEA WebLogic 9提供了對整體服務器進行遷移的特性。它支持集羣的服務器實例從一臺機器到另一臺機器的自動和手動遷移。能被遷移的託管服務器被稱爲可遷移服務器。此特性專爲需要高可用性的環境而設計。單個服務可裝載於一臺服務器上，並可能由於故障而被遷移。可遷移服務器提供了服務器級別而不是服務級別的自動和手動遷移。服務器遷移功能可用於：
- 在宿主服務器實例發生故障時，確保單個服務的連續可用性，在任何給定時間中，單個服務必須只運行在單個服務器上，例如JMS和JTA事務處理恢復系統。在發生故障時，爲自動遷移配置的託管服務器將被自動遷移爲另一臺機器（如圖8所示）。
- 簡化重定位託管服務器及其駐留的所有服務的過程，將其作爲計劃中的系統管理過程的一部分。管理員能從管理控制檯或命令行初始化託管服務器的遷移。
- 服務器遷移過程將徹底重定位託管服務器，包括將IP地址和駐留的應用程序重定位到一組預先定義的可用主機上。
理由之 3 ： WebLogic 腳本編寫工具 (WLST) ：管理員的福音！
WebLogic 9提供了令人印象深刻的基於標準的命令行管理工具(Jython)，還提供了強大的功能，例如：
- 對域（包括用戶創建的以及非WebLogic Server MBean）配置的導航和編輯
- 獲得有關域的運行時信息
- 執行各種管理任務，比如部署應用程序、通過節點管理器啓動/停止服務器等
WLST不贊成WebLogic 9中的weblogic.Admin，儘管它完全支持後者。
理由之 2 ： Work Manager 和線程自我調優：執行隊列在哪裏？
所有資深J2EE開發人員都在某種程度上進行過性能調整。在WebLogic Server的前一個版本中，處理在多個執行隊列中執行。不同種類的工作根據優先級以及排序和避免死鎖的要求在不同的隊列中執行。用戶不得不通過改變執行隊列中線程的數量來控制線程使用。而現在執行隊列的概念已經被Work Manger取代了。WebLogic 9.0實現了Work Manager 1.1規範，在一個線程池中執行所有類型的工作。WebLogic Server根據用戶定義的規則和運行時指標（包括執行請求的實際時間以及請求進入和離開線程池的比率等）對工作劃分優先級，這將提供更大的吞吐量和更快的響應速度。Work Manager API能使應用程序將單個請求任務分爲多個工作項，並使用多個在WebLogic Server中配置的Work Manager指派這些工作項同時執行。應用程序能配置調度指導原則（例如，模型A應該獲得70%的CPU時間，如果線程擁擠，模型B可被關閉），這樣WebLogic Server就能利用這些指導原則和所收集的實際運行時性能數據來安排應用程序的CPU資源。應用程序不必再爲指定的組件配置單獨的線程池了，因爲可以利用WebLogic Serve來監視、調整並分配這些資源。
WebLogic Server中重要的自我調優特性包括：
- 工作負載管理 -- 管理員能定義調度策略並在域、應用程序和模塊級別上加以約束。
- 自動線程計數調整 -- 線程池能根據吞吐量歷史和隊列大小自動修改其大小，從而使吞吐量最大化。
- 線程調度功能 -- WebLogic Server 9.0實現了通用的Work Manager API，將線程調度功能向開發人員公開。應用程序也能使用Work Manager API來異步執行工作，並能在執行時接收通知。
在這裏我們要重點強調一個非常好的特性，即過載保護。BEA一直努力做到想客戶之所想，過載保護就是這種努力的一個傑出代表。WebLogic 9.0在這方面提供了兩種類型的保護。
類型 1 ：得體的降級 -- 過載保護
- 基於低內存和隊列容量閾值的工作拒絕（如表1所示）
- 以非臨界開銷維護的臨界系統
- 在過載時拒絕而不是降級
類型 2 ：得體的故障 -- 如果其它的一切都出現故障，那麼就關閉服務器
- 出現致命故障（如死鎖）時的關閉/掛起服務器選項，OOME
- 用於腳本編寫的定義良好的現有代碼
- 指定阻塞線程動作的能力
理由之 1 ：性能
無疑，性能永遠都是購買決心、遷移和升級的第一驅動力。
SPECjAppServer2004是評估J2EE應用服務器的基準。BEA WebLogic 9.0獲得了SpecjAppServer2004在J2EE領域中的最佳性能結果。那麼WebLogic 8.1又如何呢？ -- WebLogic 9.0是否比WebLogic 8.1及以前的版本更快呢？
BEA創建了服務器性能指數(Server Performance Index，SPI)來比較每個WLS版本。與道瓊斯指數類似，WLS的SPI性能是參考了大量有代表性的性能基準（包括微基準和應用程序基準），然後計算這些基準的幾何平均數而得出的。測試後的內部數據顯示，WLS 9.0比WLS 8.1 SP4快17%。同樣，藉助於WebLogic 9支持新硬件、操作系統和數據庫系統的新增能力，有可能獲得更高的性能。顯然，WebLogic 9會使用戶在現階段獲得很大的收益，而且BEA永遠不會停止實現更高性能的努力。
結束語
由於WebLogic 9.0具有諸多新特性，遷移到此WebLogic Server版本的理由也就顯而易見了，您還等什麼？快行動吧！別忘了，無論何時，只要您需要，都會獲得BEA的專業服務和技術支持，現在您還有什麼理由不升級呢？