WebSphere Message Broker V7 上的影響分析

Suman Kalia 是位於加拿大安大略省多倫多市的 IBM 多倫多實驗室的一名諮詢軟體開發人員。他是 WebSphere Business Integration Message Broker 的訊息集開發工具團隊的負責人。

Kevin Quan 是位於多倫多市的 IBM 加拿大軟體實驗室的 WebSphere Message Broker 工具包團隊的一名軟體開發人員。他擁有加拿大滑鐵盧大學的電子工程學士學位和計算機工程碩士學位。

簡介： 開發和維護期間的關鍵問題是 “what-if” 分析：如果您變更一個專案，那麼為了避免錯誤和保持一致性其他專案的什麼是您必須變更的？新的 WebSphere Message Broker V7 影響分析功能給出了答案。

什麼是影響分析？

影響分析就是可能會受到其他專案變更影響的開發專案的識別。因為識別專案之間關係的自動化功能在開發過程中可以節省大量時間和麻煩，所以專案之間的連結可能並不明顯。

例如，在 IBM® WebSphere® Message Broker（以後稱作 Message Broker）環境中，如果您有一個使用名為 input 的訊息的訊息對映，則在訊息對映和 input 之間存在一個關係。如果將名稱 input 變更為 request，則訊息對映所指的訊息將不再被發現，因為在訊息對映和訊息 input 之間存在依賴關係，所以將在訊息對映上導致驗證錯誤。

如果您是一位準備更改開發專案的應用程式開發人員，影響分析可告訴您除了最初的變更以外還需要執行什麼操作，以便在依賴的專案上消除並避免潛在的驗證錯誤。Message Broker 變更那些支援影響分析的操作，包括：

• 在專案內重新命名專案或構造
• 在專案內將專案或構造移動到另外的位置

擴充套件前面的例子，如果您正在與使用了訊息 input 的訊息對映一起工作，您就需要重新命名該訊息為 request，影響分析功能將報告重新命名 input 為 request 的要求，該要求可更新訊息對映。

影響分析只報告什麼專案可能會受到變更的影響 — 其不執行變更。此外，影響分析只報告那些直接依賴可能變更的構造的專案。例如，如果您擁有使用訊息對映的訊息流，因為這是一種間接的關係，所以重新命名的 input 將不把訊息流作為潛在的影響列出。

因為關係資訊在索引系統內被編目，所以影響分析可在工作空間內識別依賴關係。為了充實此目錄，在工作空間的專案上將執行一個被稱作索引的流程。

應用程式的描述

為了說明在 Message Broker 上使用影響分析的優點，我提供了一個 zip 檔案的示例，您可以在本文的底部 下載 它。在此示例中，兩種銀行操作（存款和提款）已經被模式化。這些操作可通過傳送一個 SOAP 訊息給訊息流來啟動。該 SOAP 訊息的格式通過 WSDL 定義，如圖 1 所示：

圖 1. WSDL 定義操作 SOAP 訊息的格式

在呼叫存款或提款操作時，Message Broker 將輸入資訊轉換成可被銀行後端系統接受的訊息格式。在這個示例中，為了簡單起見，一個子流程模擬連線到銀行後端系統。

通過使用 ESQL 程式碼，來自銀行後端系統的響應被返回且一個 SOAP 訊息已構造，以便為該操作產生一個回覆訊息。圖 2 顯示了訊息流的概況，BankOperationFlow.msgflow 實現了剛才所描述的場景：

圖 2. 描述示例場景的訊息流

圖 1 中描述的 WSDL 被匯入到訊息集中，且 MXSD 定義包含了 transferIn 和 transferOut 訊息的 ops.mxsd，其通過匯入建立。在執行存款時 transferIn 是輸入訊息，而在請求提款時 transferOut 是被使用的訊息。

模擬的後端系統採用訊息 changeRequest 作為輸入並返回 updateConfirmation。這些都在檔案 BackendOperationMessages.mxsd 中被定義。

根據被呼叫的操作，訊息 transferIn 或 transferOut 必須被對映到訊息 changeRequest 中以便將變更持久化到儲存系統中。此對映的示例如圖 3 所示：

