このトピック内の情報は、出力ノードとメッセージ処理ノードのどちらにも適用されます。 これら 2 つのノード・タイプは一緒に考慮することができます。 なぜなら、メッセージ処理ノードは一般に、メッセージを処理するために使用され、 出力ノードはメッセージからビット・ストリームの形式で出力を提供するために使用されますが、 そのいずれかの機能を実行するために、どちらのノード・タイプでも使用できるからです。
Java で作成されたユーザー定義のメッセージ処理ノードがブローカーに知られるか、またはブローカーに登録されると、登録の段階となります。
ブローカーが開始するたびに、関連するすべての LIL と Java クラスがロードされます。 確実にメッセージ処理ノードをブローカーに登録するために、ブローカーのクラスパスに含まれる、MbNodeInterface インターフェースをインプリメントする クラスをブローカーに提供する必要があります。
Java のユーザー定義のメッセージ処理ノードは、ブローカーがそのユーザー定義のメッセージ処理ノードを含むメッセージ・フローをデプロイするときにインスタンス化されます。 ノードがインスタンス化されるときは、 メッセージ処理ノードのクラスのコンストラクターが呼び出されます。
ノードがインスタンス化されると、指定したすべてのターミナルが作成されます。 メッセージ処理ノードは、 いくつかの入力ターミナルと出力ターミナルを関連付けることができます。 createInputTerminal メソッドと createOutputTerminal メソッドをノード・コンストラクターに組み込み、これらのターミナルを宣言する必要があります。
出力ターミナルには、out ターミナル、failure ターミナル、 および catch ターミナルが含まれます。 ノード・クラス・コンストラクター内の createOutputTerminal クラスを使用して、必要数の出力ターミナルを作成できます。
最低限必要なのは、コンストラクター・クラスを使用してこれらの出力ターミナルを作成することだけです。 ただし、属性値を初期化する必要がある場合、そのコードをこの時点でメッセージ処理ノードに組み込む必要もあります。
メッセージ処理ノードに戻される例外を処理する場合は、createOutputTerminal メソッドを使用してユーザー定義のメッセージ処理ノードのために failure ターミナルを作成し、例外を処理するのが実際的です。 WebSphere Message Broker はエラーを failure ターミナルへ伝搬するため、この処理のために failure ターミナルを使用するのは適切です。
メッセージ処理ノードがキャッチした例外をすべて適切に処理する必要があります。 failure ターミナルを含めない場合、メッセージ処理ノードは例外の処理を試行しません。 メッセージ・フローに例外処理のメソッドが含まれない場合、スローされた例外はすべて入力ノードに戻され、入力ノードは例外を処理します。
例外をキャッチした場合、メッセージ処理ノードで処理できない例外については、必ずこれをすべて再スローするようにしてください。 これにより、例えばトランザクションをロールバックしたい場合などに、例外が入力ノードに戻され、処理されます。
Java ユーザー定義のメッセージ処理ノードは、 ノードが削除されるか、またはブローカーがシャットダウンされると破棄されます。 ノードを物理的に削除するよう指定するために、コードの中に何かを組み込む必要はありません。ガーベッジ・コレクターがこれを処理できるためです。
ただし、ノードの削除に関して通知が必要な場合は、onDelete メソッドを使用できます。 ガーベッジ・コレクションが実行されるリソース以外にも、削除したいリソースがある場合に、これを使用することができます。 例えば、ソケットをオープンした場合、ノードが自動的に削除されるとこのソケットは正しくクローズされません。 この指示を onDelete メソッドに組み込んで、ソケットを正しくクローズすることができます。