bea ホーム | 製品 | dev2dev | support | askBEA |
![]() |
![]() |
|
![]() |
e-docs > Tuxedo > Tuxedo CORBA 要求レベルのインターセプタ > CORBA 要求レベルのインターセプタの概要 |
Tuxedo CORBA 要求レベルのインターセプタ
|
CORBA 要求レベルのインターセプタの概要
要求レベルのインターセプタとは、CORBA アプリケーションのクライアント・コンポーネントとサーバ・コンポーネントの間の呼び出しパスに、セキュリティ・コンポーネントや監視コンポーネントなどの機能を挿入する手段となる、ユーザ記述の CORBA オブジェクトです。特定のマシン上でオブジェクト・リクエスト・ブローカ (ORB) にインストールおよび登録されたインターセプタは、そのマシン上のすべての CORBA アプリケーションに関与します。インターセプタを使用すると、任意の追加機能をクライアント側、サーバ側、または両方でオブジェクト呼び出しの呼び出しパスに挿入できます。
要求レベルのインターセプタは通常、代表的な CORBA 環境の一部ではありません。これらのインプリメントは、高度なプログラミング・タスクと見なされています。
BEA Tuxedo システムの CORBA 環境でサポートされるインターセプタは、2 種類のカテゴリに分類されます。
CORBA 環境の BEA Tuxedo システムは、クライアント・オブジェクトおよびターゲット・オブジェクトの相対的な場所を基準として、インターセプタをインストールして使用できる場所に関する自由度は非常に高くなっています。クライアント・アプリケーションからは、要求のターゲットが同じプロセス内にあるのか別のプロセス内にあるのかは、見えません。
クライアント側インターセプタとターゲット側インターセプタは別個のインターフェイスから継承されていますが、両者を単一のソース・ファイル内にインプリメントすると都合のよい場合が多くあります。
インターセプタのアーキテクチャ
次の図は、要求レベルのインターセプタと BEA Tuxedo システムの関係を示します。
CORBA インターセプタの BEA Tuxedo インプリメンテーションについては、次の事項に留意してください。
呼び出しの正常な要求応答サイクル 1 回の間に、クライアント側インターセプタは ORB によって 2 回呼び出されます。
呼び出しの要求応答サイクル 1 回の間に、ターゲット側インターセプタは ORB によって 2 回呼び出されます。
ORB は、登録されたインターセプタのリストを維持します。インターセプタの登録は、管理タスクとして行う操作です。複数のインターセプタをインストールおよび作成できるので、アプリケーション実行時に、ORB はこのリストを使用して、いつ、どの順番でインターセプタを呼び出すべきかを決定します。複数のインターセプタを登録した場合、ORB は各インターセプタを連続的に実行します。複数のインターセプタの呼び出しの順序を設定するのも、管理タスクの 1 つです。
機能と制限事項
要求レベルのインターセプタは、以下のような数種類のサービス・アプリケーションをインプリメントする際に、特に有用です。
CORBA インターセプタに対する現在の制限事項は、以下のとおりです。
これらのインターフェイスは BEA Tuxedo 製品では使用しません。これらのインターフェイスが BEA Tuxedo ソフトウェアで定義されているのは、BEA Tuxedo 製品の将来のリリースでこれらのインターフェイスのインプリメンテーションが提供された場合に、CORBA アプリケーションを再コンパイルする必要性をなくすためです。ORB は常に実際の引数に対する nil オブジェクトを渡します。これらの引数を使用しないでください。プロセスが深刻なエラーにより停止することが予想されます。
実行フロー
以下の節では、インターセプタを使用する CORBA アプリケーションの実行中に行われる処理を説明します。一般に、要求レベルのインターセプタのインスタンス化と初期化は、ORB の初期化時にのみ行われます。それ以外では、要求レベルのインターセプタをインスタンス化できません。
インターセプタの戻りステータスにより、ORB 実行時およびインストールされている可能性があるほかの要求レベルのインターセプタの実行フローが制御されます。
呼び出された後のインターセプタの戻りステータスに応じて、次のイベントのうち 1 つが発生することがあります。
複数の要求レベルのインターセプタを、1 回の呼び出しに関連付けることができます。あるインターセプタが別のインターセプタを認識する必要は、まったくありません。
呼び出しの要求応答サイクル内で起こるイベントは、次の 2 つのカテゴリに分けて提示されます。
クライアント側での実行
呼び出しの要求応答サイクルにおいて、各インターセプタは 2 回呼び出されます。1 回目は要求がクライアントからターゲットに向かうとき、2 回目は応答がクライアントに返るときです。クライアントのインターセプタ・クラス ClientRequestInterceptor には、これら 2 つの呼び出しに特に対応するオペレーションが 2 つあります。
クライアント側インターセプタを使用する CORBA アプリケーションの実行フローを 図1-1 に示します。この図では、基本的かつ正常な要求応答呼び出しサイクルを示します。つまり、このサイクルでは例外は発生しません。
図 1-1 クライアント側インターセプタ
クライアント側での例外処理
client_invoke および client_response オペレーションは各々、クライアント・インターセプタの処理を続行するかどうかを示すステータス値を返します。インターセプタは、例外処理を引き起こす例外ステータス値を返すことがあります。表 1-1 は、これらのオペレーションから返されるステータス値に応じて生じる現象、およびインターセプタが ORB と共に例外を処理する方法を示します。
表 1-1 クライアント・インターセプタの戻りステータス値
ターゲット側での実行 クライアント側と同じく、ターゲット側インターセプタは要求応答サイクル中に 2 回呼び出されます。ターゲット側インターセプタは TargetRequestInterceptor クラスから継承されます。このクラスには、次のオペレーションが含まれます。
ターゲット側インターセプタを使用する CORBA アプリケーションの実行フローを 図1-2 に示します。この図では、基本的かつ正常な要求応答呼び出しサイクルを示します。つまり、このサイクルでは例外は発生しません。
図 1-2 ターゲット側インターセプタ
ターゲット側での例外処理
表 1-2 は、target_invoke および target_response オペレーションによって返されるステータス値に応じて、ターゲット側の呼び出しに生じる現象を示し、例外がスローされた場合の動作を説明します。
表 1-2 ターゲット・インターセプタの戻りステータス値
exception_occurred メソッド すべてのインターセプタに exception_occurred メソッドが存在します。ORB はこのメソッドを、次の状況下で呼び出します。
前述の状況の 1 つが生じた場合、exception_occurred メソッドが client_response または target_response メソッドの代わりに呼び出されますが、クライアントの呼び出しを完了させる効果は本質的に同じです。
要求のトラッキングの詳細については、第 2 章の 7 ページ「インターセプタの応答オペレーションのインプリメント」を参照してください。
短絡動作について
前述のように、インターセプタは自身で要求を処理したり、例外を返したりすることによって、クライアント要求を短絡できます。どちらの場合でも、クライアント要求が実際にターゲット・オブジェクトによって処理されることはありません。
短絡動作は、client_invoke または target_invoke メソッドでのみ機能します。client_response または target_response メソッドには適用されません。
複数の要求レベルのインターセプタの使用方法
複数の要求レベルのインターセプタは、ORB が 1 つずつ逐次的に実行できるように、キューにインストールされます。ORB は、キューに残っている要求レベルのインターセプタがなくなるまで、各要求レベルのインターセプタに連続的に要求を供給します。すべてのインターセプタで正常な状態が示されると要求が処理されます。ORB は得られた応答をクライアントの場合はトランスポートに、ターゲットの場合はオブジェクト・インプリメンテーションに送信します。ORB は要求の処理とは逆の順番で応答を処理するインターセプタを実行します。
インターセプタで正常な状態が示されない場合は、短絡応答が生じます。短絡は client_invoke または target_invoke オペレーションによって実行されます。インターセプタから返されたステータスにより、例外を伴う要求をターゲット・オブジェクトに処理させるのではなく、インターセプタ自体で応答することが、ORB に通知されます。 (インターセプタの client_response または target_response オペレーションでは、短絡動作を行うことはできませんが、ターゲット応答の代わりとなることはできます)。
各インターセプタは通常、明示的に情報を共有していない限り、ほかのインターセプタを認識していません。この独立したプログラミング・モデルは、短絡に関する実行セマンティクスによって維持されます。応答を短絡して、送信先 (クライアント側のトランスポート、およびターゲット側のオブジェクト・インプリメンテーション) に届かないようにする必要があるとインターセプタが示した場合、応答は正常に通過したインターセプタを経由して元に戻ります。たとえば、インターセプタ A が client_invoke オペレーションの処理後に、要求が送信されるようにステータス値 INVOKE_NO_EXCEPTION を返し、次のインターセプタ B が要求を拒否して例外を生成すると、その例外は応答に加えられ、インターセプタ A の exception_occurred オペレーションに送信されます。ターゲット側の類似の実行モデルも有効です。
図1-3 は複数のクライアント側インターセプタが ORB にインストールされている場合の実行シーケンスを示します。 (同様の一連のオペレーションは、複数のターゲット側インターセプタでも発生します)。
図 1-3 ORB 上の複数のインターセプタ
複数のクライアント側インターセプタ
ORB は要求を受け取ると、各クライアント側インターセプタの client_invoke オペレーションを呼び出します。戻り値 INVOKE_NO_EXCEPTION が各 client_invoke オペレーションから返された場合(通常の場合)、結果として生じた要求は ORB によってメッセージにマーシャリングされ、ターゲット・オブジェクトに送られます。
次の状況では、ORB は、クライアント方向で残りのインターセプタの client_response オペレーションを呼び出すのではなく、これらのインターセプタの exception_occurred を呼び出し、次に例外をクライアント・アプリケーションに返します。
この場合、ORB は要求を残りのインターセプタまたはトランスポートに伝達することを中止します。したがって、要求は ORB によって短絡されます。
この場合、インターセプタは ORB に例外を返し、それ以前の要求の結果はすべて上書きします。
複数のターゲット側インターセプタ
クライアント側インターセプタの処理の場合と同じく、ORB は各ターゲット側インターセプタの target_invoke オペレーションを連続的に呼び出します。各 target_invoke オペレーションから戻り値 INVOKE_NO_EXCEPTION が返されると、要求はターゲット・オブジェクトに渡されます。
次の状況では、ORB は、クライアント方向で残りのインターセプタの target_response オペレーションを呼び出すのではなく、これらのインターセプタの exception_occurred を呼び出し、次に例外をクライアント・アプリケーションに返します。
この場合、ORB は要求を残りのインターセプタおよびトランスポートに伝達することを中止します。この時点で、ORB はクライアント ORB に応答を返し、ターゲット ORB は要求を短絡します。
この場合、インターセプタは ORB に例外を返し、それ以前の要求の結果はすべて上書きします。
インターセプタおよびメタ・オペレーション
メタ・オペレーションとは、CORBA Object インターフェイスをサポートする is_a、get_interface、および non_existent などのオペレーションです。一部のメタ・オペレーションは、呼び出しを発行することなく ORB によって実行されますが、それ以外のオペレーション (is_a、get_interface、および non_existent メソッド) ではオブジェクトの呼び出しを必要とする場合あります。したがって、これらのオペレーションはインターセプタを開始できます。
オペレーションを CORBA 固有の言語でバインディングすると、オペレーション名を IDL で定義した名前から、次の名前に変換できます。
セキュリティ・ベースのインターセプタをインプリメントしている場合は、ORB がこれらのオペレーションをクライアント要求の一部として呼び出す可能性があるため、この振る舞いには注意してください。通常、インターセプタが特定のクライアント要求にだけターゲット・オブジェクトへの送信を許可し、これらのメタ・オペレーションを考慮できないような状況は避けてください。
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |