很多 SOA 實現都依賴于用 XML 定義的消息格式。結果，消息模式可能變得非常復雜、不兼容、難以維護，甚至造成嚴重的可伸縮性和性能問題。在本文中，Frank Cohen 將介紹如何通過在 SOA 中間層使用 XML、XQuery 和本機 XML 數據庫技術來提高 SOA 性能的戰略和技術。

很多軟件架構師在面向服務體系結構（SOA）設計中使用 XML，雖然沒有一種 SOA 標準要求在 SOA 中使用 XML 或者提供相關指南。因此，軟件開發社區做了很多實驗和調查來發現定義服務端點和消息定義（模式）的最佳方式。這些方法大多數都會帶來了糟糕的性能和可伸縮性。

比如，最早提出用 SOA 實現 ebXML 的 General Motors Corp.，其最初的設計使用的是 Universal Business Language (UBL)，建立的 XML 消息有 150,000 字節到 10 兆字節甚至更大。2004 年，我的性能測試公司 PushToTest 認為當時的 Java? 應用程序服務器沒有提供足夠的吞吐量，在 GM Web Services Performance Benchmark 研究中提出了可伸縮性和性能問題。

當時基于 XML 的 Web 服務技術還非常新，我認為新一代應用程序服務器技術會解決性能問題。但大部分問題仍然存在。

Web 服務吞吐量問題和復雜的 XML

2005 年，PushToTest 完成了一項新的 SOA 性能研究（請參閱參考資料）表明，在處理復雜的 XML 消息時，使用當前 Java 應用程序服務器構建的應用程序其性能很差，不足以投入生產。是發現的問題和以前研究中的問題相同：

• 簡單對象訪問協議（SOAP）綁定（代理）低效而緩慢。
• 每次請求都需要一組全新的資源（對象、CPU 和網絡帶寬）來處理響應。沒有緩沖模式。
• 使用關系數據庫技術存儲 XML 數據非常慢而且沒有可伸縮性。

雖然可以使用使用不同技術建立基于 XML 的 Web 服務，但我發現多數開發人員更愿意從服務的 Web Services Description Language (WSDL) 定義開始。Java 應用程序服務器提供了輸入 WSDL定義和生成代理類的工具。代理器接收 SOAP 請求并把請求轉發給 Java 對象或 Enterprise Java Bean (EJB) 進行處理。SOAP 綁定（代理器）是一種 Java 類，可通過 servlet 接口調用它。

圖 2 說明了 Web 服務消費者如何向服務發出 SOAP 請求。SOAP 綁定對 SOAP 消息體中的 XML 內容進行反序列化。這個過程需要進行大量的處理，非常復雜，因為消息體常常包含復雜的數據類型。比如，消費者可能向服務發送包含多個值的散列表。SOAP 綁定需要解碼散列表的內容，對每個值創建 Java 對象的實例。散列表還可能包含其他散列表，因此解碼 SOAP 消息內容不是一件容易的事。如果不相信的話，請看一看 Apache Axis 反序列化器的源代碼。

SOAP 綁定實例化包含 SOAP 消息體內容的 Java Request 對象。SOAP 綁定調用目標類中的目標方法，并將 Request 對象作為參數傳遞。目標 EJB 或 Java 對象提供所有必要的處理來建立對請求的響應。SOAP 綁定將 EJB 或 Java 對象返回的值序列化到 SOAP 響應消息中。SOAP 綁定將響應對象中的值解碼成能夠序列化到 SOAP 響應消息中的值需要經過同樣復雜的過程。

通過研究用流行的 Java 應用程序服務器工具創建的 SOAP 綁定，我發現了以下問題：

• 應用程序服務器工具創建的 SOAP 綁定效率很低。比如，我發現某些 SOAP 綁定創建 SOAP 請求的多個副本，每個請求都實例化為 String 對象 —— 這樣做并沒有明顯的理由。一些 SOAP 綁定創建了 15,000 個 Java 對象來反序列化消息體中包含 500 個元素的 SOAP 請求。
• 在配備有雙 CPU 3.0 GHz Intel Xeon 處理器的服務器上，我發現在處理有效負荷 10,000 字節、包含 50 個元素的簡單 SOAP 消息時，每秒處理的事務為 15 到 20 個（TPS）。隨著 SOAP 消息復雜性和大小的增加，我發現會造成明顯的伸縮性和性能問題。有效負荷 100,000 字節、包含 750 個元素的 SOAP 消息會把吞吐量降低到 1.5 TPS。SOAP 消息體中元素個數越多，每個元素嵌套越深，問題就會越嚴重。

