ユーザー定義のメッセージ処理ノードのライフ・サイクル

このトピックは、C プログラミング言語と Java プログラミング言語の両方に関する、 ユーザー定義のメッセージ処理ノードの存続期間におけるさまざまな段階を説明します。 作成および破棄されるオブジェクト、 およびこれらの段階で呼び出されるメソッドやクラスについて説明します。

このトピック内の情報は、出力ノードとメッセージ処理ノードのどちらにも適用されます。 これら 2 つのノード・タイプは一緒に考慮することができます。 なぜなら、メッセージ処理ノードは一般に、メッセージを処理するために使用され、 出力ノードはメッセージからビット・ストリームの形式で出力を提供するために使用されますが、 そのいずれかの機能を実行するために、どちらのノード・タイプでも使用できるからです。

C メッセージ処理ノードのライフ・サイクル

インスタンス化の段階で、ユーザー定義のメッセージ処理ノードのインスタンスが作成されます。 ブローカーが関数ポインターのテーブルを受信するとこの段階は開始し、 ユーザー定義ノードの各インスタンス化ごとに cniCreateNodeContext 関数を呼び出します。 cniCreateNodeContext 関数は、 ユーザー定義のメッセージ処理ノードを使用している各メッセージ・フローごとに呼び出されます。 この関数は、そのユーザー定義ノードのインスタンス化用に、 構成された属性の値を保持するためのメモリーを割り振ります。

cniCreateContext 内でブローカーは cniCreateInputTerminal および cniCreateOutputTerminal という 2 つの関数を呼び出して、 メッセージ処理ノードが持つ入力ターミナルと出力ターミナルを設定します。

登録

ユーザー定義のメッセージ処理ノードは、 ノードを含む LIL がオペレーティング・システムによってロードされ、 初期化されるときにブローカーに登録されます。

ブローカーは bipGetMessageflowNodeFactory を呼び出して、LIL の機能、 およびその呼び出し方を設定します。

次に bipGetMessageflowNodeFactory 関数は、cniCreateNodeFactory 関数を呼び出します。 これは、LIL によってサポートされるすべてのノードに対して、 ファクトリー名およびグループ名を戻します。

LIL は次にユーティリティー関数 cniDefineNodeClass を呼び出して、 各ノードの名前と、インプリメンテーション関数のアドレスの仮想関数テーブルを渡します。

インスタンス化

処理

ユーザー定義のメッセージ処理ノードのライフ・サイクルの処理段階で、 その入力メッセージの処理が行われると、メッセージは何らかの方法で変換されます。

ブローカーがキューからメッセージを取り出し、 そのメッセージがユーザー定義ノードの入力ターミナルに到着すると、 ブローカーはインプリメンテーション関数 cniEvaluate を呼び出します。 この関数は、メッセージの処理方法を決定するために使用されます。

ユーザー定義のメッセージ処理ノードで一連のノード・ユーティリティー関数を使用して、 一連のメッセージ処理関数、 たとえば、メッセージ・データへのアクセス、 ESQL へのアクセス、メッセージ・オブジェクトの変換、 メッセージの伝搬などを実行することができます。 メッセージを処理するために使用しようとしているノード・ユーティリティー関数を、cniEvaluate 関数に組み込む必要があります。

このインターフェースでは、メッセージのプロパティー・サブツリーが自動的に生成されるわけではありません。 メッセージにプロパティー・サブツリーを含めることは要件ではありませんが、入力ノードに関係なく、 プロパティー・フォルダーを作成して一貫したメッセージ・ツリー構造を用意すると便利かもしれません。 メッセージにプロパティー・サブツリーを作成する場合で、 ユーザー定義の入力ノードを使用している場合、 この作業は自分で行う必要があります。

破棄

ユーザー定義のメッセージ処理ノードによるメッセージの処理が完了したら、 使用されていたシステム・リソースをリリースするため、 また、メッセージが構成されて処理されたときに獲得されたコンテキストなどの、 ノード・インスタンスに固有のデータ領域をリリースするために、 ノードを破棄する必要があります。

