WebSphere Message Broker 実行モデルは、一連のノードを介してメッセージ・フローを実行するのに使用されるシステムです。
実行グループが初期化されると、ランタイムに対して適切な LIL が使用可能になります。
実行グループ・ランタイム・プロセスが開始し、専用構成スレッドを生み出します。
メッセージ・フロー実行環境では、メッセージ・フローはスレッド・セーフです。
逐次化の問題を考慮しなくても、
多数のスレッド上で並行してメッセージ・フローを実行することができます。
インプリメントするユーザー定義ノードは、このスレッド化モデルと妥協するべきではありません。
以下の点に注意してください。
- メッセージ・フローに送信される入力メッセージは、それを受け取ったスレッドによってのみ
処理されます。メッセージ処理中には、スレッドまたはコンテキストの交換は行われません。
- メッセージ・フローがアクセスするデータ構造は、1 つのスレッドにしか可視になりません。
これらのデータ構造は、処理中のメッセージの存続期間のみ存在します。
- メッセージ・フローの単一インスタンスは、メッセージ・フロー・スレッド・プールの
すべてのスレッド間で共用されます。
これは、状態がないという点で、メッセージ・フロー・ノードの動作に関連します。
- 実行グループのメモリー要件は、より多くの OS スレッド上でメッセージ・フローを実行しても、
過度に影響を受けることはありません。
- メッセージ・フロー実行環境は、概念的にはプロシージャー型プログラミングと類似しています。
メッセージ・フローに挿入するノードは、
関数呼び出しインターフェースを使って呼び出されるサブルーチンのようなものです。
しかし、パラメーターが入力メッセージ・データの形式で渡される「呼び出し - 戻り」
インターフェースというよりは、WebSphere Message Broker の実行モデルは「伝搬して戻る」モデルと言えます。
- WebSphere Message Broker メッセージ・フローは本質的にスレッド・セーフで、
メッセージ・フローは複数のスレッド上で並行して実行することができます。
例えば、ユーザー定義ノードを使用してメッセージを処理しており、
さらにユーザー定義のパーサーを使用して着信メッセージを解析している場合、
ノードとパーサーの両方にインプリメンテーション関数が入ります。
ブローカーは、特定のイベントの発生時にこれらのインプリメンテーション関数を呼び出すか、
またはコールバックします。
入力メッセージがその入力ノードでブローカーに受け取られると、
そのメッセージはユーザー定義のノードに送信されます。
- C ノードの場合、ブローカーは、ユーザー定義のノードのために cniEvaluate 関数を呼び出します。
cniEvaluate 関数についての詳細は、cniCreateNodeContextを参照してください。
- Java ノードの場合、ブローカーは、ユーザー定義のノードによりインプリメントされている evaluate メソッドを呼び出します。
ノードがメッセージを照会して、それをどうするか決定する場合、C ユーティリティー関数または Java メソッドのどちらか、そのノードを作成した言語に適切な方を呼び出します。
その後、ブローカーはインプリメンテーション関数の 1 つでユーザー定義のパーサーを呼び出します。
これは、パーサーが WebSphere Message Broker 解析ツリーの作成を開始するように指示します。
パーサーは、解析ツリーでエレメントを作成するユーティリティー関数を呼び出すことによって、ツリーの作成を開始します。
パーサーはブローカーによって 1 回だけではなく複数回呼び出されることがあります。