WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

Java ユーザー定義入力ノードのライフサイクル

Java™ プログラミング言語で作成されるユーザー定義入力ノードは、存続期間の間、いくつかの段階を経て進行します。

ライフ・サイクルには、以下の段階があります。

登録

登録の段階で、Java で作成されたユーザー定義の入力ノードはブローカーに自分の存在を知らせます。 ノードは静的 getNodeName メソッドによってブローカーに登録されます。 ブローカーが開始するたびに、関連するすべての Java クラスがロードされます。 この時点で静的メソッド getNodeName が呼び出され、ブローカーは入力ノードを getNodeName で指定したノード名で登録します。 ノード名を指定しない場合、ブローカーはそれが含まれているパッケージに基づいてノードに対して自動的に名前を作成します。

ここで静的メソッドを使うということは、 ノード自体がインスタンス化される前にブローカーでメソッドを呼び出せるということを意味します。

インスタンス化

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

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

入力ノードに再び渡された例外を処理するには、createOutputTerminal を使用して入力ノードの catch ターミナルを作成します。 入力ノードがエラーをキャッチすると、catch ターミナルは MQInput ノードが行うのと同じ方法でそのエラーを処理します。 デプロイメントの問題に起因する例外など、ほとんどの例外はブローカーに戻すことができます。ブローカーは、考えられるあらゆる構成エラーについてユーザーに警告を出します。

コンストラクター・クラスに最低限必要なのは、これらの出力ターミナルを入力ノードに作成することだけです。 ただし、例えば入力ノードから渡されるメッセージを最初に構文解析するパーサーの定義など、 属性値を初期化する必要がある場合、そのコードをこの時点で入力ノードに組み込む必要もあります。

処理

入力ノードのメッセージ処理は、 ブローカーが run メソッドを呼び出したときに開始します。 run メソッドが入力メッセージを作成し、メソッドは入力ノードの処理関数を含むはずです。

run メソッドは MbInputNodeInterface で定義されます。 これは、ユーザー定義ノードで使用され、それを入力ノードとして定義するインターフェースです。 ノードには run メソッドを含める必要があります。 ユーザー定義入力ノードに run メソッドが含まれていないと、ノード・ソース・コードはコンパイルできません。

ユーザー定義入力ノードが含まれたメッセージ・フローが正常にデプロイされていれば、 ブローカーはこのノードの run インプリメンテーション・メソッドを呼び出し、 メッセージの処理を待つ間、このメソッドを呼び出し続けます。

メッセージ・フローが開始する際には、ブローカーによって単一スレッドがディスパッチされ、入力ノードの run メソッドに呼び出されます。 dispatchThread() メソッドが呼び出されると、同じ run メソッドでさらにスレッドを作成することができます。 これらの新規のスレッドは、即時に入力ノードの run メソッドへ呼び出され、元のスレッドと同様に扱うことができます。 作成できる新規のスレッドの数は、additionalInstances プロパティーで 定義されています。 スレッドのディスパッチは、メッセージが作成された後、そのメッセージが伝搬される前に行うようにして、新規のメッセージを待っているスレッドが一度に 1 つだけになるようにしてください。

ユーザー定義入力ノードは異なるスレッド化モデルを選択できます。そして、選択したモデルをインプリメントする責任を担います。 入力ノードが additionalInstances プロパティーをサポートし、かつ dispatchThread() が呼び出される場合、コードは完全に再入可能でなければならず、ノードから呼び出される関数もすべて再入可能でなければなりません。 入力ノードで強制的に単一スレッド化を行う場合、つまり入力ノードが dispatchThread() を呼び出さない場合は、additionalInstances プロパティーを設定しても入力ノードには何も効果がないことをノードのドキュメンテーションに明記する必要があります。

ユーザー定義入力ノードのスレッド化モデルについて詳しくは、ユーザー定義拡張機能のスレッド化に関する考慮事項を参照してください。

破棄

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

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

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:48:12


概念トピック概念トピック | バージョン 8.0.0.5 | as24998_