![]() ![]() ![]() ![]() ![]() ![]() ![]() |
注: | 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種類のカテゴリに分類されます。
ClientRequestInterceptor
クラスから継承されます。TargetRequestInterceptor
クラスから継承されます。CORBA環境のOracle Tuxedoシステムは、クライアント・オブジェクトおよびターゲット・オブジェクトの相対的な場所を基準として、インターセプタをインストールして使用できる場所に関する自由度は非常に高くなっています。クライアント・アプリケーションからは、リクエストのターゲットが同じプロセス内にあるのか別のプロセス内にあるのかは、見えません。
クライアント側インターセプタとターゲット・サイド・インターセプタは別個のインタフェースから継承されていますが、両者を単一のソース・ファイル内に実装すると都合のよい場合が多くあります。
次の図は、リクエスト・レベルのインターセプタとOracle Tuxedoシステムの関係を示します。
CORBAインターセプタのOracle Tuxedo実装については、次の事項に留意してください。
呼出しの正常なリクエスト・レスポンス・サイクル1回の間に、クライアント側インターセプタはORBによって2回呼び出されます。
呼出しのリクエスト・レスポンス・サイクル1回の間に、ターゲット・サイド・インターセプタはORBによって2回呼び出されます。
ORBは、登録されたインターセプタのリストを維持します。インターセプタの登録は、管理タスクとして行う操作です。複数のインターセプタをインストールおよび作成できるので、アプリケーション実行時に、ORBはこのリストを使用して、いつ、どの順番でインターセプタを呼び出すべきかを決定します。複数のインターセプタを登録した場合、ORBは各インターセプタを連続的に実行します。複数のインターセプタの呼出しの順序を設定するのも、管理タスクの1つです。
リクエスト・レベルのインターセプタは、以下のような数種類のサービス・アプリケーションを実装する際に、特に有用です。
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つあります。
クライアント側インターセプタを使用するCORBAアプリケーションの実行フローを図1-1に示します。この図では、基本的かつ正常なリクエスト-レスポンス呼出しサイクルを示します。つまり、このサイクルでは例外は発生しません。
図1-1では、以下のイベントを説明しています。
client_invoke
オペレーションを呼び出します。(「複数のリクエスト・レベルのインターセプタの使用方法」では、複数のクライアント側インターセプタがインストールされている場合に生じる現象について説明します。)client_invoke
オペレーションの結果として返される例外がない場合、リクエストはターゲット・オブジェクトへのパスを再開します。client_response
オペレーションを呼び出します。 client_invoke
およびclient_response
オペレーションは各々、クライアント・インターセプタの処理を続行するかどうかを示すステータス値を返します。インターセプタは、例外処理を引き起こす例外ステータス値を返すことがあります。表1-1は、これらのオペレーションから返されるステータス値に応じて生じる現象、およびインターセプタがORBと共に例外を処理する方法を示します。
インターセプタはORBへ例外を戻します。次に、ORBはこれより前のクライアント側インターセプタの各
exception_occurred オペレーションを呼び出します。exception_occurred メソッドは、ORBがクライアント・アプリケーションに例外を戻す前に状態をクリーンアップする機会を、これより前のインターセプタに提供します。これにより、ORBは呼出しを短絡し、呼出しは完了します。exception_occurred メソッドの詳細は、「exception_occurredメソッド」を参照してください。
|
||
クライアント側と同じく、ターゲット・サイド・インターセプタはリクエスト-レスポンス・サイクル中に2回呼び出されます。ターゲット・サイド・インターセプタはTargetRequestInterceptor
クラスから継承されます。このクラスには、次のオペレーションが含まれます。
ターゲット・サイド・インターセプタを使用するCORBAアプリケーションの実行フローを図1-2に示します。この図では、基本的かつ正常なリクエスト-レスポンス呼出しサイクルを示します。つまり、このサイクルでは例外は発生しません。
図1-2では、以下のイベントを説明しています。
target_invoke
オペレーションを呼び出します。(複数のターゲット・サイド・インターセプタがインストールされている場合に生じる現象については「複数のリクエスト・レベルのインターセプタの使用方法」の節で説明します。)target_invoke
オペレーションの実行中に発生する例外がない場合、リクエストがターゲット・オブジェクトへのパスを再開します。target_response
オペレーションを呼び出します。 表1-2は、target_invoke
およびtarget_response
オペレーションによって返されるステータス値に応じて、ターゲット・サイドの呼出しに生じる現象を示し、例外がスローされた場合の動作を説明します。
インターセプタはORBへ例外を戻します。次に、ORBはこれより前のターゲット側インターセプタの各
exception_occurred オペレーションを呼び出します。exception_occurred メソッドは、ORBがクライアントORBに例外を戻す前に状態をクリーンアップする機会を、これより前のインターセプタに提供します。これにより、ターゲットORBは呼出しを短絡し、呼出しは完了します。exception_occurred メソッドの詳細は、「exception_occurredメソッド」を参照してください。
|
||
すべてのインターセプタにexception_occurred
メソッドが存在します。ORBはこのメソッドを、次の状況下で呼び出します。
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では、以下のイベントを説明しています。
ORBはリクエストを受け取ると、各クライアント側インターセプタのclient_invoke
オペレーションを呼び出します。戻り値INVOKE_NO_EXCEPTION
が各client_invoke
オペレーションから戻された場合(通常の場合)、結果として生じたリクエストはORBによってメッセージにマーシャリングされ、ターゲット・オブジェクトに送られます。
次の状況では、ORBは、クライアント方向で残りのインターセプタのclient_response
オペレーションを呼び出すのではなく、これらのインターセプタのexception_occurred
を呼び出し、次に例外をクライアント・アプリケーションに返します。
クライアント側インターセプタの処理の場合と同じく、ORBは各ターゲット側インターセプタのtarget_invoke
オペレーションを連続的に呼び出します。各target_invoke
オペレーションから戻り値INVOKE_NO_EXCEPTION
が戻されると、リクエストはターゲット・オブジェクトに渡されます。
次の状況では、ORBは、クライアント方向で残りのインターセプタのtarget_response
オペレーションを呼び出すのではなく、これらのインターセプタのexception_occurred
を呼び出し、次に例外をクライアント・アプリケーションに返します。
メタ・オペレーションとは、CORBA Object
インタフェースをサポートするis_a
、get_interface
、およびnon_existent
などのオペレーションです。一部のメタ・オペレーションは、呼出しを発行することなくORBによって実行されますが、それ以外のオペレーション(is_a
、get_interface
、およびnon_existent
メソッド)ではオブジェクトの呼出しを必要とする場合あります。したがって、これらのオペレーションはインターセプタを開始できます。
オペレーションをCORBA固有の言語でバインディングすると、オペレーション名をIDLで定義した名前から、次の名前に変換できます。
セキュリティ・ベースのインターセプタを実装している場合は、ORBがこれらのオペレーションをクライアント・リクエストの一部として呼び出す可能性があるため、この振る舞いには注意してください。通常、インターセプタが特定のクライアント・リクエストにだけターゲット・オブジェクトへの送信を許可し、これらのメタ・オペレーションを考慮できないような状況は避けてください。
![]() ![]() ![]() |