在多叢集WPC單元中配置高效的訊息傳遞

Matt Roberts, 高階 IT 專家, IBM Hursley

引言

隨著客戶開始使用 IBM® WebSphere® Process Server（以下稱為 Process Server）來管理越來越多的業務流程或實現其自動化，將所有必要的模組都包含在單個黃金部署拓撲中的做法經常變得不再可行。為了處理這個問題，可以建立一組新的黃金叢集，並在兩個目標之間分配模組，但此方法需要仔細考慮 SCA 執行時和應用程式模組使用 WebSphere Service Integration Bus（以下稱為 SIBus）訊息傳遞元件的方式。本文將提供一系列以高效且可維護的方式配置 SIBus 的最佳實踐指南，從而幫助您成功進行實現。

黃金拓撲

本文將提供黃金拓撲的概述，介紹多黃金拓撲中的 SIBus 訊息傳遞，並說明如何在多黃金拓撲環境中配置高效的訊息傳遞連線。

概述

雖然有著各種不同的稱法，包括黃金拓撲、白銀拓撲、全面支援或遠端訊息傳遞，不過大部分 IBM® WebSphere® Process Server 和 WebSphere Enterprise Service Bus 客戶都在使用這樣的生產配置，其中的服務整合匯流排訊息傳遞引擎配置為獨立的 WebSphere 叢集的一部分，Process Server 或 WebSphere ESB 模組承載於此叢集中，如圖 1 中所示。

圖 1. 黃金拓撲

什麼是黃金拓撲？ 有關黃金拓撲、白銀拓撲、全面支援或遠端訊息傳遞的含義的完整細節，請參見在下面參考資料部分提供的連結。

對於此文件中描述的功能，黃金和白銀拓撲彼此相當，都具有獨立的訊息傳遞叢集。此文件全文中均使用黃金拓撲，但是本文中的觀察結果也同樣適用於白銀拓撲。白銀拓撲和黃金拓撲的區別在於其中的 CEI 功能部署到應用程式叢集，而並沒有自己的獨立叢集。

在此拓撲中，應用程式模組部署到應用程式叢集，訊息傳遞叢集中只有單個活動訊息傳遞引擎，如 MEServer1 中所示，它在 MEServer2 中有一個被動對等項，在 MEServer1 出現故障時備用。

圖中所示的叢集連結集提供了獨立調配和管理環境的各個元件的能力，例如，提供應用程式叢集中的伺服器數量，以滿足所安裝的各個應用程式模組的可伸縮性或吞吐量需求。

模組可伸縮性問題

雖然環境拓撲提供了出色的可伸縮性，但是隨著為了滿足業務需求而開發的 SCA 模組不斷增多，越來越多的客戶感到單個叢集連結集已不足以滿足這些模組的需求。

在有些大型生產方案中，SCA 模組的數量達到一百或兩百的情況並不少見。這可能是由於採用了過度細粒度的方法處理模組或服務定義造成的，或者是由於客戶反對對程式碼開發或管理進行劃分來與現有團隊結構相匹配的做法造成的。

在包括大量 SCA 模組的客戶方案中，經常會出現黃金拓撲環境非常勉強地努力滿足專案的非功能需求，例如：

• 應用程式叢集中的伺服器啟動時間長到不能接受，從而使得在生產或開發環境中進行維護之類的管理任務極為費時。
• 部署在應用程式叢集中的應用程式的數量太多，導致可用的 Java™ 堆大小中沒有足夠的空間執行應用程式。
• 服務整合匯流排訊息傳遞引擎啟動或故障轉移的時間長，導致出現不能接受的長時間停機或 ME 不可用的時間內服務不可用。

這些問題是由於每個模組的初始化開銷及訊息傳遞引擎（Messaging Engine，ME）上的負載造成的，這兩個因素都可能隨著應用程式數量的增加而成為阻礙因素。

