在企業級 SOA 中使用 Web 服務，第 11 部分: 使用 WebSphere Business Modeler 和

對將基于 XML 二進制優化打包 (XML-binary Optimized Packaging, XOP) 的服務連接到外部服務有興趣嗎？在本文中，我們將開發橋接 Web 服務、確定文件大小閾值，并設置多個隊列。理解外部文件依賴項、創建非線性隊列、使用非線性讀取以及設置最佳大小閾值。同時使用 IBM Rational Web Developer® 和 IBM WebSphere Business Modeler® 來簡化開發流程。

引言

在本系列的第 7 部分，我們向您介紹了為何基于 XML 的 Web 服務應用程序會變得過于龐大。當大量使用 Web 服務時，這些 Web 服務將導致系統過載，進而阻塞網絡通信。為了解決這個問題，我們應用 XML 二進制優化打包 (XOP) 規范來提高 Web 服務的速度。

該 XOP 規范是一個標準草案，旨在比當前 XML 解析器更有效地處理 Web 服務。解析器的行為更像是解釋器，而不是編譯器。當解析器讀寫大型文件（特別是文本格式的）時，并不能達到其讀取較小的文本文件或計算簡單函數的性能。甚至加密也可能使 Web 服務陷于停頓，因為必須執行復雜的計算才能獲得希望的結果。

在本文中，我們將繼續介紹 XOP 規范，探討如何將一個組織內部遵循 XOP 的 Web 服務連接到外部沒有遵循此規范的繁忙的 Web 服務上。當系統限制了帶寬、訪問控制數以及 Web 請求數時，此類連接將變得非常重要。

回頁首

開發橋接 Web 服務

您需要開發橋接 Web 服務來測試從外部 Web 服務傳入的文件是否遵循 XOP。如果測試成功，橋接 Web 服務將允許外部文件傳入。如果測試失敗，橋接 Web 服務將進行第二次測試以確定文件的大小。如果文件很小，則橋接 Web 服務允許這些文件傳入。如果該文件在這兩次測試中均失敗，則橋接 Web 服務會將它路由到一個內部 Web 服務，然后您可以使用該服務將文件轉換成二進制格式以使它遵循 XOP。在本文中，您將了解如何使用 IBM 工具來設置橋接 Web 服務中的隊列以挑選出外部文件。

那么，應該考慮哪種隊列呢？我們先看一個簡單的隊列，然后再介紹一個較復雜的隊列。對于任何隊列類型，首先都應該對作為橋接 Web 服務單元到達隊列的外部文件的特性和為接收這些文件而設計的目標 Web 服務進行評估。圖 1 顯示了進入一個簡單隊列的外部文件。數字的粗度代表文件的大小。數字越粗，文件就越大。

接下來，您需要確定每個文件在進入隊列之后的行為。問自己以下問題：

• 當進入隊列時，文件能否處理服務延遲？
• 文件是否會不耐煩并想要進入另一個隊列以獲得更快的服務？
• 隊列應該有多大？
• 隊列的支持程度應該有多大？
• 當隊列達到其最大值時，Web 服務應該如何通知發送文件的外部 Web 服務必須等待一段時間才能將文件發送到該橋接 Web 服務上？
• 它如果無法等待，則應該將文件發送到同一個橋接 Web 服務的另一個隊列上，還是發送到不同的橋接 Web 服務上？

回頁首

確定文件大小閾值

橋接 Web 服務中的隊列如何知道最佳的文件大小是多少呢？您需要建立一套大小閾值機制，將其設置在一定水平上以衡量外部文件的大小是否最優。如果文件大小在閾值或閾值以下，則橋接 Web 服務會將該文件從其隊列中釋放出來，以供請求處理的面向服務體系結構 (Service-Oriented Architecture，SOA) 做進一步處理。如果文件超出閾值，則 Web 服務會將其標記為“過于龐大”。然后將被標記的文件釋放并發送到 Web 服務文件優化器上。

當文件優化器接收到該文件時，會對其進行 XOP 規范的處理以使其變得更小。然后對處理過的文件進行檢查，以確定其大小是否在大小閾值的范圍之內。如果測試表明確實如此，則認為該文件是最優的。否則，將向您發出警報，提示您檢查文件內容或編程邏輯。

回頁首

設置多個隊列

橋接 Web 服務中只有單個隊列的問題是每個文件都必須耐心地等待輪到它的時候。文件無法繞過在它前面的另一個文件，就像在單行道上車輛無法超越在它前面行駛緩慢的車輛一樣。您會問，那應該怎樣解決呢？

