WebSphere Process Server 流量管理，第 1 部分

轉自:http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0907_hopkins/0907_hopkins.html

簡介

WebSphere Process Server（此後簡稱為 Process Server）公開的 SOA 程式設計模型可以幫助實現廣泛的應用程式設計模式。一個常見的模式包含對應的源和目標整合端點系統之間的資料同步。

任何實時企業 IT 環境都涉及一組不同的應用程式，這組應用程式被部署到不同的執行時環境，公開不同的介面。整合架構師需要設計出能夠解決這些不相容性並實現資料同步的解決方案。整體設計必須考慮到每一種整合端點系統在非功能性特徵方面的差異。非功能性特徵方面的典型差異包括：

• 可用性：計劃中或非計劃中的當機很可能以不同方式影響端點系統。這將導致資料同步解決方案的參與方在不同的時間點變得不可用。對於目標系統當機，您通常需要暫停後續的請求轉發。另一種可取的做法是同時禁止額外的同步請求進入到整合中介軟體集線器（hub）。

• 併發處理能力：某些目標整合端點系統無法處理大容量的併發請求。如果這些系統中湧入了過量的請求，那麼將導致操作問題，並且在最壞的情況下，可能會導致目標端點系統故障。

這份共 2 部分的系列文章的第一篇給出了一種簡單的方法，可以在目標整合端點不可用時實現智慧的儲存和轉發功能，而不會受到源系統的影響。後續文章將給出一種在 Process Server 內截斷整合流量的方法，從而確保目標端點伺服器不會擠滿大量併發請求。

場景概述

儘管可以使用 Process Server 實現複雜的多路（n-way）資料同步集線器功能，但是考慮到清晰性，我們在一個包含兩個端點整合系統的簡單場景中分離了核心問題。這個場景包含一個整合流，接收來自源系統的入站訊息並將它們傳遞到目標系統。我們的示例中的源和目標系統均由 WebSphere MQ Queue Managers 提供。

Process Server 內部署的整合解決方案由兩個 Service Component Architecture (SCA) 模組組成（圖 1）。第一個模組，可以被看作是一個工作負載注入器，負責在入站訊息達到源 Queue Manager 時獲取它們。第二個 SCA 模組，可以將其看作一個訊息轉發器，負責將訊息傳遞到目標 Queue Manager。這些 SCA 模組通過 SCA wiring metaphor 直接連線在一起，形成了一個簡單的端到端同步解決方案。但是要注意，SCA 的模組化特性允許以一種不同的方式將這些模組連線在一起；例如，合併包含了其他功能的額外元件。分別使用 SCA Export 和 Import 建構函式來獲取傳入的訊息和轉發出站訊息，這兩個函式都具有一個 WebSphere MQ 繫結型別。

圖 1. 場景 SCA 的結構圖

如果所有 Queue Managers 都可用，那麼只需要傳遞訊息。然而，當一個目標系統出現當機，事情就有些複雜了。有許多種方法可以處理這種情況。預設行為是在訊息抵達源 Queue Manager 時繼續獲取它們，並嘗試將它們傳遞到目標整合端點系統。這將造成對每一次訊息傳遞嘗試丟擲一個故障，該故障由 Process Server Failed Event 子系統攔截。這些失敗的事件隨後可以從 Failed Event Manager 中管理。然而，對於那些具有較高程度的資料同步流量的系統，捕獲的失敗事件的數量可能會達到一個很高的水平。在這些情況下，最好實現一種更具可管理性的方法。方法就是，當檢測到目標端點系統當機後，要儘可能快地停止使用入站事件。

要使這兩個獨立 SCA 模組配合工作，關鍵機制在於對共享變數的訪問，這個共享變數在底層 WebSphere Application Server 執行時引擎提供的 Object Cache 工具中定義。

在從源 MQ Manager 獲取訊息之前，請求注入器元件將檢查這個指示器。如果可用性指示器表示端點服務可用，那麼訊息將被獲取以進行處理。如果端點服務被標記為不可用，那麼將建立一個 Human Task 來提供服務當機通知。

在入站訊息處理的開始階段，系統可用性指示器被設定為 “true”，表示端點系統是可用的。一個向不可用目標 Queue Manager 轉發訊息的失敗嘗試將導致丟擲一個故障。該故障由請求轉發器元件內的 Fault Handler 截獲。捕獲到故障後，共享系統可用性標誌被更新，表示系統當機。

關鍵實現細節

WebSphere Object Cache

我們利用底層 WebSphere Application Server 執行時引擎提供的 Object Cache 功能提供一個共享變數，該變數可以同時從 WorkloadInjector 和 RequestPropagator SCA 模組讀取和更新。您將需要定義一個新的 Object Cache 例項，如圖 2 所示，以執行示例程式碼。本文後面的 端點系統可用執行路徑演示 小節將提供更詳細的細節。