每個 SCA 應用程式都會導致在訊息傳遞引擎上建立一系列目的地，增加 ME 的啟動邏輯的負載。建立的目的地的數量取決於模組的複雜性和其中使用的操作的型別，經常會導致每個模組建立六個或更多目的地。ME 使用 WebSphere 平臺中的其他服務意味著啟動訊息傳遞引擎的時間長度將以 n² 為係數變化，其中“n”是訊息傳遞引擎本地的目的地的數量。因此，隨著所安裝的 SCA 應用程式的數量的增加，ME 啟動或故障轉移所花的時間也會增加，但是後者增加速度會更快一些。

對於小型到中型規模的目的地數量（上限為約 300 個），訊息傳遞引擎啟動時間的增加通常是可接受的。不過，如果定義的目的地超過了 300 個，或者包括的 SCA 模組超過了 50-60 個，則 n² 增加所帶來的效果將非常明顯，導致 ME 故障轉移時間從以秒計算增加到以分鐘進行計算。

使用多黃金拓撲模式解決可伸縮性問題

解決部署如此眾多的 SCA 應用程式導致的問題的最簡單方法是將應用程式集劃分為兩個或更多獨立的黃金拓撲叢集集（每個應用程式僅部署到一個應用程式叢集），並對每個應用程式叢集採用獨立的 ME 叢集，如下圖中所示。

圖 2. 將應用程式劃分到兩個或更多黃金拓撲副本中

通過將應用程式拆分到多個應用程式叢集，任何給定伺服器上都有必須啟動的應用程式，從而縮短了伺服器啟動的時間，與此類似，由於每個訊息引擎上的本地目的地數量為之前的一半，因此 ME 的啟動和故障轉移時間都應該減少到可以接受的範圍內。

上述設計可以採用兩種方式進行實現：

1. 每個黃金拓撲一個單元
2. 單個單元中配置多個黃金拓撲叢集集

方法 A（多個單元，各自包含一個黃金拓撲的副本）能保證模組彼此獨立執行，不過需要以安裝、配置和維護新單元基礎結構的額外管理開銷為代價。另外，如果在安裝於不同的單元中的模組之間有通訊需求，則不能輕易使用此拓撲，因為需要進行手動配置才能允許此行為。

方法 B（單個單元/多個叢集）避免了額外的配置開銷，但是必須謹慎實施，以確保每個叢集的 Process Server 功能不會彼此干擾；例如，務必注意以下要點：

1. 應用程式叢集必須將“remote SCA destination”位置屬性設定為相關的訊息傳遞引擎叢集，以便在安裝 SCA 模組時正確地將目的地本地化。
2. 每個 ME 叢集中的訊息傳遞引擎應該成為相同 SCA.APPLICATION 和 SCA.SYSTEM 匯流排的成員。對於系統匯流排，這將允許一個叢集中的模組呼叫另一個叢集中的模組；而在應用程式匯流排中，可以節約為每個黃金拓撲副本建立獨立匯流排的管理成本。

即使假定上述配置能正確實現，上面的關係圖中所示的連線模式通常不會完全按照您的預期實現。有關連線過程的描述，請參見下面的如何實際建立 SIBus 連線部分。

多黃金拓撲中的 SIBus 訊息傳遞

如何實際建立 SIBus 連線

圖 2 中所示的所需連線模式的簡化形式如下：

圖 3. 所需連線模式的簡化檢視

從 SCA 模組到 SCA.SYSTEM 或 SCA.APPLICATION 匯流排的每個連線都由 JMS ConnectionFactory、JMS Activation Specification（對於 JMS 訊息驅動的 Bean）或 J2C Resource Adapter Activation Specification（對於內部 SCA 訊息驅動的 Bean）控制。

預設情況下，這些管理專案包含一組屬性，用於告知系統將應用程式連線到指定匯流排上的任意訊息傳遞引擎（系統或應用程式）。對於單元中單個黃金拓撲的情況，這是可以接受的，因為只有一個訊息傳遞引擎供選擇。不過，如果匯流排中有多個 ME，如相同單元中存在多個黃金拓撲的副本的情況，則連線將需要在可用的訊息傳遞引擎之間進行工作負載平衡。

