FastSOA_用XML、XQuery.pptVIP

FastSOA：用 XML、XQuery 和本機 XML 資料庫技術加速 SOA 授課教授：葉慶隆 博士/教授 主講學生：黃正嘉 Rick Huang 作者介紹 Frank Cohen（mailto:frank.cohen@?cc=dwxed@）是企業在複雜的互動作業系統中需要建置、測試和解決問題時要找的人。 Frank 是 Java Testing and Design: From Unit Tests to Automated Web Tests 的作者，該書可以在 / 上找到。 他也是頗受歡迎的 TestMaker 開放程式代碼測試工具和框架的主要維護者、Raining Data Corporation Solutions Engineering 的主管、TigerLogic XDMS XQuery 引擎和本機 XML 資料庫的發表者。 中介程式 SOA 暫存架構的作用 很多 SOA 實現都依賴於用 XML 定義的訊息格式。結果，訊息模式可能變得非常複雜、不相容、難以維護，甚至造成嚴重的可伸縮性和性能問題。 在本文中， 將介紹如何透過在 SOA 中介程序使用 XML、XQuery 和本機 XML 資料庫技術來提高 SOA 性能的策略和技術。 例如，最早提出用 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 資料非常慢而且沒有可伸縮性。 Web 服務存取量問題和複雜的 XML(二) 為了瞭解這三個問題，設想一下軟體發展人員如何使用 J2EE 應用程式伺服器工具建置和部署 XML 服務。 雖然可以使用使用不同技術建立使用 XML 的 Web 服務，但我發現多數開發人員更願意從服務的 Web Services Description Language (WSDL) 定義開始。 Web 服務存取量問題和複雜的 XML(三) 透過研究用流行的 Java 應用程式伺服器工具建立的 SOAP 鎖定，我發現了以下問題： 應用程式伺服器工具建立的 SOAP 鎖定效率很低。 比如，我發現某些 SOAP 鎖定建立 SOAP 請求的多個副本，每個請求 都實例化為 String 物件 —— 這樣做並沒有明顯的理由。 在配備有雙 CPU 3.0 GHz Intel Xeon 處理器的伺服器上，我發現隨著 SOAP 消 息複雜性和大小的增加，會造成明顯的伸縮性和性能問題。 有效負荷 100,000 位元組、包含 750 個元素的 SOAP 消息會把吞吐量降低到 1.5 TPS。SOAP 訊息中元素個數越多，每個元素嵌套越深，問題就會越嚴重。 FastSOA 解決方案 FastSOA 是解決這些問題的一種架構和軟體設計實踐： FastSOA 透過減少 Java 物件的需要，更多使用本機 XML 環境提供 SOAP 鎖定來解決 SOAP 鎖定（代理）性能問題。 FastSOA 引入了中介程式服務緩衝來加快 SOA 服務。 FastSOA 使用本機 XML 持久性來避免 XML 到關聯資料庫的轉換造成的性能問題 FastSOA 方法的優點 服務端點是標準的。對於應用程式的其他部分而言，FastSOA 中介程式暫存就像是一種服務。 不需要修改現有的系統或程式碼。FastSOA 中介程式暫存作為一種資料聚合和遷移服務嵌入到已有的資料中心。 如果上游服務暫時不能用，當服務離線的時候，FastSOA 方法提供了一種瀏覽暫存資料的機制。 透過暫存服務的請求降低了為支援消費者和服務之間的通訊通常所需的頻寬要求。 計算服務增