性能問題在 SOA 設計中會引起連鎖反應。SOA 是一種組件軟件重用技術。一個服務通常調用其他服務來確定對消費者請求的響應，從而形成一個調用鏈。

不僅僅是一個服務的性能問題，每個服務在序列化、反序列化請求和響應的時候都會增加同樣的開銷。隨著服務調用層次的增加，性能問題也成倍增加。

加快 SOA 失去的機會

除了 SOAP 綁定代理速度慢的問題，SOA 設計還常常忽略或者忽視另外兩個問題。

首先，SOA 設計常常忽視了用中間層服務緩沖來提高 SOA 性能的可能性。比如多數 SOA 設計中的 XML 模式都定義了了響應的 time-to-live 值。在這種情況下，緩沖服務響應并在服務再次收到同樣的請求時重新使用緩沖的響應是一種提高 SOA 服務性能的合理而適當的方法。

其次，在 SOA 性能測試中，我嘗試了各種不同的 XML 消息解析方法，其中包括 Streaming API for XML (StAX)、XML 綁定編譯器、Java Architecture for XML Binding (JAXB) 和 Document Object Model (DOM) 技術。一些技術的性能要優于另一些。比如，很多 StAX 解析器能夠提供比 DOM 解析器快 2 到 10 倍的性能。

我懷疑如果使用其他東西而不是 Java 對象來提供 SOAP 綁定是否能夠改進性能。比如，如果收到的 SOAP 請求在本機 XML 環境中處理，那么基于 Java 的 SOAP 綁定就不再是必需的了，同時還可以避免因為序列化成 Java 對象而導致的性能降低。

此外，一些本機 XML 環境使用 Java Virtual Machine 環境，但會避免構造 Java 對象。比如，Raining Data 的 TigerLogic XDMS 和 Kawa/Qexo 通過將 XQuery 查詢直接轉換成 Java 字節碼來實現 XML 處理代碼。這樣做是因為與使用 Java 對象相比，使用 XQuery 字節碼實現的 XML 處理代碼的吞吐量更大，代碼更短。

FastSOA 解決方案

FastSOA 是解決這些問題的一種體系結構和軟件編碼實踐：

• FastSOA 通過減少 Java 對象的需要，更多使用本機 XML 環境提供 SOAP 綁定來解決 SOAP 綁定（代理）性能問題。
• FastSOA 引入了中間層服務緩沖來加快 SOA 服務。
• FastSOA 使用本機 XML 持久性來避免 XML 到關系數據庫的轉換造成的性能問題。

下圖顯示了 FastSOA 體系結構。

FastSOA 體系結構與現有的基于 Web 的基礎結構結合在一起，作為中間層緩沖部署來接收服務消費者的請求。比如，一個消費者向服務發出 SOAP 請求。中間層緩沖提供 SOAP 綁定（代理）。綁定調用 XQuery 在 XQuery 引擎處理 XML 請求文檔。XQuery 檢查緩沖，查看以前是否收到該請求；在這種情況下，FastSOA 服務可以從緩沖中返回響應，不需要逆流而上再請求服務。該過程通過緩沖加快 SOA 執行從而實現了 SOA 提速。

FastSOA 方法的優點包括：

• 服務端點是標準的。對于應用程序的其他部分而言，FastSOA 中間層緩沖就像是一種服務。
• 不需要修改現有的系統或代碼。FastSOA 中間層緩沖作為一種數據聚合和遷移服務嵌入到已有的數據中心。
• 如果上游服務暫時不能用，當服務離線的時候，FastSOA 方法提供了一種瀏覽緩沖數據的機制。
• 通過緩沖服務的請求降低了為支持消費者和服務之間的通信通常所需的帶寬要求。

為了從實踐的角度理解 FastSOA，考慮下面的應用程序。

XML 的例子