多個訊息傳遞引擎之間的工作負載平衡意味著 Module1 將有 50% 的時間連線到 ME2，以傳送/接收本地化到 ME1 的訊息，如下所示：

圖 4. 交叉連線模式

圖 4 中所示的交叉連線模式會導致在訊息傳遞引擎中建立遠端佇列點（Remote queue points，RQP）。RQP 是執行時構件，對於應用程式傳送到的目的地不由所連線的訊息傳遞引擎承載的情況，由 RQP 對這些訊息進行儲存和管理。在圖 4 中所示的模式中，將建立一個 RQP，用於 ME1 承載的 Module1 的訊息所傳輸到的目的地。

交叉連線模式的缺點

效能

由於使用了在兩個訊息傳遞引擎之間傳輸訊息的可靠協議，而這在應用程式和所需的目的地之間造成了額外的通訊延遲，因此交叉連線模式效率較低。

對於這個交叉連線模式造成的效能降低，很難進行理論預測，不過我們可以很容易地發現，從應用程式所連線的 ME（上面圖 4 中的 ME2）以可靠方式將訊息傳遞到訊息所傳送到的目的地所在的 ME (ME1) 需要額外的跳轉，這樣所帶來的開銷是非常大的。

因此，出於效能考慮，有必要對環境進行配置，以避免交叉連線模式。

可管理性/服務能力

用於連線到訊息傳遞引擎的工作負載管理演算法要求，如果未指定目標屬性，則系統實際上會基於請求的執行時順序對連線進行輪詢。這意味著，很難或不可能預測在什麼地方建立連線，因為連線的目標取決於給定伺服器中所有連線請求的準確順序。

這增加了系統管理的複雜性，因為伺服器之間要建立的連線組並不固定；例如，無法使用 netstat 進行檢視。

這個行為還會導致服務能力問題，因為特定方案的兩次執行可能使用完全不同的連線模式，而導致在考察應用程式是直接連線到其與之通訊的目的地所在的訊息傳遞引擎，還是通過中間訊息傳遞引擎從該目的地獲得訊息時，可能會觀察到不同的執行時行為。

當一個應用程式傳送的訊息未達到佇列供第二個應用程式使用時，就出現了這方面的問題。從外部來看，訊息似乎丟失了；事實上，此訊息安全地儲存在第一個應用程式連線到的訊息傳遞引擎上的遠端佇列點上，在等待傳輸到目的地所在的訊息傳遞引擎。如果不知道第一個應用程式連線到哪個 ME，則確認訊息等待的位置並解決問題將非常費時。

出於一致性的原因，非常需要按照如下所示建立防止交叉連線模式的目標連線需求，從而形成強制的連線路徑。

次要程式碼路徑

與直接連線到承載目的地的訊息引擎的應用程式相比，交叉連線 到其他訊息傳遞引擎的應用程式使用了不同（且更為複雜）的程式碼路徑。

在 Process Server 和 WebSphere ESB 的早期版本中，有些客戶在由於疏忽而使用了交叉連線模式（會影響應用程式內的訊息流）時遇到了功能問題。在第一代故障資料捕獲記錄（Failure Data Capture Records，FFDC）中，這種問題經常包含類或方法名稱，涉及遠端使用者、遠端佇列點 或保證交付 之類的文字。

IBM 已經修復了這些問題，因此務必確保向單元（隸屬一個或多個匯流排）中所有伺服器應用最新的服務修補程式。這些修補程式在下面的步驟 1 中描述，強烈建議將其應用到環境中的所有節點。

在多黃金拓撲環境中配置高效的訊息傳遞連線

應用程式交叉連線時用於解決問題的簡單方法是，配置 ConnectionFactory 或 ActivationSpecification 物件的必要屬性，以告知系統連線到相應的訊息傳遞引擎。

此過程包含三個步驟：

步驟 1：應用相關修補程式包

除了本文提供的指令碼執行的配置更改外，還必須按照如下所述應用一系列服務更新，這些更新處理 Process Server 基礎結構其他領域的同類交叉連線模式。

• 對於 Process Server v6.0.2，強烈建議使用包括 WebSphere Application Server 的 v6.0.2.27 或更高版本（Process Server v6.0.2.4 或更高版本）的修補程式包，因為其中包括一系列用於此方案的關鍵修補程式，是下面描述的 iFixe 之一的先決條件。
• JR29484 及其相應的先決條件：SCA 目標重要性
• JR30198：失敗的事件管理器目標重要性
• PK71156：SIBus 恢復修補程式

請注意，在應用 JR29484 之後，按照 JR29484 的文件中所述，必須在各個 Process Server 應用程式叢集的叢集範圍內定義一個 WebSphere 變數，其名稱為 SCA_TARGET_SIGNIFICANCE，值為 Required 或 Preferred。

有關這些修補程式的進一步資訊，請參見參考資料部分提供的連結。

步驟 2：建立屬性定義（僅限於 Process Server v6.0.2）

重要說明：在進行任何配置更改前，應該建立 Process Server 配置的備份！

在 WebSphere Application Server V6.1（及關聯的堆疊產品）中，配置此連線行為所需的屬性已經進行了預定義，可供管理員進行配置。如果使用 v6.1 產品，則直接進入步驟 3。

如果配置檔案是使用 v6.0.2.4 之前的 Process Server（具體來說，使用 v6.0.2.25 之前的 Application Server 版本）建立的，則屬性定義不會自動生成。如果配置檔案是使用 Process Server v6.0.2.3 或更早版本建立的（即使後來已經升級到了 Process Server v6.0.2.4 或更高版本），則必須遵循這些說明來定義屬性。

設定屬性定義所需的配置步驟在 PK54128 下描述，在下面的參考資料部分提供了相應的連結。此網頁介紹如何使用管理控制檯定義必要的屬性定義，不過使用 Service 團隊提供的 JACL 指令碼“SIBUpdateResourceAdapter.jacl”和“SIBInternalUpdateResourceAdapter.jacl”更為簡單，且不容易出錯，能實現相同的配置。

此網頁還說明了，有必要在建立配置檔案前配置屬性，不過這裡所給的指令碼並沒有這個限制，可以在無需重新建立任何定義的情況下應用到現有配置檔案。下載部分也提供了用於下載這些 JACL 指令碼的連結。

對於希望定義屬性的單元，必須使用以下命令執行一次這些指令碼（有關完整細節，請參見“參考資料”部分提供的連結所指向的文件）。

清單 1. 執行指令碼來建立目標屬性定義

				
wsadmin ¨Cf SIBUpdateResourceAdapter.jacl
wsadmin ¨Cf SIBInternalUpdateResourceAdapter.jacl

步驟 3：配置目標屬性

現在已經定義了屬性，接下來必須使用相對於您的環境的必要環境特定變數對其進行配置。這包括對兩個（或更多）應用程式叢集的叢集範圍內定義的每個 JMS ConnectionFactory、QueueConnectionFactory、TopicConnectionFactory、ActivationSpecification 和 J2C ActivationSpecification 進行以下更改：

• 將 TargetType 設定為 BusMember：我們希望連線到相關 Process Server ME 叢集中的訊息傳遞引擎。
• 將 Target 設定為 ME 叢集的名稱。
• 將 Significance for Connection Factories 設定為“Preferred”或“Required”，具體取決於您的應用程式環境（有關選擇這兩個選項的幫助，請參見後面的內容）。對於 ActivationSpecifications，其重要性應始終設定為“Required”。

現在這個活動可能會非常耗時，因此本文在下載部分提供了名為“configure_MultipleGold_Messaging.jacl”的指令碼，用於幫助您自動執行此工作。