圖 3. 執行對映以便建立適用於後端系統的訊息格式的示例

來自 transferOut 訊息的對映是相似的。因為本文的重點不是對映，所以僅使用一個直觀的對映示例進行說明。

一旦訊息流通過呼叫模擬子流程更新了後端上的資訊，則主流程會傳遞控制到 Compute（計算）節點，其在 ESQL 內呼叫模組以確定變更是否成功。

ESQL 的第二個功能是通過從 updateConfirmation 訊息複製欄位來構建 SOAP 回覆訊息。以下是 ESQL 程式碼：

圖 4. 構建 SOAP 回覆訊息的 ESQL 程式碼段

雖然這個應用程式沒有任何驗證錯誤，但是建立它是為了反映正在開發的應用程式的狀態；也就是說，專案的一些位置並沒有遵循最佳實踐，且一些構造沒有清晰地命名。本文為您展示瞭如何使用影響分析來幫助您修改保持應用程式最終有效狀態的專案和構造。

影響分析的先決條件

為了正常執行，影響分析需要建立並維持一個在開發工作空間上各專案之間關係的索引。如果沒有這個索引，影響分析就無法執行，因為它無法在專案之間識別關係。同樣，它無法識別新建立的依賴關係，也無法報告那些不再存在的對專案的修改的依賴關係。為了保持當前的索引，無論何時建立專案 Message Broker 都將索引一個專案，並啟動已提供的此索引。

在新的工作空間，或從以前版本的 Message Broker 遷移而來的工作空間，在預設情況下禁用索引，且在建立專案時索引將不會發生。當從一個新的或遷移的工作空間處工作時，您必須在使用影響分析以前啟動索引。在 Development Toolkit（開發工具包）的 Window（視窗）選單下，轉到 Preferences（首選項）對話方塊並選擇 Broker Development => Impact Analysis：

圖 5. 控制索引是否在 Message Broker 中發生的首選項頁面

此 Impact Analysis 子選單列出了影響分析可以為所選專案進行分析的變更。如果該專案不支援影響分析，則此子選單將不顯示。

圖 6. Impact Analysis 子選單

呼叫影響分析的第二種方法是在編輯器內選擇構造並呼叫與上下文相關的 Impact Analysis 選單。正如第一種選擇那樣，它只出現在那些支援影響分析的構造上。在 Message Broker V7.0 中，來自編輯器內的影響分析支援僅在訊息定義編輯器 (Message Definition Editor) 中可用。

呼叫影響分析的示例如下面的圖 7 所示。引用構造（如元素引用和組引用）無法通過其他專案引用，因此在引用專案上 Impact Analysis 子選單不出現。為了說明此概念，請檢視如圖 7 所示的訊息 transferIn 上的元素引用 tns:id。這不是一個全域性性的元素定義而是一個全域性性元素 id（列於 Elements and Attributes（元素和屬性）下）的元素引用。如果您在 transferIn 下的 tns:id 上單擊右鍵，則上下文選單中將不會有 Impact Analysis 子選單。然而，如果您在 Elements and Attributes 下的 id 上單擊右鍵，您將會在上下文選單內看到 Impact Analysis 子選單：

圖 7. 通過訊息定義編輯器呼叫影響分析

您可以在應用程式示例內對許多不同型別的物件呼叫影響分析。本文重點介紹兩個重新命名的變更和一個移動的變更以便提供 Message Broker V7.0 功能的概述。在本文的後面，您可以作出一系列其他的變更以瞭解有關影響分析的更多資訊。

執行影響分析 — 重新命名

本部分為您顯示如何重新命名一個專案，即您可以這樣做的原因，如當前的名稱不是描述正在執行的功能。通過 transferIn 訊息，該名稱不描述實際操作（存款），因此您可能想要將它重新命名為一個更合乎邏輯且直觀的名稱。重新命名的另外一個原因可能是 Web 服務的外部呼叫方可能已經為輸入的 SOAP 訊息要求了不同的格式，即將會要求變更 transferIn 名稱。

