想要學習如何優化面向服務的體系結構（Service-Oriented Architecture，SOA）中的 Web 服務應用程序嗎？Judith M. Myerson 強調了業務流程規則在優化 Web 服務的過程中具有最高優先級的重要性，并給出了其他優化技術的例子，例如減少 Web 請求的數量和執行時間。 她還討論了 IBM WebSphere Business Integration，開發人員和業務分析人員可以使用這個工具來協作建模 Web 服務，以便進行優化 。
引言
在這個系列的第 1 部分中，我展示了如何執行 Web 服務的業務邏輯來使專有的企業應用程序集成（Enterprise Application Integration，EAI）應用程序可以交互。在第 3 部分中，我指出了 Web 服務如何相互通信來交流集成和實現多個 SOA 中的流程的方式。同樣，我還在第 4 部分中討論了開發人員可以如何使用 Rational? 開發工具來創建實際的應用程序。
在本文中，我將討論在優化 Web 服務和 SOA 的過程中具有最高優先級的 Web 服務的業務流程規則。一旦開發人員優化了流程規則，那么他們就可以開始減少：
- Web 請求的數量
- 執行時間
- 訪問時間
- 不需要的數據
- 帶寬量
開發人員還需要考慮連接到一個或多個 Web 服務的大型數據庫的分區方案。
業務流程規則
為了減少通信量瓶頸或者加載開銷，開發人員需要使用某些業務流程規則來優化跨 SOA 的 Web 服務的性能。他們應該使用用于 Web 服務的業務流程執行語言（Business Process Execution Language for Web Services，BPEL4WS）規范來創建新的業務邏輯、調用 Web 服務、操作數據、拋出錯誤或者終止流程。
您可以使用可執行的流程基于業務邏輯組成新的 Web 服務，以便實現組織的業務目標。您還可以使用抽象的流程作為兩個合作伙伴之間在電子商務對話中如何進行交互的協議。
Web 請求
在優化業務流程規則之后，開發人員可以繼續開發他們所需要的 Web 請求，從現有的 Web 服務構建新的 Web 服務。Web 服務是在 SOA 內部還是跨 SOA 都沒有關系。如果新的 Web 服務——業務邏輯或者以數據為中心——提供更好的或者額外的服務或功能，開發人員必須減少或者完全消除冗余的 Web 請求。圖 1 展示了兩個現有的 Web 服務各自發送了一個冗余的 Web 請求來創建新的 Web 服務。
圖 1. 冗余的 Web 請求
執行時間
在開發人員優化了現有的 Web 服務可以發出的請求數量之后，他們還需要減少現有的 Web 服務的執行時間，以便在組合生命周期的任何時刻基于業務流程創建新的 Web 服務。以數據為中心的 Web 服務極少自己執行。
當開發人員組合新的 Web 服務時，他們應該當心不要導致新的冗余。為了消除冗余，可能需要將某些冗余的 Web 服務合并成為一個服務。
訪問時間
如果給定最佳的執行時間，則減少訪問時間是開發人員需要關心的另一個問題。當 Web 服務請求比較簡單時，從數據庫或者另外的數據源中訪問所請求的信息的時間必須是最佳的。在使用和發布 Web 服務時必須注意請求不要互相重疊。
開發人員應該模塊化、最優化和索引化請求，以便減少訪問時間。然后，他們可以將 Web 請求放在儲存庫中，以便在新的應用程序中重用。
帶寬量
正如您所知道的，Web 服務基于 XML，并且大部分文件都很小。通常帶寬不是問題，而且執行和訪問時間也都是最佳的。問題在于大的 XML 文件。當您每次更改遠程服務器上的這些文件時，您需要重新傳輸整個文件。大的未壓縮格式的圖形文件可以消耗掉大量的磁盤空間和帶寬量，從而延緩了訪問時間。
作為部分的解決方案，開發人員只需要傳輸對新的 Web 服務的文件的更改。其他節省帶寬的技術包括：加速頁面加載的緩存技術、優化解析文本格式的 XML 文件的時間，以及將 XML 文件編譯成二進制文件（不可讀的）。
不需要的數據
開發人員應該指定篩選規則來清除他們不想要的數據。篩選規則與針對減少數據冗余的標準化規則不是一回事。他們同樣也應該優化篩選規則，然后將它們（XML 格式）存儲到儲存庫中，供以后調用。您可以在需要這些規則時從儲存庫中加載它們，而在您不需要時將它們卸載回儲存庫。篩選規則還應該包括對舊數據的自動清除或者備份、以及使大的 XML 文件不久后過期的機制。
分區方案
當 Web 服務連接到大型數據庫時，應該注意是如何跨服務器訪問、篩選和分發數據的，尤其是在后者位于不同的 SOA 中的情況下。為了在減少帶寬的同時更快地進行訪問，開發人員應該考慮兩件事情：
如果數據庫的大部分經常都需要更新，那么您應該考慮分區方案：硬件分區、水平分區或者垂直分區。而如果數據庫只是一小部分經常需要更新，那么就考慮動態分區。
硬件分區
您可以使用獨立磁盤冗余陣列（Redundant Array of Independent Disk，RAID）進行硬件分區，物理地將表放在單獨的磁盤驅動器上而不必分割表。把一個表放在一個物理驅動器上而把其他的表放在單獨的驅動器上可以提高吞吐量和操作效率。另外，您還可以選擇將一個表拆開，放到多個驅動器上，這樣比將同一個表存儲在一個驅動器上掃描起來快。
水平分區
您可以基于年代水平地對數據進行分區。例如，您可以將一個大表分成十個小的子表，每個子表包括十年中的一年的數據和業務流程規則。
垂直分區
您可以使用這種方法將表分成若干個子表。您可以應用規范化的概念刪除表的冗余部分，然后將它們放在次表中。您還可以在次表中建立外鍵，以鏈接主表中的主鍵。
動態分區
在某種情況下，您可能需要經常更新數據中相對較小而非常重要的子集，我們假定您的數據庫中的絕大多數信息相對來說是靜態的。如下面的圖 2 所示，您需要分別按頻繁更新和很少更新將數據庫分成動態部分和靜態部分。
圖 2. 動態部分和靜態部分
這就意味著您需要以這樣的方式設計數據庫系統，即將數據庫表劃分成兩種類型——靜態和動態——的模塊化、最優化部分。您可以將靜態的部分保存在本地服務器上，而將動態的部分轉移到遠程服務器供用戶頻繁地更新。您可以通過跨一組本地服務器和另一組遠程服務器分割表來實現這一點。當新的 Web 服務更新數據庫時，這種方法可以幫助減少多個數量級的帶寬使用。
消除語言隔閡
開發人員和業務分析人員應該找到優化 Web 服務和 SOA 的方法的共同基礎。這種方法存在的一個問題就是，他們往往使用不同的語言，使用不同的術語，并且具有不同的知識背景。
例如，業務分析人員使用流程模型來處理業務需求，而開發人員使用統一建模語言（Unified Modeling Language，UML）模型來專注于他們想要優化的 Web 服務的系統功能。解決這個問題的一種方法就是進行 UML 和業務流程建模（Business Process Modeling，BPM）模型之間的集成和轉換。這將有助于進行良好的溝通，并減少由于缺乏交流而帶來的成本。
WebSphere Business Integration 工具
下面是 IBM WebSphere? Business Integration（以前稱為 IBM Holosofx）工具，您可以使用它們來消除這種隔閡：
-
IBM WebSphere Business Integration Workbench：這是一個 BPM 工具，您可以使用它通過共同的 UML/BPM 工作區來消除業務分析人員或經理與開發人員之間的隔閡。
-
IBM WebSphere Business Integration Monitor：使用這個工具，您可以顯示來自 WebSphere MQ Workflow 所產生的事件的實時數據和歷史數據。通過查看業務控制、業務和 IT 的工作流 (Workflow) 和業務儀表板 (Business Dashboard)，您可以優化和管理業務性能。
-
IBM WebSphere Business Integration Workbench Server：這個工具向您提供儲存庫管理和 Web 發布功能。使用這個工具，您可以促進如下幾方面的流程設計協作和即時 Web 訪問：
-
IBM WebSphere Business Integration Modeler Advanced Edition：您可以在協作環境中使用這個工具來設計與多個用戶交互的流程。這款產品由 IBM WebSphere Business Integration Workbench Server 和 IBM WebSphere Business Integration Workbench 許可捆綁組成。您可以在 Windows? 2000 或者 Windows XP 操作系統中運行 WebSphere Business Integration Modeler Advanced Edition。
結束語
優化跨 SOA 的 Web 服務需要提前計劃實際上有多少依賴于業務規則的 Web 服務可以優化。開發人員應該就 Web 服務設計中使用什么建模技術和優化方案的問題與業務分析人員團隊進行溝通。通過預先解決這個問題，開發人員將會發現他們優化 Web 服務的工作變得更加容易了。他們可以開發和優化相互交互和集成——在 SOA 內部以及跨 SOA——的 Web 服務。
分析人員同樣也會發現，預先解決這些問題使他們設計和分析優化 Web 服務的業務端工作變得更加容易了。他們可以確定使用哪種建模方法、使用什么方案、以及在 SOA 中有多少 Web 服務可以優化。