圖 2. 預定義的物件快取例項

工作負載注入器

Workload Injector 被作為 SCA 模組提供，而中心 SCA 元件被實現為一個 BPEL 流程（圖 3）。模組公開了兩個匯出，第一個用於接受最初的觸發事件（用於呼叫 BPEL 流程）。第二個匯出用於反覆獲取傳入的同步請求（被作為訊息傳遞給源 Queue Manager）。模組只有一個匯入，用於將元件連線到 Request Propagator 模組。

圖 3. Workload Injector SCA 模組

在入站訊息處理的開始階段，系統可用性指示器被設定為 true，表示端點系統可用。BPEL 流程的其餘部分負責反覆獲取來自源 Queue Manager 的訊息。在每次迭代的開始，系統可用性指示器判斷是獲取下一條訊息以進行處理，還是通過安排一個 Human Task 來暫停處理。任務的接受和完成允許終端使用者在繼續獲取訊息和終止處理之間做出選擇。

圖 4. Workload Injector 流程

從源佇列管理器接收入站訊息是由一個 SCA Export 以及一個 WebSphere MQ 繫結型別處理的。此結構被繫結到源佇列管理器，如圖 5 所示。

圖 5. InboundMessagesExport MQ 繫結配置

在獲取期間，MQ 訊息負載和對應的 xsd 資料型別（用於在 Process Server 內部封裝資料）之間的同步資料轉換是由一個定製 Data Handler 管理的。這個定製 Data Handler 的源資料可以在 Project Interchange 檔案中找到，本文的 下載 部分提供了該檔案。

關聯傳入訊息

WebSphere Process Server 進行了優化，可以為大量併發執行執行緒提供一個可伸縮的效能執行環境。多個動態（in-flight）流程例項可以在任何情況下共存。

通過將訊息負載中的一個或多個指定欄位的值匹配到先前指定的值，入站訊息可以被轉發到相應的動態流程例項。這一功能是通過使用 Correlation Set 和特定的內含屬性集指定的。在當前示例中，我們定義了具有一個內含屬性 objType 的 Correlation Set，指定了受控制的同步（圖 6）。

圖 6. 關聯屬性定義

請求傳播器（Propagator）

該元件也被實現為一個 BPEL 流程，並利用一個 SCA 匯入和 MQ Series 繫結來實現與目標 MQ Manager 的互動。

圖 7. Request Propagator SCA 的結構圖

這裡關注的主要特性是在嘗試將訊息轉發給目標 Queue Manager 失敗時，使用 BPEL Fault Handler 捕獲丟擲的故障。在這個 Fault Handler 中，我們更新系統可用性指示器來反映目標 Queue Manager 的不可用性。

圖 8. Request Propagator 流程

場景執行

端點系統可用執行路徑演示

讓我們首先演示源 Queue Manager 和目標 Queue Manager 之間的成功的受控制的訊息同步。SCA 匯出和匯入分別用於與源佇列管理器和目標佇列管理器互動，它們已經被配置為使用以下定義。

對於 Source Queue Manager：

• Queue Manager name：Source_QM
• Soure Queue name：Inbound_Queue
• Host name：localhost
• TCP/IP Listener port：1416

對於 Target Queue Manager：

• Queue Manager name：Target_QM
• Soure Queue name：Outbound_Queue
• Host name：localhost
• TCP/IP Listener port：1417

您必須在您的環境中建立這些 Queue Managers，或者分別修改 InboundMessages 和 OutboundMessages SCA Export/Import 配置，以指向源和目標 Queue Manager。

您必須定義用於提供共享變數的 Object Cache 例項。從 WebSphere Process Server 管理控制檯中，導航到 Resources > Cache instances > Object cache instances 並單擊 New。定義一個 Object Cache 例項，並使用如圖 9 所示的引數。

圖 9. Object Cache 定義

注意，您需要將附帶的 Project Interchange 檔案 中提供的兩個應用程式部署到您的 WebSphere Process Server 例項。確保源佇列管理器和目標佇列管理器均被啟動。一種管理佇列管理器的方便方法就是使用 WebSphere MQ 提供的 MQ Explorer 實用程式。

您現在必須啟動 RequestInjector 流程。為了保持簡單性，我們使用了 BPC Explorer：

1. 從 WebSphere Integration Developer shell 或 Web 瀏覽器開啟 BPC Explorer。
2. 通過導航到 Process Instances 啟動 RequestInjector 流程例項。
3. 選擇流程模板並單擊 Start Instance。在 Process Input Message 模板中，提供流程例項名，併為 objType 欄位提供 Customer 值（圖 10）。
   
   圖 10. 啟動 Request Injector 流程
   
   
   
