CORBAリクエスト・レベルのインターセプタの紹介
|
注意:
|
Oracle Tuxedo CORBA JavaクライアントとOracle Tuxedo CORBA JavaクライアントORBはTuxedo 8.1で非推奨になり、サポートされなくなりました。すべてのOracle Tuxedo CORBA JavaクライアントおよびOracle Tuxedo CORBA JavaクライアントORBのテキスト・リファレンスとコード・サンプルは、サード・パーティのJava ORBライブラリを実装または実行する際の参考や、プログラマの参照用としてのみ使用してください。 |
サード・パーティのCORBA Java ORBのテクニカル・サポートは、各ベンダーによって提供されます。Oracle Tuxedoでは、サード・パーティのCORBA Java ORBに関する技術的なサポートまたはドキュメントは提供していません。
リクエスト・レベルのインターセプタとは、CORBAアプリケーションのクライアント・コンポーネントとサーバー・コンポーネントの間の呼出しパスに、セキュリティ・コンポーネントやモニタリング・コンポーネントなどの機能を挿入する手段となる、ユーザー記述のCORBAオブジェクトです。特定のマシン上でオブジェクト・リクエスト・ブローカ(ORB)にインストールおよび登録されたインターセプタは、そのマシン上のすべてのCORBAアプリケーションに関与します。インターセプタを使用すると、任意の追加機能をクライアント側、サーバー側、または両方でオブジェクト呼出しの呼出しパスに挿入できます。
リクエスト・レベルのインターセプタは通常、代表的なCORBA環境の一部ではありません。これらの実装は、高度なプログラミング・タスクとみなされています。
Oracle TuxedoシステムのCORBA環境でサポートされるインターセプタは、2種類のカテゴリに分類されます。
|
•
|
1つはクライアント側インターセプタです。これは呼出しのクライアント側でORBによって呼び出され、要求を行うエンティティのプロセスで実行されます。クライアント側インターセプタは、 ClientRequestInterceptorクラスから継承されます。 |
|
•
|
もう1つは、ターゲット・サイド・インターセプタです。これは呼出しのターゲット・サイドでORBによって呼び出され、ターゲット・アプリケーション・プロセスで実行されます。呼出しのターゲットは、CORBAサーバー・アプリケーションでもCORBA共同クライアント/サーバー・アプリケーションでもかまいません。ターゲット・サイド・インターセプタは、 TargetRequestInterceptorクラスから継承されます。 |
CORBA環境のOracle Tuxedoシステムは、クライアント・オブジェクトおよびターゲット・オブジェクトの相対的な場所を基準として、インターセプタをインストールして使用できる場所に関する自由度は非常に高くなっています。クライアント・アプリケーションからは、リクエストのターゲットが同じプロセス内にあるのか別のプロセス内にあるのかは、見えません。
クライアント側インターセプタとターゲット・サイド・インターセプタは別個のインタフェースから継承されていますが、両者を単一のソース・ファイル内に実装すると都合のよい場合が多くあります。
次の図は、リクエスト・レベルのインターセプタとOracle Tuxedoシステムの関係を示します。
CORBAインターセプタのOracle Tuxedo実装については、次の事項に留意してください。
|
•
|
インターセプタは管理者によって登録され、アプリケーションの実行中の適切な時点でORBによって呼び出されます。 |
|
•
|
クライアント側インターセプタがORBにインストールおよび登録されると、そのインターセプタはマシン上のどのCORBAクライアント・アプリケーションからリクエストを受信しても、毎回呼び出されます。 |
呼出しの正常なリクエスト・レスポンス・サイクル1回の間に、クライアント側インターセプタはORBによって2回呼び出されます。
|
a.
|
リクエストが最初にクライアント・アプリケーションから発行され、ORBに到達した時点( client_invokeオペレーション) |
|
b.
|
ターゲット・レスポンスが返されてクライアント・アプリケーションのプロセスに到達した時点( client_responseオペレーション) |
|
•
|
ターゲット・サイド・インターセプタがORBにインストールおよび登録されると、そのインターセプタはマシン上のどのターゲット・オブジェクトにリクエストが到達しても、毎回呼び出されます。 |
呼出しのリクエスト・レスポンス・サイクル1回の間に、ターゲット・サイド・インターセプタはORBによって2回呼び出されます。
|
a.
|
クライアント・リクエストが最初にORBに到達した時点( target_invokeオペレーション) |
|
b.
|
ターゲット・オブジェクト・レスポンスがORBに到達した時点( target_responseオペレーション) |
|
•
|
複数のクライアント側インターセプタまたはターゲット・サイド・インターセプタをORBにインストールおよび登録できます。 |
|
•
|
インターセプタは、各々独立しており、ほかのインターセプタが存在するかどうかを認識している必要はありません。 |
|
•
|
インターセプタは、まったくターゲット・オブジェクトと関係なく、直接クライアントにレスポンスを返すことによって、呼出しを短絡 できます。 |
|
•
|
インターセプタを使用すると、各リクエストが実行されるたびに手順が追加されるため、アプリケーションの全体的なパフォーマンスに影響が生じます。 |
ORBは、登録されたインターセプタのリストを維持します。インターセプタの登録は、管理タスクとして行う操作です。複数のインターセプタをインストールおよび作成できるので、アプリケーション実行時に、ORBはこのリストを使用して、いつ、どの順番でインターセプタを呼び出すべきかを決定します。複数のインターセプタを登録した場合、ORBは各インターセプタを連続的に実行します。複数のインターセプタの呼出しの順序を設定するのも、管理タスクの1つです。
リクエスト・レベルのインターセプタは、以下のような数種類のサービス・アプリケーションを実装する際に、特に有用です。
|
•
|
統計情報を収集するためのインストゥルメンテーション・ポイント |
|
•
|
モニタリング機能またはトレース機能を含むプローブ・ポイント |
CORBAインターセプタに対する現在の制限事項は、以下のとおりです。
|
•
|
インターセプタはORBによってのみ呼び出されます。CORBAクライアントもサーバー・アプリケーションもインターセプタを直接呼び出すことはできません。 |
|
•
|
特定のプログラミング言語で実装されたインターセプタは、同じ言語で実装されたエンティティからのみ、呼出しをインターセプトできます。 |
|
•
|
インターセプタは DataInputStreamオブジェクトへの書込みはできません。 |
|
•
|
インターセプタは、サービス・コンテキスト・オブジェクトを渡したり操作したりできません。 |
|
•
|
インターセプタは、トランザクション・カレント・オブジェクトを渡したり操作したりできません。 |
|
•
|
インターセプタは、 Tobj_Bootstrapオブジェクトのメソッドを呼び出すことはできません。 |
|
•
|
REPLY_NO_EXCEPTIONの戻りステータス値はサポートされていません。ただしインターセプタ・クラスのメソッド・シグネチャ・オペレーションでは使用されます。
|
|
•
|
インターセプタはほかのオブジェクトに呼出しを行うことができますが、これらの呼び出しもインターセプトの対象となります。インターセプタがオブジェクトを呼び出す際には、そのインターセプタが自身の呼出しをインターセプトして無限ループを生じることがないように確認してください。この現象は、呼び出されるオブジェクトがインターセプタと同じサーバー・プロセス内にある場合に起こります。このような状況下では、システムがハングする可能性があります。 |
|
•
|
RequestLevelInterceptorインタフェースから派生したクラスのオペレーションのためのメソッド・シグネチャには、次のインタフェースのパラメータが含まれます。
|
|
•
|
RequestLevelInterceptor::DataOutputStream
|
|
•
|
RequestLevelInterceptor::ServiceContextList
|
これらのインタフェースはOracle Tuxedo製品では使用しません。これらのインタフェースがOracle Tuxedoソフトウェアで定義されているのは、Oracle Tuxedo製品の将来のリリースでこれらのインタフェースの実装が提供された場合に、CORBAアプリケーションを再コンパイルする必要性をなくすためです。ORBは常に実際の引数に対するnilオブジェクトを渡します。これらの引数を使用しないでください。プロセスが深刻なエラーにより停止することが予想されます。
以下の項では、インターセプタを使用するCORBAアプリケーションの実行中に行われる処理を説明します。一般に、リクエスト・レベルのインターセプタのインスタンス化と初期化は、ORBの初期化時にのみ行われます。それ以外では、リクエスト・レベルのインターセプタをインスタンス化できません。
インターセプタの戻りステータスにより、ORB実行時およびインストールされている可能性があるほかのリクエスト・レベルのインターセプタの実行フローが制御されます。
呼び出された後のインターセプタの戻りステータスに応じて、次のイベントのうち1つが発生することがあります。
|
•
|
呼出しは、ターゲット・オブジェクトへの通常のパス、クライアント・アプリケーションに戻るパス、または別のインターセプタへのパスを再開します。 |
|
•
|
クライアント側またはサーバー側のインターセプタはクライアント・リクエストを処理し、例外をクライアントに返します。(この場合、リクエストはターゲット・オブジェクトへはまったく送信されないか、またはインターセプタにより例外と置換されるレスポンスをターゲット・オブジェクトが提供します。これは、クライアント・アプリケーションに対して透過的に行われます。) |
複数のリクエスト・レベルのインターセプタを、1回の呼出しに関連付けることができます。あるインターセプタが別のインターセプタを認識する必要は、まったくありません。
呼出しのリクエスト・レスポンス・サイクル内で起こるイベントは、次の2つのカテゴリに分けて提示されます。
呼出しのリクエスト-レスポンス・サイクルにおいて、各インターセプタは2回呼び出されます。1回目はリクエストがクライアントからターゲットに向かうとき、2回目はレスポンスがクライアントに返るときです。クライアントのインターセプタ・クラス
ClientRequestInterceptorには、これら2つの呼出しに特に対応するオペレーションが2つあります。
|
•
|
client_invoke() - オブジェクト参照に対して行われたリクエストがクライアント側ORBに到達した時点で呼び出されます。
|
|
•
|
client_response() - リクエストを行っているエンティティに対してレスポンスが返された時点で呼び出されます。
|
クライアント側インターセプタを使用するCORBAアプリケーションの実行フローを
図1-1に示します。この図では、基本的かつ正常なリクエスト-レスポンス呼出しサイクルを示します。つまり、このサイクルでは例外は発生しません。
図1-1,では、呼び出される次のイベントを説明しています。
|
1.
|
リクエストがクライアントから出され、ORBに到達します。 |
|
3.
|
クライアント側インターセプタはリクエストを処理し、ORBにステータス・コードを返します。 |
|
4.
|
client_invokeオペレーションの結果として返される例外がない場合、リクエストはターゲット・オブジェクトへのパスを再開します。
|
|
5.
|
ターゲット・オブジェクトがリクエストを処理して、レスポンスを発行します。 |
|
6.
|
レスポンスはORBに戻され、ORBはインターセプタの client_responseオペレーションを呼び出します。 |
|
7.
|
インターセプタがレスポンスを処理し、ORBにステータス・コードを返します。 |
|
8.
|
レスポンスがクライアント・アプリケーションに送信されます。 |
client_invokeおよび
client_responseオペレーションは各々、クライアント・インターセプタの処理を続行するかどうかを示すステータス値を返します。インターセプタは、例外処理を引き起こす例外ステータス値を返すことがあります。
表1-1は、これらのオペレーションから返されるステータス値に応じて生じる現象、およびインターセプタがORBとともに例外を処理する方法を示します。
表1-1
クライアント・インターセプタの戻りステータス値
|
|
|
|
|
|
|
ORBはターゲットに送られたリクエストの通常処理を続行し、ほかにインターセプタが存在する場合は、それを呼び出します。 |
(Oracle Tuxedo製品のバージョン8.0では、ORBはこの戻り値を処理できないため、これをインターセプタの戻り値として実装することは避けてください。) |
インターセプタはリクエストを処理しました。ターゲットに対してこれ以上の処理は必要ありません。リクエストは、ターゲットによって処理された場合のように、処理済と見なされます。したがって、ORBは呼出しを短絡 し、クライアント方向のインターセプタの呼出しを開始します。同じインターセプタの client_responseオペレーションは呼び出されませんが、それ以前に呼び出されたインターセプタのclient_responseオペレーションは呼び出されます。 |
|
|
インターセプタはORBへ例外を戻します。次に、ORBはこれより前のクライアント側インターセプタの各 exception_occurredオペレーションを呼び出します。 exception_occurredメソッドは、ORBがクライアント・アプリケーションに例外を戻す前に状態をクリーンアップする機会を、これより前のインターセプタに提供します。これにより、ORBは呼出しを短絡 し、呼出しは完了します。 exception_occurredメソッドの詳細は、 1-12ページの「exception_occurredメソッド」を参照してください。 |
|
|
|
ORBはクライアントに送られたリクエストの通常処理を続行し、ほかにインターセプタが存在する場合は、それを呼び出します。 |
|
|
インターセプタはORBに例外を返し、それ以前のリクエストの結果はすべてオーバーライドします。ORBは、クライアント方向に、それ以前の各インターセプタの exception_occurredメソッドを呼び出し、次にクライアント・アプリケーションに例外を返します。 |
クライアント側と同じく、ターゲット・サイド・インターセプタはリクエスト-レスポンス・サイクル中に2回呼び出されます。ターゲット・サイド・インターセプタは
TargetRequestInterceptorクラスから継承されます。このクラスには、次のオペレーションが含まれます。
|
•
|
target_invoke() - リクエストがターゲット・オブジェクトのプロセスの一部であるORBに到達した時点で呼び出されます。
|
|
•
|
target_response() - レスポンスがクライアントに返るように送信された時点で呼び出されます。
|
ターゲット・サイド・インターセプタを使用するCORBAアプリケーションの実行フローを
図1-2に示します。この図では、基本的かつ正常なリクエスト-レスポンス呼出しサイクルを示します。つまり、このサイクルでは例外は発生しません。
図1-2では、呼び出される次のイベントを説明しています。
|
3.
|
ターゲット・サイド・インターセプタがリクエストを処理し、ORBにステータス・コードを返します。 |
|
4.
|
target_invokeオペレーションの実行中に発生する例外がない場合、リクエストがターゲット・オブジェクトへのパスを再開します。
|
|
5.
|
ターゲット・オブジェクトがリクエストを処理して、レスポンスを発行します。 |
|
6.
|
ターゲット・サイドORBがインターセプタの target_responseオペレーションを呼び出します。 |
|
7.
|
インターセプタがレスポンスを処理し、ORBにステータス・コードを返します。 |
|
8.
|
レスポンスがクライアント・アプリケーションに送信されます。 |
表1-2は、
target_invokeおよび
target_responseオペレーションによって返されるステータス値に応じて、ターゲット・サイドの呼出しに生じる現象を示し、例外がスローされた場合の動作を説明します。
表1-2
ターゲット・インターセプタの戻りステータス値
|
|
|
|
|
|
|
ORBはターゲット(オブジェクト実装)へのリクエストの通常処理を続行し、ほかにインターセプタが存在する場合は、それを呼び出します。 |
(Oracle Tuxedo製品のバージョン8.0では、ORBはこの戻り値を処理できないため、これをインターセプタの戻り値として実装することは避けてください。) |
インターセプタはリクエストを処理しました。ターゲットに対してこれ以上の処理は必要ありません。リクエストは、ターゲットによって処理された場合のように、処理済と見なされます。したがって、ORBは呼出しを短絡 し、クライアント方向のインターセプタの呼出しを開始します。同じインターセプタの target_responseオペレーションは呼び出されませんが、それ以前に呼び出されたインターセプタのtarget_responseオペレーションは呼び出されます。 |
|
|
インターセプタはORBへ例外を戻します。次に、ORBはこれより前のターゲット側インターセプタの各 exception_occurredオペレーションを呼び出します。 exception_occurredメソッドは、ORBがクライアントORBに例外を戻す前に状態をクリーンアップする機会を、これより前のインターセプタに提供します。これにより、ターゲットORBは呼出しを短絡 し、呼出しは完了します。 exception_occurredメソッドの詳細は、 1-12ページの「exception_occurredメソッド」を参照してください。 |
|
|
|
ORBはクライアントに送られたリクエストの通常処理を続行し、ほかにインターセプタが存在する場合は、それを呼び出します。 |
|
|
インターセプタはORBに新しい例外を返し、それ以前のリクエストの結果はすべてオーバーライドします。クライアントに戻る過程でインターセプタの target_responseオペレーションを呼び出すかわりに、ORBはこれらのインターセプタの exception_occurredオペレーションを呼び出します。 |
すべてのインターセプタに
exception_occurredメソッドが存在します。ORBはこのメソッドを、次の状況下で呼び出します。
|
•
|
ORB内部に問題が見つかった場合。たとえば、オペレーティング・システムのリソース・エラーや通信障害など。
|
|
•
|
例外がORBまたはメソッドで生成されたのではなく、別のインターセプタによって設定された場合。これはたとえば、ORBがインターセプタAおよびインターセプタBをそれぞれ呼び出している場合です。インターセプタAで例外が設定されているため、ORBがインターセプタBに呼び出すのは client_responseまたは target_responseメソッドではなく、 exception_occurredメソッドとなります。インターセプタはこの振る舞いを利用して、例外を含むレスポンスが処理されるコンテキストと、例外の実際の値を、 DataInputStream構造体からの例外を読み取ることなく検査できます。 |
|
•
|
クライアント・アプリケーションは Requestオブジェクトに対する遅延同期DII呼出しを使用し、その後 Requestオブジェクトを解放します。この場合、クライアントに送信されるレスポンスはありません。 |
前述の状況の1つが生じた場合、
exception_occurredメソッドが
client_responseまたは
target_responseメソッドのかわりに呼び出されますが、クライアントの呼出しを完了させる効果は本質的に同じです。
前述のように、インターセプタは自身でリクエストを処理したり、例外を返したりすることによって、クライアント・リクエストを短絡できます。どちらの場合でも、クライアント・リクエストが実際にターゲット・オブジェクトによって処理されることはありません。
短絡動作は、
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では、呼び出される次のイベントを説明しています。
|
1.
|
クライアント・リクエストがORBに到達し、ORBがインターセプタAからDを順に呼び出します。 |
|
2.
|
リクエストがターゲット・オブジェクトに送られます。 |
|
3.
|
ターゲット・オブジェクトがリクエストを処理して、レスポンスを返します。 |
|
4.
|
レスポンスがクライアント側インターセプタを含むORBに戻ります。次に、ORBは登録された各インターセプタを、リクエストが送出されたときとは逆順に呼び出します。 |
|
5.
|
レスポンスが返されてクライアント・アプリケーションに到達します。 |
ORBはリクエストを受け取ると、各クライアント側インターセプタの
client_invokeオペレーションを呼び出します。戻り値
INVOKE_NO_EXCEPTIONが各
client_invokeオペレーションから戻された場合(通常の場合)、結果として生じたリクエストはORBによってメッセージにマーシャリングされ、ターゲット・オブジェクトに送られます。
次の状況では、ORBは、クライアント方向で残りのインターセプタの
client_responseオペレーションを呼び出すのではなく、これらのインターセプタの
exception_occurredを呼び出し、次に例外をクライアント・アプリケーションに返します。
|
•
|
どの client_invokeオペレーションからの戻り値も、 REPLY_EXCEPTIONとなります。 |
この場合、ORBはリクエストを残りのインターセプタまたはトランスポートに伝播することを中止します。したがって、リクエストはORBによって短絡されます。
|
•
|
どの client_responseオペレーションからの戻り値も、 RESPONSE_EXCEPTIONとなります。 |
この場合、インターセプタはORBに例外を返し、それ以前のリクエストの結果はすべてオーバーライドします。
クライアント側インターセプタの処理の場合と同じく、ORBは各ターゲット側インターセプタの
target_invokeオペレーションを連続的に呼び出します。各
target_invokeオペレーションから戻り値
INVOKE_NO_EXCEPTIONが戻されると、リクエストはターゲット・オブジェクトに渡されます。
次の状況では、ORBは、クライアント方向で残りのインターセプタの
target_responseオペレーションを呼び出すのではなく、これらのインターセプタの
exception_occurredを呼び出し、次に例外をクライアント・アプリケーションに返します。
|
•
|
どの target_invokeオペレーションからの戻り値も、 REPLY_EXCEPTIONとなります。 |
この場合、ORBはリクエストを残りのインターセプタおよびトランスポートに伝播することを中止します。この時点で、ORBはクライアントORBにレスポンスを返し、ターゲットORBはリクエストを短絡します。
|
•
|
どの target_responseオペレーションからの戻り値も、 RESPONSE_EXCEPTIONとなります。 |
この場合、インターセプタはORBに例外を返し、それ以前のリクエストの結果はすべてオーバーライドします。
メタ・オペレーションとは、
CORBA Objectインタフェースをサポートする
is_a、
get_interface、および
non_existentなどのオペレーションです。一部のメタ・オペレーションは、呼出しを発行することなくORBによって実行されますが、それ以外のオペレーション(
is_a、
get_interface、および
non_existentメソッド)ではオブジェクトの呼出しを必要とする場合あります。したがって、これらのオペレーションはインターセプタを開始できます。
オペレーションをCORBA固有の言語でバインディングすると、オペレーション名をIDLで定義した名前から、次の名前に変換できます。
|
•
|
_non_existent (または _not_existent)
|
セキュリティ・ベースのインターセプタを実装している場合は、ORBがこれらのオペレーションをクライアント・リクエストの一部として呼び出す可能性があるため、この振る舞いには注意してください。通常、インターセプタが特定のクライアント・リクエストにだけターゲット・オブジェクトへの送信を許可し、これらのメタ・オペレーションを考慮できないような状況は避けてください。
