|
|
| 注意: | 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::DataOutputStreamRequestLevelInterceptor::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がこれらのオペレーションをクライアント・リクエストの一部として呼び出す可能性があるため、この振る舞いには注意してください。通常、インターセプタが特定のクライアント・リクエストにだけターゲット・オブジェクトへの送信を許可し、これらのメタ・オペレーションを考慮できないような状況は避けてください。
  
|