此外，為了避免必須每次安裝新應用程式或進行配置後必須重新進行此活動，指令碼將更新指定物件的 admin 物件模板，從而使建立的任意新物件都會自動選取合適的預設值。因此，安裝新應用程式時，除非開發人員或管理員專門進行了另行配置，否則在相應範圍內（例如，群集上）建立的任何 ActivationSpecification 物件都將自動選取關聯的訊息傳遞引擎作為其目標。

Preferred 和 Required 的區別何在？

目標重要性屬性提供的基本行為如下：

• Required：連線到其他目標屬性（例如，匯流排成員）中指定的目標。如果此目標不可用，則連線失敗。
• Preferred：嘗試連線到其他目標屬性中指定的目標。如果該目標不可用，則嘗試連線到相同匯流排中執行的任意訊息傳遞引擎。

請注意，如果管理員設定了“Preferred”，而指定的目標在建立連線時不可用，則將建立到其他 ME 的連線。如果稍後原始（首選）目標再次可用，不會自動丟棄連線並進行重新建立；應用程式將保持連線到非首選 ME，直到該連線由於任何原因斷開為止。對於長期存在的連線，或使用連線池技術時，這個行為可能不盡人意，這種情形應該使用“Required”目標重要性。

選擇使用 Preferred 還是 Required

可以在兩種型別的物件上設定目標屬性：連線工廠和啟用規範。

啟用規範
啟用規範為訊息驅動的 Bean（Message Driven Bean，MDB）提供必要的配置細節，幷包括關於在何處連線以及從哪個目的地使用訊息的資訊。啟用規範可以由開發人員/管理員建立，也可以由 SCA 基礎結構作為 SCA 模組定義的一部分建立。

無論 Activation Specification 如何建立，目的地的位置都是在配置時固定的，因此我們可以準確地知道 MDB 應該連線到哪個匯流排成員。連線到任何其他匯流排成員將導致上面所述的交叉連線模式，因為將嘗試通過已連線到的匯流排成員從訊息傳遞引擎檢索訊息。

如果承載目的地的訊息傳遞引擎沒有執行，即使連線到其他訊息傳遞引擎，MDB 也無法使用訊息，因為該 ME 仍然需要聯絡這個不可用的 ME 來檢索訊息。因此，對於 ActivationSpecifications，我們應始終將重要性設定為“Required”，以獲得最佳的效能。（請注意，無論指定的引數如何，configured_MultipleGold_Messaging.jacl 指令碼會始終將啟用規範重要性設定為“Required”，而此選項僅適用於連線工廠物件。）

連線工廠
連線工廠用於傳送或接收訊息，將使用的目的地在配置時未知。

如果管理員知道特定的連線工廠將僅用於使用訊息，則可以應用與上面啟用規範相同的邏輯，應該為目的地所在的匯流排成員設定“Required”目標。

如果連線工廠將僅用於傳送訊息，則通常最好將重要性設定為“Preferred”，以獲得更好的容錯能力（訊息將在匯流排中有任意訊息傳遞引擎可用的情況下傳送）。對此，有下面兩個例外，這兩種情況下需要使用“Required”設定：

1. 前一部分所述的關於這些主體的可管理性/服務能力。
2. 訊息順序或事件序列。如果使用了“Preferred”設定，則應用程式在出現故障的情況下可能會通過其他路徑傳送訊息，從而無法保證訊息到達目的地的順序。如果需要考慮訊息順序，則應該始終使用“Required”。

如何執行目標屬性配置指令碼

重要說明：在進行任何配置更改前，應該建立 Process Server 配置的備份！

下面的清單中提供瞭如何執行隨本文提供的配置指令碼的簡單示例，用於自動進行上述必要的配置更改。

清單 2. 執行指令碼來配置目標屬性定義

				
wsadmin -f configure_MultipleGold_Messaging.jacl CORRECT AppCluster1 Required

... 其中，AppCluster1 是之前配置的 Process Server 應用程式叢集的名稱。

接下來同步各個必要的節點，然後重新啟動應用程式叢集中的每個伺服器。如果不想重啟訊息傳遞叢集伺服器，可以不重啟。