一種可能的回答是設置兩個隊列。您已經了解了如何在橋接 Web 服務中設置一個隊列來從外部 Web 服務接收傳入的文件。如果該文件已在隊列中，但不符合閾值范圍，則應該對它進行標記并允許它從該隊列跳到另一個隊列中。在這個次“優先”的隊列中，該文件會被釋放并發送到 Web 服務文件優先器的隊列中，此優先器將使用 XOP 規范來處理該文件。這種解決方案對于不依賴于其他文件（過于龐大或者不過于龐大的）的文件來說足夠了。

回頁首

理解外部文件依賴項

上述方案適用于橋接 Web 服務釋放到內部 Web 服務的一系列外部文件都沒有連接到其他文件的情況。如果只有外部文件有多個依賴項需要連接 SOA 中請求的 Web 服務才能完成一個或一系列任務，則會出現什么情況呢？而當內部 Web 服務中有兩個經過裁減的文件需要連接到一個正等待優化的過于龐大的文件時，又會出現什么情況呢？

我們假設此請求的 Web 服務執行了兩個任務。首先，它從 Web 服務文件優化器接收這兩個文件。然后，它幾乎同時要求這兩個文件連接到仍在橋接 Web 服務的隊列中的第三個文件。在連接完成后，將釋放該第三個文件以便文件優化器進行處理。如果在一定時間范圍內該文件沒有獲得最優化，則請求的 Web 服務的性能會下降。

Web 服務文件優化器中的隊列是單一的，這意味著它不會在意該文件是否等待被優化而等得不耐煩。該文件必須線性地等待輪到它的時候。文件被優化需要一定的時間，這將導致請求的 Web 服務的性能下降。

回頁首

創建非線性隊列

處理這種等得不耐煩的文件的一種方式是在 Web 服務文件優化器中創建非線性隊列。當非線性接收隊列從外部 Web 服務接收過于龐大的文件時，文件優化器可以將該文件移到可以立即進行多線程優化的另一個非線性隊列中。

如果有許多過于龐大的文件要處理，則可能需要根據每個文件的優先級和大小建立多個不同優先級的非線性隊列。優先級較高的文件可以分配到高優先級的非線性隊列中。類似地，那些優先級較低的文件可以分配到低優先級的非線性隊列中。優先級在最高和最低之間的其他任何文件可以分配到合適優先級的非線性隊列中。

為了使多線程有效地執行，您必須確保操作系統有足夠的資源來執行優化程序（文件優化器用它來根據每個文件的優先級和大小對文件進行裁減）的不同部分。您必須謹慎地設計該程序，以保證所有線程都可以同時運行而不會相互干擾。

回頁首

使用非線性讀取

我們假定操作系統能夠使設計為一次性將 10 個文件優化成裁減版的程序完全多線程化。并假設文件優化器以多線程方式從其隊列中釋放三個過于龐大的文件以供該程序做進一步處理。從非線性隊列中獲取這三個過于龐大的文件加速了文件相互連接的過程。

您可以使用 Rational Web Developer，以某種方式設計 Web 服務，通過這種方式，Web 服務可以根據業務流程、多線程模式、非線性算法以及文件的優先級和大小讀取這些文件。圖 2 顯示了非線性高優先級隊列和進行中的多線程優化之間的關聯。

回頁首

設置最佳大小閾值

那么，應該如何確定需要優化的文件的大小閾值呢？您可以使用 WebSphere Business Modeler 來幫助開發人員和業務分析人員達成一個閾值范圍（允許在隊列中動態更改）。設置閾值范圍取決于網絡流量的大小、最大無故障運行時間以及峰值時間的帶寬總量。還取決于生命周期特定時刻的 Web 服務編排方式、防御深度設置、訪問和執行次數的頻繁程度、延遲問題，以及在給定時間內發生的 Web 請求數。

假設每個要優化的文件（全都標記為“高優先級”）的大小閾值都有顯著差別。為了解決這個問題，我們考慮設置三種不同優先級的閾值隊列：

• 高優先級、大小較小的閾值隊列
• 高優先級、大小中等的閾值隊列
• 高優先級、大小較大的閾值隊列

您必須謹慎地設計該程序，以保證所有線程都可以同時運行而不會相互干擾。

回頁首

結束語

在本文中您了解到，為了開發將基于 XOP 的 Web 服務連接到外部服務的橋接 Web 服務，我們需要有計劃地理解文件依賴項和設置多個非線性隊列。同樣重要的是，團隊成員（包括系統管理員、業務分析人員和開發人員）之間必須相互交流，以確保獲得最佳文件大小閾值和從高優先級隊列進行最佳非線性讀取，以及確定可以將多少個文件導入多個非線性隊列而不會導致系統過載。

為了使工作更簡單，請基于用 IBM WebSphere Business Modeler 建模的業務流程并使用 IBM Rational Web Developer 開發 Web 服務。這些產品可以簡化將基于 XOP 的 Web 服務連接到外部服務的工作。