実行モデルは、一連のノードを介してメッセージ・フローを開始するのに使用されるシステムです。
実行グループが初期化されると、該当するロード可能実装ライブラリー (LIL) ファイル
およびプラグイン・アーカイブ (PAR) ファイルをランタイム環境で使用できるようになります。 実行グループ・ランタイム・プロセスが開始し、専用構成スレッドを作成します。 必ず、ユーザー定義ノードがスレッド・セーフであるようにしてください。 ノードが複数のスレッドをまたいで変数を更新する場合は、適切なロックを施す必要があります。 ユーザー定義のノードのインプリメンテーションで、このスレッド・モデルを妥協しないでください。 以下の点をご覧ください。
- メッセージ・フローに送信される入力メッセージは、それを受け取ったスレッドによってのみ
処理されます。
- ユーザー定義拡張機能の単一インスタンスは、いくつかのスレッド上で並行して呼び出されることがあります。
- メッセージ・フロー実行環境は、概念的にはプロシージャー型プログラミングと類似しています。 メッセージ・フローに挿入するノードは、関数呼び出しインターフェースを使って呼び出されるサブルーチンのようなものです。 しかしながら、パラメーターが入力メッセージ・データの形式で渡される「呼び出し - 戻り」インターフェースというよりは、実行モデルは「伝搬して戻る」モデルと言えます。
一例として、ユーザー定義ノードおよびパーサーの両方で使用しているメッセージ・フローについて考えてみます。 ユーザー定義ノードを使用してメッセージを処理し、ユーザー定義のパーサーを使用してメッセージを解析します。ノードとパーサーの両方にインプリメンテーション関数が入ります。 ブローカーは、特定のイベントの発生時にインプリメンテーション関数またはコールバック関数を呼び出します。
- メッセージ・フローが入力メッセージを受け取り、ユーザー定義のノードに伝搬された場合:
- C ノードの場合、ブローカーは、ユーザー定義のノードのために cniEvaluate 関数を呼び出します。 cniEvaluateを参照してください。
- Java™ ノードの場合、ブローカーは、ユーザー定義のノードによりインプリメントされている evaluate メソッドを呼び出します。
- ユーザー定義ノードがメッセージを照会して、それをどうするか決定する場合、そのノードは C ユーティリティー関数または Java メソッドのどちらか、そのノードを作成した言語に適切な方を呼び出します。
ブローカーはインプリメンテーション関数の 1 つでユーザー定義のパーサーを呼び出します。(例えば cpiParseFirstChild など)。 この関数は、パーサーが解析ツリーの作成を開始するように指示します。 パーサーは、解析ツリーでエレメントを作成するユーティリティー関数を呼び出すことによって、ツリーを作成します。(例えば cpiCreateElement など)。
パーサーはブローカーによって複数回呼び出されることがあります。