General Motors 采用 SOA 模式創建服務，讓汽車代理商使用基于 ebXML 的模式和協議從生產廠家訂購零部件。該服務能夠識別 Software Technology in Automotive Retailing (STAR) 組織的一種 XML 模式。STAR 是大型汽車廠商共同努力的結果，其中包括 GM。STAR 創建并維護 Business Object Document (BOD) 模式，定義了目錄檢查請求（以及其他許多東西）。

CheckInventory 請求檢查請求者和目錄的級別與狀態。服務消費者根據 STAR 模式創建目錄請求文檔。消費者將文檔編組成請求，并通過網絡發送給服務。服務發回目錄狀態響應說明庫存中有哪些零部件。

通過降低網絡帶寬的需要和減少為了響應冗余請求而造成的服務帶寬需要，零件訂購服務可以從 FastSOA 模式中受益。

比方說，汽車零售商的零件目錄響應中包含一個 Time-To-Live (TTL) 元素。TTL 元素定義了響應有效的秒數。比如 GM 可能將其設為 60 秒。在這 60 秒內，FastSOA 用中間層存儲的目錄響應緩存響應目錄請求。這樣服務就減少了帶寬的使用，并縮短了請求響應時間。

下表說明了如何計算網絡中的服務提速效果，這些服務位于本地網絡之外的服務器上，FastSOA 數據緩沖收集服務在本地網絡中。

在 FastSOA 實現中，用 XQuery 實現零部件訂購服務。XQuery 請求目錄服務，讀取響應的內容，在運行時確定是否可以使用以前存儲的響應而不必再次請求目錄服務。

這樣就在服務環境中實現了 FastSOA 數據緩沖收集體系結構。XQuery 和本機 XML 數據庫提供了重用以前緩沖響應數據的服務，只要請求與以前的請求匹配并且數據仍然不過時。結果是服務提速了。

FastSOA 技術選擇

可以使用 Java 代碼和關系數據庫技術實現 FastSOA 體系結構。但是，在測試使用 Java 對象創建的服務綁定和使用關系數據庫持久 XML 時，我發現了重要的性能和可伸縮性問題。這些問題很突出，考慮使用 XQuery、XSLT 和本機 XML 數據庫技術很有必要。

我對 XQuery 感興趣，是因為它是作為應用程序開發的本機 XML 環境來實現的。與早期的 Java 技術非常相似，XQuery 社區充滿了擴張和證明 XQuery 是一種開發平臺的活力。實際上，多數 XQuery 實現都經過擴展超出了 XQuery 標準，以便 XQuery 能夠進行 SOAP 請求。比如，XQuery 可以查詢其他服務、J2EE 對象和通過 JDBC、SOAP、JMS 協議查詢數據源。此外，已經有 10 種或更多非常可靠的商業化和開放源碼 XQuery 實現。

最后，FastSOA 使用本機 XML 數據庫作為中間層緩沖，因為 SOA 數據通常采用 XML 編碼格式，而關系數據庫在持久存儲和索引 XML 這樣的層次性非結構化數據方面有很大不足。存儲 XML 數據的關系數據庫通常使用大型二進制對象（BLOB）字段類型存儲 XML。不僅效率低，而且很難建立索引以便快速搜索。對于流數據采用關系方法通常也不是最佳辦法。如果在基于 Web 服務的網絡中發送 XML 消息，最好用基于流的方法處理該消息，而關系數據庫對此無能為力。

FastSOA 的未來

除了本文所述的 SOAP 綁定性能改進之外，采用中間層服務緩沖還會為企業帶來很多好處。其他好處包括中間層模式轉換、服務版本化、策略選路和服務質量（QOS）處理。比如，FastSOA 提供了中間層 XML 消息模式轉換，以便保證需要不同和不兼容的消息類型的服務之間的兼容性。

結束語

本文考察了如何提升 SOA 的性能和可伸縮性，詳細介紹了在中間層使用 XQuery 支持結合 XML 持久的 SOA 設計所帶來的好處。FastSOA 設計結合使用了本機 XML 持久性和 XQuery，因此每次收到服務調用時，中間層都要決定是使用以前請求的緩沖值響應，還是傳遞請求。服務使用 XQuery 根據對服務請求元數據查詢的結果描述判定緩沖是否有效。