4. 單擊 Submit 以呼叫流程例項。流程例項執行 Retrieve Message Receive 行為，在其中流程將等待訊息的到來以進行處理。
5. 開啟 WebSphere MQ Explorer 並通過單擊佇列名和選擇 Put Test Message，將一條訊息寫入到 Source_QM 中的 Inbound_Queue（圖 11）。
   
   圖 11. 放入測試訊息
   
   
   
6. 使用以下格式提供測試訊息負載（圖 12）：

   firstName,lastName,addr1,addr2,city,state,zip,CustomerID,Customer

   
   
   
   圖 12. 測試訊息資料
   
   
   
7. 單擊 Put Message 將訊息放入到佇列中。這將使 BPEL Receive 等待行為接收訊息以進行處理。成功地將訊息傳播給 Target_QM 中的 Outbound_Queue，這通過目標佇列的 Current Queue Depth 的遞增值表示。您可以通過右鍵單擊 Outbound-Queue 並選擇 Browse Messages 檢視出站訊息。注意，出站訊息中的欄位分隔符由 “,” 符號轉換成 “|” 符號（圖 13）。這種轉換髮生在定製 DataHandler 內部，是在從 xsd 資料格式轉換為字串訊息負載的出站轉換期間發生的。
   
   圖 13. 傳播給 Target Queue 的訊息
   
   
   

此時將迭代 RequestInjector，並且再一次等待下一次的訊息傳播。

端點系統不可用執行路徑的演示

假設 RequestInjector 正在等待下一條傳入訊息的到來以實現前面討論的同步，您可以通過智慧儲存和轉發實現繼續執行系統的不可用路徑。

1. 通過右鍵單擊佇列管理器名並選擇 Stop，從 WebSphere MQ Explorer 關閉 Target_QM。
2. 通過遵循前一小節介紹的步驟提交後續的入站訊息。在傳播同步訊息期間，WebSphere Process Server 將丟擲一個由於 Target_QM 不可用而引發的異常。與該異常相關的 Stack 跟蹤被寫入到 WebSphere Process Server SystemOut.log 檔案，同時寫入的還有表示 RequestPropagator BPEL Process 中定義的 Fault Handler 已被呼叫的訊息。
3. 在同步下游期間檢測到錯誤後，WorkloadInjector 流程例項將以 Human Task 的形式生成一個 Notification。現在可以通過從 BPC Explorer 選擇 My To-dos 檢視這個任務（圖 14）。
   
   圖 14. 目標端點系統當機 Human Task
   
   
   
4. 通過選擇並單擊 Work on 獲得該任務。從圖 15 的解釋文字以及根源錯誤訊息可以看出，錯誤與佇列管理器 Target_QM 有關。
   
   圖 15. 目標端點系統當機通知訊息
   
   
   
5. 在完成任務前，需要糾正問題並處理失敗的動態同步流。從 WebSphere MQ Explorer 啟動 Target_QM。在非同步 SCA 呼叫期間遇到的錯誤將被作為事件持久化到 Failed Event 子系統中。從管理控制檯導航到 Integration Applications > Failed Event Manager，開啟 Failed Event Manager。單擊 Get all 以獲取所有失敗的事件（圖 16）。
   
   圖 16. 失敗的 Event Manager
   
   
   
6. 單擊 Event ID 連結檢視更多細節（圖 17）。
   
   圖 17. 失敗的事件的細節
   
   
   
7. 可以通過單擊 View business data 檢視資料同步訊息的負載，如果需要的話還可以進行修改（圖 18）。
   
   圖 18. 失敗的 Event Payload
   
   
   

由於您已經找到了問題的根源，因此現在可以重新提交 Failed Event，允許資料同步流完成。觀察訊息是否達到 Target_QM Outbound_Queue，以確定重新提交是否成功。

要繼續執行資料同步，您必須完成未交付的 Human Task。確保選擇了 Task Output Message 中的輸出核取方塊並單擊 Complete。

您現在可以繼續為同步提交訊息，方法就是使用 WebSphere MQ Explorer 將訊息放到 Inbound_Queue。

注意，您可以在任意時刻從 BPC Explorer 的 Process Instances > Administered By Me 皮膚終止流程例項。

結束語

WebSphere Process Server 提供了一個功能豐富的、基於元件的程式設計模型，它為廣泛的業務問題實現模組化解決方案。整合多個不同端點系統通常需要使用這些解決方案。因此，負責解決方案設計的整合架構師必須考慮到端點系統之間的操作差異，比如可用性和並行處理能力。這篇文章描述瞭如何使用 Process Server 程式設計模型實現一種智慧的儲存和轉發功能，從而在目標端點系統出現意外故障時仍然能夠提供接近實時的響應性。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-624285/，如需轉載，請註明出處，否則將追究法律責任。