在企業級 Java 開發領域，Web 服務扮演著關鍵角色。隨著技術演進，Metro 與 Axis2 成為兩大主流堆疊。本文將深入剖析兩者在不同安全配置下的效能表現，為架構選型提供實證依據。
Metro 建立在 JAXB 2.x 資料綁定與 JAX-WS 2.x 標準之上，屬於參考實作。其擴充功能（如 WS-Security）由 WSIT（Web Services Interoperability Technologies）專案提供，底層安全處理則委派給 XWSS（XML and WebServices Security Project）。
Axis2 則採用完全不同的技術棧：預設使用 ADB（Axis2 Data Binding）進行資料綁定，核心引擎自成體系，WS-Security 支援透過 Rampart 模組整合 WSS4J 實現。早期文章《WS-Security 的大開銷》已詳細探討 Axis2 在安全處理上的效能影響。
採用單機雙進程模式（Client 與 Server 運行於同一系統），排除網路延遲干擾，專注測量 Web 服務處理本身的開銷。測試應用為地震資料檢索服務，資料庫收錄 93,000 筆全球地震記錄。請求參數包含時間範圍與地理座標範圍，回傳符合條件的地震資訊。
各配置多次執行，取最佳結果記錄。
圖表顯示，在無 WS-Security 情況下，兩堆疊效能極為接近。小回應測試 Metro 領先 0.5 秒；大回應測試兩者僅差 0.1 秒。這表明 Metro 在請求處理單位時間上略有優勢，但實際資料傳輸階段兩者不相伯仲（基於 Axis2 預設 ADB 綁定；若使用 XMLBeans 綁定，Axis2 會顯著變慢）。
測試四種安全配置：
驚人發現：Metro 在 WS-Security 配置下比 Axis2 快 2 倍以上，大訊息的 username 與 sign 配置更超過 3 倍。這對於同樣成熟的兩大堆疊而言極為罕見。
透過 Rampart 內建的 `org.apache.rampart.TIME` 記錄器（DEBUG 層級）分析發現，Rampart 處理時間僅佔總耗時不到一半。這意味著主要瓶頸不在 WSS4J 安全實作本身，而在於 Axis2/Rampart 的架構設計。
關鍵問題在於：Rampart 在 WS-Security 介入時，未建立完整的訊息記憶體模型。這導致 UsernameToken 場景下表現不佳，其他 WS-Security 場景可能也存在類似的轉換與處理效率問題。Rampart 仍有巨大優化空間。
Metro 雖然配置相對繁瑣、文件有限，且綁定 JAXB/JAX-WS 標準（不如 Axis2 支援多種資料綁定靈活），但在核心效能指標上表現優異：
建議：若您的應用使用 WS-Security 且對效能敏感，Metro 是值得優先考慮的選擇。
下一篇將轉向 Apache CXF Web 服務堆疊——另一個 Apache 基金會專案。CXF 與 Axis2 共享部分底層組件，但在配置與部署理念上截然不同。敬請期待。