ブローカーが cniDeleteNodeContext 関数を呼び出すとき、 ユーザー定義のメッセージ処理ノードのインスタンスは破棄されます。 (不完全セグメント)The broker calls cniDeleteNodeContext when

Java メッセージ処理ノードのライフ・サイクル

登録

Java で作成されたユーザー定義のメッセージ処理ノードがブローカーに知られるか、 または登録されると、登録の段階となります。

ブローカーが開始するたびに、関連するすべての lil と java クラスがロードされます。 確実にメッセージ処理ノードをブローカーに登録するために、 ブローカーのクラスパスに含まれる、MbNodeInterface インターフェースをインプリメントする クラスをブローカーに提供する必要があります。

インスタンス化

Java のユーザー定義のメッセージ処理ノードは、 ブローカーがそのユーザー定義のメッセージ処理ノードを含むメッセージ・フローをデプロイするときにインスタンス化されます。 ノードがインスタンス化されるときは、 メッセージ処理ノードのクラスのコンストラクターが呼び出されます。

ノードがインスタンス化されると、 関連メソッドを使って指定したすべてのターミナルが作成されます。 メッセージ処理ノードは、 いくつかの入力ターミナルと出力ターミナルを関連付けることができます。 createInputTerminal メソッドと createOutputTerminal メソッドをノード・コンストラクターに組み込み、 これらのターミナルを宣言する必要があります。

出力ターミナルには、out ターミナル、failure ターミナル、 および catch ターミナルが含まれます。 ノード・クラス・コンストラクター内の createOutputTerminal クラスを使用して、 必要数の出力ターミナルを作成できます。

最小限として、これらの出力ターミナルをコンストラクター・クラスを使用して作成するだけの必要があります。 ただし、属性値を初期化する必要がある場合、そのコードをこの時点でメッセージ処理ノードに組み込む必要もあります。

入力ノードに再び渡された例外を処理する場合は、 createOutputTerminal メソッドを使用して、ユーザー定義のメッセージ処理ノード のために failure ターミナルを作成することによりそうするのが、実際的です。 WebSphere Business Integration Message Broker はエラーを failure ターミナルへ伝搬するため、この処理のために failure ターミナルを使用するのは、適切です。

メッセージ処理ノードがキャッチした例外をすべて適切に処理する必要があります。 failure ターミナルを含めない場合、メッセージ処理ノードは例外の処理を試行しません。 メッセージ・フローに例外処理のメソッドが含まれない場合、 送出された例外はすべて入力ノードに再び渡され、処理されます。

例外をキャッチする場合、メッセージ処理ノードが処理できないものをすべて再送出し、 たとえばトランザクションのロールバックなどの処理のために例外を入力ノードに渡す必要があります。

処理

ユーザー定義のメッセージ処理ノードのライフ・サイクルの処理段階で、 メッセージ処理ノードはメッセージの論理階層を取り込み、それを何らかの方法で処理します。

破棄

Java ユーザー定義のメッセージ処理ノードは、 ノードが削除されるか、またはブローカーがシャットダウンされると破棄されます。 ガーベッジ・コレクターによって処理できるので、 ノードの物理的な削除の指定をコードに組み込む必要はありません。

ただし、ノードの削除に関して通知が必要な場合は、onDelete メソッドを使用できます。 削除したい、ガーベッジ・コレクションが実行されるこれ以外のリソースがある場合にも、 これを使用することができます。 たとえば、ソケットをオープンした場合、 ノードが自動的に削除されるとこのソケットは正しくクローズされません。 この指示を onDelete メソッドに組み込んで、 ソケットを正しくクローズすることができます。

関連概念
メッセージ・フロー・ノード
ユーザー定義のメッセージ処理ノード
ユーザー定義のメッセージ処理ノードの計画

関連タスク
C でのメッセージ処理ノードの作成
Java でのメッセージ処理ノードまたは出力ノードの作成

関連資料
cniCreateInputTerminal
cniCreateNodeFactory
cniDeleteNodeContext
cniDefineNodeClass
cniEvaluate