ユーザー定義のパーサーのライフ・サイクル

このトピックは、ユーザー定義のメッセージ・フロー・パーサーの存続期間におけるさまざまな段階を説明します。 以下の段階です。

このトピックは、ユーザー定義のパーサー実行時に、WebSphere Message Broker コンポーネント間で発生する 対話を理解するのに役立ちます。ここでは、各段階中、およびその後に発生するイベント、 および呼び出される API に関して各段階を説明します。 このトピックの概念を理解すると、パーサーの設計および開発をより効率的に行うことができます。

登録

ユーザー定義のパーサーのライフ・サイクル中の最初の段階は、登録段階です。 登録段階の目的は、ユーザー定義のパーサーをブローカーに登録することです。 この段階は、実行グループ・プロセスの開始段階を初期化することによってトリガーされます。

インスタンス化

パーサーは、パーサーのライフ・サイクルのインスタンス化の段階で作成されます。 入力メッセージを受け取るか、または計算ノードで出力メッセージが作成されると、 関係のあるパーサーが識別され、MQMD などのメッセージ・ヘッダーからパーサー要件が取られます。 ブローカーは開始し、ロード可能インプリメンテーション・ライブラリー (LIL)、およびパーサー・ファクトリーをロードします。 実行グループ・プロセスがパーサーのインスタンスを作成し、ブローカーは cpiCreateContext への呼び出しを行って、パーサー・オブジェクトがメッセージの適切な セクションを獲得できるようにします。

この関数が呼び出される前に、 ブローカーは、パーサー用の有効なルート・エレメントとして名前エレメントを作成しています。 ただし、このエレメントには名前が付いていません。 パーサーは、このエレメントに cpiSetElementName 関数で名前を指定しなければなりません。

次いでブローカーは、cpiParseBuffer を呼び出します。 この段階での cpiParseBuffer の目的は、必要な初期化を実行すること、およびパーサーが取る 所有権を持つメッセージ内容の長さを戻すことです。 パーサーは、解析するメッセージ・データの量を査定し、適切なバイト数を請求します。

ユーザー定義のパーサー・オブジェクトのインスタンスが作成されるときはいつでも、 コンテキスト作成インプリメンテーション関数 cpiCreateContext も メッセージ・ブローカーによって呼び出されます。 これによって、パーサーは、属性用のデータ域など、 パーサーと関連付けられたインスタンス・データを割り振ることができます。 パーサー・オブジェクトのコンテキストを削除する、cpiDeleteContext 関数も必要です。

処理

処理段階の目的は、パーサーが解釈中のメッセージ・オブジェクト内のエレメントを操作、 変更、および参照することです。 メッセージ・フロー処理段階は、関係するメッセージのブローカーの内部モデル表現に存在しない メッセージ内でエレメントへのアクセスを必要とする、ナビゲーションなどのメッセージ処理 アクティビティー発生時に開始します。

メッセージ・フロー処理段階中、パーサーはメッセージ・ツリーへのナビゲートの試みに応答して 呼び出されます。パーサーは、cpiParseBuffer 呼び出し時に割り振られたバッファーを調査し、 必要なメッセージ・エレメントがあれば作成します。

その後、パーサーは次のパーサー・インプリメンテーション関数のいずれか、またはすべてを使用して、 メッセージ・エレメント全体をナビゲートできます。
  • cpiParseFirstChild
  • cpiParseLastChild
  • cpiParsePreviousSibling
  • cpiParseNextSibling

これらの関数は、メッセージ・フィールドを指定するフィルター表現など、何らかの形式の ナビゲーションが実行された場合に、ユーザー定義のパーサーがサポートするメッセージ形式用の データを論理的に表す構文エレメント・ツリーの一部分に呼び出されます。 これは、ブローカー内の操作が構文エレメント・ツリーの構築または拡張を必要とする場合に発生します。

構文エレメント・ツリーを最も良い方法でナビゲートするため、次の点を意識することが必要です。
  • 構文エレメントには、親、兄弟、および最初と最後の子への 5 つのポインターがあります。 つまり、ナビゲーションの有限セットが使用できるということです。
  • 同じ内部クラスは、これらのすべてのナビゲーションを実行するために使用されます。
  • パーサーはナビゲーションを制御しません。 ESQL またはユーザー定義のノードは、ナビゲートする方向、およびナビゲーション・パーサー・インプリメンテーション関数が呼び出される順番を決定します。 ユーザー定義のパーサーにはこれに関する制御がなく、選択されたナビゲーション・スキームに正しく応答することが必要です。これは、例えば左から右だけでなく右から左にも解析をするという 意味です。
  • ユーザー定義のパーサーの作成時、実際のパーサー・コードを parseNextItem 関数に入れる ことが期待されます。この関数は、構文エレメント・ツリーのエレメントを一度に 1 つずつ構築し、 名前、値、および完全なフラグを適切に設定することになっています。 この関数のインプリメント方法は、解析されるビット・ストリームの性質に依存します。WebSphere Message Broker 付属のパーサーのサンプルはこのことを例示しています。

構文エレメント・ツリーの関連部分の解析を終えると、パーサーは cpiWriteBuffer を呼び出します。 この関数は、パーサー・オブジェクトに関連付けられているメッセージ・バッファーにある ビット・ストリームに構文エレメント・ツリーの一部分を追加します。 これによって出力メッセージが作成されます。

破棄

破棄段階は、ユーザー定義のパーサーのライフ・サイクルの最終段階です。 パーサーが構文エレメント・ツリーの一部分をビット・ストリームに書き込み、出力メッセージを 作成すると、ブローカーがパーサーが使用するために作成したシステム・リソースをリリースする 必要があります。

破棄段階は、mqsistop コマンドを使用して実行プロセスを停止する際に開始します。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 最終更新: 08/21/2006
as01413_