配置更改生效後，任何現有（或新的）應用程式都只會連線到在關聯訊息傳遞叢集中的訊息傳遞引擎，這樣更為高效，而且避免了上面所述的缺點。

執行指令碼的場合

對於系統中的每個 Process Server 應用程式，都必須執行一次此指令碼。因此，如果您的環境有兩個黃金拓撲例項，則將需要執行此指令碼兩次，並分別提供相應的叢集名稱引數。

如果在單元中有 Process Server 叢集之外的其他伺服器，而這些伺服器包括連線工廠或啟用規範物件的定義，則還應該遵循清單 6 中提供的針對非叢集化伺服器的說明，按照與上面所述類似的方式配置這些物件的目標屬性。

在開始功能或效能測試之前，必須將指令碼作為標準配置流程的一部分執行，以確保環境與將在生產環境中使用的環境匹配。

執行指令碼一次之後，所有現有應用程式都得到了正確配置，並會為安裝到 Process Server 應用程式叢集的任何新應用程式建立相應的預設設定並在此範圍內建立其資源。

在大多數情況下，預設設定對所部署的新應用程式都將是正確的。不過，為了確保設定了正確的配置，應該考慮在每批新應用程式安裝之後重新執行一次指令碼，以檢查預設設定是否真正得到了正確應用。

執行指令碼時，會輸出所找到的配置的摘要，以及進行了哪些更改或建議進行哪些更改。下面示例控制檯輸出部分提供了此摘要的示例。

資源範圍需求

為了使指令碼正確工作，必須能夠自動地確定哪些連線工廠和啟用規範資源與應用程式/訊息傳遞引擎叢集關聯。為了完成此工作，要假設在應用程式叢集中的叢集範圍定義了所有必要的資源，SCA 模組自動建立的資源通常是這樣。

如果有在其他範圍配置的資源（例如，在單元範圍），而這些資源將由 Process Server 應用程式叢集中的應用程式使用，則強烈建議在執行指令碼之前在相應的應用程式叢集範圍重新定義這些資源。

重要說明：此指令碼包括了用於手動指定資源定義的範圍的選項（請參見指令碼頂部的註釋）。不過，這在處理單元範圍內的資源時非常不足，因為不非常謹慎，就可能在為第二個叢集執行此指令碼時重寫新屬性值。由於這個原因，本文並不對這個選項進行深入討論，並假定所有資源都在相應的叢集範圍定義。

使用配置指令碼

此指令碼使用以下命令執行：

清單 3. 執行指令碼來配置目標屬性定義

				
wsadmin.sh -f configure_MultipleGold_Messaging.jacl   

請注意，這裡並不會詳細討論可選的 scopeOverride 引數，因為其使用並不代表最佳實踐，請參見前一部分的說明。

引數文件

下面將詳細討論每個引數。

表 1. mode 引數的說明

指令碼執行示例

在下面的示例中，假定部署管理器在與執行指令碼的會話相同的主機的預設埠執行。如果您的環境中不是這樣，則必須提供 -host 和 -port 引數，以便管理客戶端連線到部署管理器。

清單 4. 將配置更新為 Required

					
wsadmin -f configure_MultipleGold_Messaging.jacl CORRECT env.AppTarget Required

清單 5. 驗證連線工廠的配置是否使用 Preferred 重要性

					
wsadmin -f configure_MultipleGold_Messaging.jacl VALIDATE env.AppTarget Preferred

將檢查啟用規範，以確定是否與相關目的地的計算主位置匹配，且具有 Required 目標（請參見選擇使用 Preferred 還是 Required）。 將檢查 JMS Connection Factory 物件，確定是否使用應用程式叢集的關聯 ME 叢集的匯流排成員的名稱將其設定為 BusMember/Preferred。

重要說明：請注意，當使用 Validate 選項執行指令碼時，將在指令碼退出時看到一個或多個以下警告訊息：

--------------------------------------------------------
No changes have been saved to the configuration.
--------------------------------------------------------

