軟件測試之用XML、XQuery和XML數據庫技術加速SOA （2）SOA 架構
關鍵字：XML、XQuery和XML 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 體系結構。
圖 4. 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) 模式，定義了目錄檢查請求（以及其他許多東西）。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