為了檢查重新命名的 transferIn 可能會影響其他的專案和構造什麼，您可以在 transferIn 訊息上進行影響分析：

1. 在訊息定義編輯器內開啟訊息定義 ops.mxsd。
2. 在 Overview 標籤中的 Messages 部分下的 transferIn 定義上單擊右鍵。
3. 選擇 Impact Analysis 子選單上的 Rename。

一旦執行了這些操作，一個要求構造新名稱的對話方塊就會開啟，如下面的圖 8 所示。在這種情況下，請輸入名稱 depositRequest 並選擇 Analyze Impact：

圖 8. 影響分析 — 要求構造新名稱的 Rename Artifact 對話方塊

下列圖 9 顯示帶有分析結果的模式對話方塊。在此視窗內有三個表，用帶顏色的數字 1、2 和 3 表示，每一個描述如下：

圖 9. 來自重新命名的影響分析的結果

1. 表 1 列出了這些分析結果所屬的操作。
2. 表 2 列出了初始的變更（也稱作主要變更），它們是為執行第一張表中指定的操作而必須執行的操作。初始變更表上的每一行都表示一個單一的操作，包括其上必須執行變更的檔案的位置，以及必須做什麼的描述。在此示例中，該操作就是重新命名 transferIn 為 depositRequest 且因此必須執行的操作是將訊息定義名稱從 transferIn 變更為 depositRequest。前兩個表都沒有提供有關將被此變更影響的專案的任何資訊（在執行影響分析時這是我們最感興趣的事情）。
3. 表 3 列出了潛在的影響（也稱為次要影響）。此表中的專案依賴正在經歷變更的構造。像表 2 那樣，除主要變更以外，表 3 中的每一行都描述了一個應該執行的單一操作以避免驗證錯誤。同樣地，每一行上的資訊可準確地識別哪個檔案必須更新且在此檔案中需要更新什麼。滾動表到右側以顯示每項操作的更多詳細說明。例如，訊息對映的變更所包含的詳細資訊：

Renaming message '{http://ImpactAnalysis/Bank}transferIn' will impact file 
'/BankMF/impactanalysis/bank/BankOperationsFlow_Convert_Withdrawal.msgmap', in message
map 'BankOperationsFlow_Convert_Withdrawal', at location '$source, accountID, amount

在某些情況下，不是所有的次要影響都會被報告。圖 9 中名為數字 4 的連結連結到資訊中心中對一些限制的描述。

重要事項： WebSphere Message Broker 影響分析無法實際地執行任何變更。使用影響分析報告作為指南以確定什麼需要變更。

從影響分析結果中生成報告

如果您點選上面圖 9 中 Impact Analysis 對話方塊底部的 Copy Analysis To Clipboard 按鈕，則整個報告將會被複制到剪貼簿，從那裡您可以貼上報告到外部應用程式以作為一個清單來執行變更。如果您將報告貼上到支援表的應用程式中，如字處理或電子表格應用程式，則將以表格式輸出，如圖 10 所示：

圖 10. 複製到電子表格的影響分析報告

如果您貼上報告到通用文字編輯器，則表格式可能不存在。

影響分析的侷限性

影響分析報告非常適用於識別需要做出的變更。現在嘗試變更訊息定義名稱（初始變更）和全域性性元素（在這種情況下，當訊息被重新命名時會自動重新命名全域性性元素）。請注意在您做出了這兩個變更以後，在訊息集中會出現一個錯誤，如圖 11 所示。

圖 11. 執行影響分析變更以後的工作空間

由於您剛剛做出了變更，因此在可部署的 WSDL 上會有一個錯誤，這是因為元素 transferIn 被重新命名為 depositRequest（還記得嗎，影響分析是在訊息而非元素上執行的）。

此示例說明影響分析的一個限制 — 它只報告那些直接依靠正在被變更的構造的專案。在這種情況下，WSDL 依靠元素 transferIn，反過來則要依靠重新命名的訊息 depositRequest。為了防止出現這種情況，請在重新命名元素以前執行第二個影響分析以檢測將要出現的次要影響，如圖 12 所示：