WASX7309W: No "save" was performed before the script. "configure_MultipleGold_M
essaging.jacl" exited; configuration changes will not be saved.

這些訊息確認沒有對配置進行更改，完全可以將其忽略。

清單 6. 更新非叢集化伺服器的配置（全部在一行上）

					
wsadmin -f configure_MultipleGold_Messaging.jacl CORRECT server1 Required
    /Node:myNode01/Server:server1/

這些非叢集化伺服器還可能在其伺服器範圍內定義訊息傳遞資源，並且必須採用與應用程式叢集類似的方式配置，這可以通過使用上面所示示例實現。

在此伺服器範圍定義的活動規範將自動獲得承載正確計算的目的地的匯流排成員的名稱。

要為在此伺服器範圍定義的 JMS ConnectionFactory 物件定義目標匯流排成員，管理員必須在伺服器範圍手動配置一個 WebSphere 變數，將其名稱設定為“JMSCF_TARGET_BUS_MEMBER”，值為目標匯流排成員名稱。例如，要指向同一個非叢集化伺服器上的所有 JMS CF 物件，必須使用“node.server”語法：例如，在上面所示的指令碼呼叫中使用“myNode01.server1”指示伺服器。如果目標匯流排成員是叢集，則將使用叢集名稱作為此變數的值。

如果未設定 JMSCF_TARGET_BUS_MEMBER 變數，則連線工廠物件將保留空目標欄位，以便在執行時可用的訊息傳遞引擎集中進行工作負載平衡。

已知的約束和限制

• ConnectionFactory 和 ActivationSpecification 名稱（顯示名稱，而不是 JNDI 名稱）包含空格，使得很難或不可能對專案列表進行解析。推薦的解決方法是刪除空格。
• 如果資源在單元範圍定義，則指令碼可以確定哪些資源應該與哪個叢集關聯。最佳實踐是在相應叢集範圍內定義資源

指令碼使用示例

管理控制檯示例

在執行本文描述的步驟之前，預設情況下，啟用規範或連線工廠將不會設定目標，如管理皮膚中的 JMS Activation Specification 的螢幕截圖中所示。

圖 5. 管理控制檯中目標屬性的預設（未配置）值

請注意，Target 欄位為空，而 Target Type 和 Target Significance 欄位使用預設值“Bus member name”和“Preferred”。除非在 Target 欄位中輸入名稱，否則不會考慮 Target Type 和 Target Significance 的值。

現在，請對相應的應用程式叢集執行配置指令碼（可以在上面的截圖中看到）。

wsadmin -f configure_MultipleGold_Messaging.jacl CORRECT mattEnv.AppTarget Required	

如果從控制檯登出，然後再次登入（以強制新配置更改生效），並再次檢視相同的物件，您將會發現值已經通過執行指令碼更新了，如下所示：

圖 6. 由指令碼進行配置之後的目標屬性

控制檯輸出示例

以下顯示了執行指令碼的控制檯輸出示例。

WASX7209I: Connected to process "dmgr" on node KADGINCellManager01 using SOAP connector;
  The type of process is: DeploymentManager
WASX7303I: The following options are passed to the scripting environment and are 
  available as arguments that are stored in the argv variable: "[CORRECT, 
  mattEnv.AppTarget, Required]"
 
Precondition validation:
  - Found application cluster OK
  - Found associated ME cluster name: mattEnv.Messaging
 

--------------------------------------------------------
Found Platform. Messaging Component SPI Resource Adapter
--------------------------------------------------------

  * Found activation spec: sca/SOACoreIVT/ActivationSpec
          busName: SCA.SYSTEM.KADGINCell01.Bus
      destination: sca/SOACoreIVT
           target: mattEnv.Messaging (current config)
       targetType: BusMember (current config)
     targetSignif: Required (current config)
        BusMember: mattEnv.Messaging (calculated)
 
  * Found activation spec: jms/act/adapterServerAS
          busName: SCA.APPLICATION.KADGINCell01.Bus
      destination: myQueue
           target: KADGINNode01.server1 (current config)
       targetType: BusMember (current config)
     targetSignif: Required (current config)
        BusMember: KADGINNode01.server1 (calculated)
 
  * Found activation spec: corespi/topicTest
          busName: SCA.APPLICATION.KADGINCell01.Bus
      destination: Default.Topic.Space
           target: mattEnv.Messaging (current config)
       targetType: BusMember (current config)
     targetSignif: Required (current config)
       durability: NonDurable
 
  * Found an activation spec TEMPLATE on the RA
      - Setting value of targetType to BusMember
      - Setting value of target to mattEnv.Messaging
      - Setting value of targetSignificance to Required


