簡介：Apache CXF 與 Apache Axis2 及 Metro 共享一些底層組件，但在完全不同的架構中結合了這 些組合。Dennis Sosnoski 將繼續他的 Java Web 服務 專欄，比較 CXF、Metro 和 Axis2 棧在有無 WS -Security 的情況下的性能表現。
Apache CXF Web 服務棧建立在與本系列早期文章討論的 Apache Axis2 及 Metro 棧相同的一些技術 的基礎之上。與 Axis2 類似，它使用 Apache WSS4J WS-Security 實現。與 Metro 類似，它主要使用 JAX-WS 2.x Web 服務配置和 JAXB 2.x 數據綁定（甚至使用與 Metro 相同的 JAXB 實現，但兩個棧的版 本不同）。但是，除了這些公共組件之外，各棧之間的差異還包括它們的處理引擎和 WS-SecurityPolicy 配置處理。
本系列的早期文章比較了 Axis2 與 Metro 的性能，包括在不同 WS-Security 配置下的簡單消息交換 。在本文中，您將了解 CXF 與 Axis2 及 Metro 最新發行版之間的性能比較。
性能概述
與之前介紹 Web 服務性能的文章 — “WS-Security 的大開銷” 和 “比較 Metro 與 Axis2 性能” — 相同，本文將測量當客戶機與服務器在單一系統中運行時執行特 定請求序列所需的時間。這種方法將多次比較 Web 服務 處理 開銷，因為它可以消除網絡延時和計時造 成的開銷。假定客戶機代碼沒有明顯慢於服務器，因此這些數據可以表示實際服務器在高負荷下的性能。
本文還將使用與早期文章相同的測試應用程序，即一個地震數據檢索服務。該服務所使用的數據庫中 包含全球范圍多年以來內發生的超過 93,000 次地震的數據。服務請求將指定時間范圍和坐標范圍，而服 務將返回范圍內的所有地震。請參閱 “WS-Security 的大開銷”，了解關於測試應用程序和 示例請求/響應消息對的完整信息。
與之前的文章相同，我們將使用兩組請求序列來進行性能測試 。第一組使用 1,000 個請求，並調整查詢參數以匹配整個地震數據庫的小部分數據（在 1,000 個請求中 ，僅返回 816 個匹配的地震條目）。第二組使用 100 個請求，並通過調整使它匹配數據庫中的較大部分 內容（在 100 個請求中，返回 176,745 個匹配的地震條目）。這兩個請求序列強調了 Web 服務棧的不 同性能特性。第一個序列顯示了棧使用少量數據處理請求的速度，而第二個序列則強調了處理數據量的速 度。每個請求序列都使用不同的安全配置運行了多次，結果中僅記錄各配置表現最好的數據。
運 行測試的硬件和軟件條件是：Mandriva 2009.1 64 位 Linux 系統，Athlon X2 5400+ 處理器和 4GB 內 存，使用 Sun (Oracle) Java 1.6.0_18 32-bit JVM（對於特定的堆大小來說，它的性能稍微好於 64 位 ）。服務器代碼運行在 Tomcat 6.0.20 上，經配置將使用 1024MB 大小的堆，而客戶機代碼則使用 512MB 大小的堆。Web 服務棧版本如下：
CXF 2.1.7
Metro 2.0
Axis2 1.5.1，以及 Rampart 1.5 發行版
如果您希望嘗試 在自己的機器和 JVM 上進行測試，那麼請 下載代碼（http://www.ibm.com/developerworks/cn/java/j -jws14/index.html#download）。
無 WS-Security 的性能
圖 1 顯示了 Axis2、Metro 和 CXF 未使用任何 WS-Security 時的測試時間。從圖中可以看出，當請求較多而響應較少時，Metro 的速 度顯著快於 Axis2 和 CXF（大約快 25%）；而當請求較少，響應較多時，其速度與 Apache 棧相同。（ 在本文的所有圖中，較短的柱表示時間更短，速度更快，即性能越好。）
圖 1. 無安全框架時的 測試時間
這些結果顯示了一些 不同於 Metro 1.5 和 Axis2 1.5.1 之間的 早期比較 的有趣的差異。時間結果說明，至少對於測試應用 程序所使用的數據來說，Metro 2.0 在單位請求處理方面快於 Axis2 和 CXF。在與 XML 之間的數據轉換 方面，三個棧的運行速度基本相同。這是 Metro 和 CXF 的預期結果，因為它們都使用 JAXB 參考實現來 進行轉換。從這些結果中可以判斷， Axis2 所使用的默認 Axis2 Databinding Framework (ADB) 綁定實 現的運行速度與 JAXB 相當。
使用 WS-Security 時的性能
下圖展示了以下安全配置的測 試時間：
plain：無安全（與 圖 1 中的值相同）
username：針對請求的 WS-Security 純 文本 UsernameToken
sign：主體和頭部的 WS-Security 簽名，使用時間戳
signencr：主 體和頭部的 WS-Security 簽名，使用時間戳和主體加密
圖 2 展示了 1000 個請求而響應較少時 的測定時間：
圖 2. 響應較少時的測定時間
圖 3 顯示了同樣 1000 個請求但響應較少時的相對時間（已標准化為 CXF 結果）：
圖 3. 響應較少時的標准化時 間
在本測試中的所有安 全配置中，Axis2 始終是速度最慢的棧。Metro 始終是速度最快的，但 Metro 和 CXF 之間的性能差異將 顯著小於 CXF 和 Axis2 之間的性能差異：在不同配置中，Metro 大約比 CXF 快 10%，而 Axis2 要比 CXF 慢一半還多。
圖 4 顯示了 100 個請求但響應較多時的測定測試時間：
圖 4. 響應較 多時的測定時間
圖 5 顯示了 100 個 請求而響應較多時的相對時間（已標准化為 CXF 結果）：
圖 5. 響應較多時的標准化時間
在第二項測試中， Axis2 仍然慢於 Metro 和 CXF（仍然只有 CXF 的一半左右），並且 Metro 和 CXF 處理少量響應消息的 速度則反過來了，CXF 的速度要快 15%。
CXF 2.1.7 與 2.1.6
這些測試結果反映了 CXF 在版本 2.1.6 和 2.1.7 之間的性能得到顯著改善。代碼調優對此功不可沒，但重要的是修復了 “ 通過 CXF 使用 WS-Security” 中所討論的問題。CXF 2.1.6 未處理 UsernameToken WS- SecurityPolicy 配置，除非存在一個 <sp:TransportBinding> 策略或某種形式的加密或簽名策略 。通常，使用 UsernameToken 時需要提供一個增加的策略 — 特別是純文本 UsernameToken，因為 如果沒有傳輸級和消息級加密，則用戶名和密碼在傳遞過程中將是可見的。但是，從策略的角度來說，使 用 UsernameToken 是絕對高效的（與本文的 username 配置相同），並且為 CXF 2.1.7 實現的修復將處 理這個問題。作為修復的一部分，CXF 2.1.7 在這種特殊情況下將跳過將 WS-Security 處理添加到響應 消息流中的步驟。
與 CXF 2.1.6 運行的相同測試相比，在 username 配置中刪除消息流中的 WS -Security 將 CXF 的總體性能提高了幾個百分比。遺憾的是，版本之間的這種改善有點失真。如果 usernaeme 測試用例使用傳輸級或消息加密，則響應消息流中將提供 WS-Security 處理，並造成該配置 的 CXF 時間結果慢很多。但未來的 CXF 版本有希望擴展策略分析，這樣僅在需求時才會在請求或響應流 中配置 WS-Security，從而將性能優勢擴展到更廣泛的用例（包括那些只需在一個方向上簽名或加密的用 例）。
結束語
根據本文報告的測試時間，Metro 2.0 在基本請求/響應處理方面快於 Axis2 1.5.1 或 CXF 2.1.7。但是，在 WS-Security 處理方面，Metro 的 XWSS 庫在總體性能上則無法 與 Axis2 和 CXF 所使用的 WSS4J 庫相提並論。
在這些結果中，最有趣的一點可能是 Axis2 影 響。早期測試表明，Axis2 在 WS-Security 處理上要比 Metro 慢很多。這些測試結果表明，差異並非歸 因於 WS-Security 實現代碼，因此必然與 Axis2（以及 Rampart 安全模塊）處理傳遞給 WSS4J 以及從 它接收到的消息的方式相關。這證實了 “比較 Metro 與 Axis2 性能” 中所討論的結果。與 其他棧相比，Axis2 運行測試所需的內存也要多很多，這在 signenecr 配置中尤為突出（Axis2 在客戶 機上大約需要 800MB 內存；而 CXF 只要 48MB 便足矣）。這些問題加強了 Axis2 浪費處理時間和內存 來處理不同消息表示之間的不必要轉換（WS-Security 處理的一部分）的早期印象。
接受測試的 棧在使用 WS-Security 簽名和加密方面的性能開銷都很大。這種開銷會對使用量較大的服務帶來問題。 在下一篇文章中，您將了解 WS-Trust 和 WS-SecureConversation 增件技術，該技術可以在客戶機廣泛 使用特定服務時降低 WS-Security 開銷。
下載
描述 名字 大小 下載方法 本文的源 代碼 j-jws14-src.zip 4.86MB HTTP