圖 12. 將 WSDL 列為次要影響

在重新命名元素 transferIn 時，可部署的 WSDL BankOperations.wsdl 如所預期的那樣被列為次要影響。雖然訊息定義 transferIn 也被列為次要影響，但這是因為訊息定義和元素的名稱必須一致。

執行影響分析 — 移動

移動專案和構造是可以從影響分析中獲益的另外一種變更。在移動中執行影響分析類似於在重新命名上執行影響分析。第一步是強調專案或構造將被移動，而後呼叫影響分析。移動操作的一個不同之處在於可選擇多個專案或構造（但不能同時），如圖 13 所示：

圖 13. 在多個專案的移動操作上呼叫影響分析

在此示例中，訊息對映 BankOperationsFlow_Convert_Withdrawal.msgmap 和 ESQL 檔案 BankOperationsFlow.esql 都屬於一個名為 testing 的 Broker 架構。這些檔案已經被測試過且需要把他們移動到 Broker 架構 impactanalysis.bank 中。但是在移動它們以前，您需要確定此移動是否會影響其他的專案。

圖 14 顯示了 Impact Analysis — Move Artifact 模式對話方塊。它顯示了將要被分析的專案和構造並讓您指定目標位置而後再點選 Analyze Impact。

圖 14. Impact Analysis — Move Artifact 對話方塊

下一個視窗顯示，基於專案如何移動的分析在前一個頁面中指定。該介面類似於重新命名操作，但是因為不同的場景而使內容不同。因為選擇了多個檔案，所以表 1 擁有多個操作。表 2 列出了主要更改，它們是一些將要被移動的檔案和構造。表 3 列出了次要影響：

圖 15. 在移動一些專案時影響分析的結果

在此示例中存在四個次要影響。兩個影響在 ESQL 檔案自身內，因為這裡有一些對將要被移動的架構範圍常量的引用。在移動一個 ESQL 檔案時，也會移動在 ESQL 檔案內的所有構造。

更重要的次要影響關心的是訊息流 BankOperationFlow.msgflow。訊息流使用訊息對映和 ESQL 檔案二者來轉換訊息格式，因此如果功能已經移動到一個新的位置，則訊息流必須知道其在哪裡。在移動檔案以後，為了使應用程式正確地驗證，訊息流也必須被更新。

影響分析的進一步示例

以上的示例顯示了，在您對專案和構造進行結構性變更時如何在 Message Broker Toolkit 中使用影響分析來識別並解決工作空間內的潛在錯誤。本文中的示例僅顯示少數可變更的專案。對於一系列完整的影響分析的支援構造，請參考下面的 附錄。

為了進一步瞭解影響分析，使用附加示例對各種構造進行變更並觀察效果。表 1 列出了示例應用程式內的影響分析示例和次要影響應該是什麼：

表 1. 示例應用程式內其他影響分析示例的清單

結束語

在 Message Broker 中的專案之間經常有依賴關係。在重新命名或移動一個專案時，依賴其初始名稱或位置的其他專案將報告驗證錯誤。修復這些錯誤是耗費時間的，因此使用 Message Broker V7.0 影響分析功能以便在變更專案以前瞭解針對依賴專案的變更範圍，這可以為您節省大量的時間和工作。影響分析功能可以生成一份需要在次要專案上執行的附加操作的外部報告並充當那些需要進行的變更的記錄。

附錄 支援和不支援的專案和構造

表 2 列出了那些在 Message Broker V7.0 中支援影響分析的專案和構造（換句話說，這些專案和構造可能是主要變更），表 2 還顯示每種專案型別可以在哪裡呼叫影響分析：

表 2. 可以執行影響分析的專案和構造以及在何處呼叫影響分析

相反，表 3 列出了對錶 2 中專案有依賴關係的專案和構造。表 3 中的這些專案可報告為次要影響：

表 3. 可能被報告為次要影響的專案和構造的清單

原文連結：http://www.ibm.com/developerworks/cn/websphere/library/techarticles/1007_kalia/1007_kalia.html

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