--------------------------------------------------------
Found SIB JMS Resource Adapter
--------------------------------------------------------

  * Found activation spec: jms/cei/QueueActivationSpec
         jndiDest: jms/cei/EventQueue
          busName: CommonEventInfrastructure_Bus
      destination: mattEnv.Messaging.CommonEventInfrastructureQueueDestination
           target: mattEnv.Messaging (current config)
       targetType: BusMember (current config)
     targetSignif: Preferred (current config)
        BusMember: mattEnv.Messaging (calculated)
         - WARNING: Target significance is not optimal in current config
         - FIXED: Target significance updated to Required
 
  * Found activation spec: actspec/MattTest
         jndiDest: jms/fred
          busName: SCA.APPLICATION.KADGINCell01.Bus
      destination: adapterQueue
           target: anIncorrectTarget (current config)
       targetType: ME (current config)
     targetSignif: Preferred (current config)
        BusMember: KADGINNode01.server1 (calculated)
         - WARNING: Target name is not optimal in current config
         - FIXED: Target name updated to KADGINNode01.server1
         - WARNING: Target type is not optimal in current config
         - FIXED: Target type updated to BusMember
         - WARNING: Target significance is not optimal in current config
         - FIXED: Target significance updated to Required
 
  * Found activation spec: jms/act/TopicAS
         jndiDest: jms/myTopic
          busName: SCA.APPLICATION.KADGINCell01.Bus
      destination: Default.Topic.Space
           target: mattEnv.Messaging (current config)
       targetType: BusMember (current config)
     targetSignif: Required (current config)
       durability: NonDurable
 
  * Found a JMS CF: jms/sampleCF
           target:  (current config)
         - WARNING: Target name is not optimal in current config
         - FIXED: Target name updated to mattEnv.Messaging
     targetSignif: Preferred (current config)
         - WARNING: Target significance is incorrect
         - FIXED: Target significance updated to Required
       targetType: BusMember (current config)
 
  * Found an activation spec TEMPLATE on the RA
      - Setting value of target to mattEnv.Messaging
      - Setting value of targetSignificance to Required
      - Setting value of targetType to BusMember

  * Found a JMS TEMPLATE on the RA
      - Setting value of Target to mattEnv.Messaging
      - Setting value of TargetSignificance to Required
      - Setting value of TargetType to BusMember

  * Found a JMS TEMPLATE on the RA
      - Setting value of Target to mattEnv.Messaging
      - Setting value of TargetSignificance to Required
      - Setting value of TargetType to BusMember

  * Found a JMS TEMPLATE on the RA
      - Setting value of Target to mattEnv.Messaging
      - Setting value of TargetSignificance to Required
      - Setting value of TargetType to BusMember

 
--------------------------------------------------------
Save any configuration changes that were made.
--------------------------------------------------------

結束語

本文介紹了一系列步驟，用於確保單個 WebSphere 單元具有多個黃金部署拓撲時大型 WebSphere Process Server 環境遵循相關的最佳實踐。我們討論了在這種環境中使用 Service Integration Bus 訊息傳遞時潛在的缺陷，並提供了一個指令碼，可用於自動配置訊息傳遞資源，使其遵循最佳實踐。

通過遵循本文中所述的步驟，您可以利用我們通過與實現了這種型別的拓撲的領先客戶協作時獲得的經驗教訓，幫助確保您的部署成功。

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