![]() ![]() ![]() ![]() |
以下の節では、RMI および RMI over IIOP を使用してプログラミングを行う際の推奨設計パターンについて説明します。
RMI を使用する場合には、java.rmi
を使うことをお勧めします。WebLogic API には weblogic.rmi
API が含まれていますが、これは非推奨となっており、互換性 API としてのみ提供されています。互換性 API として提供されているその他の WebLogic API は以下のとおりです。
コードの移植性を保持するために、ホーム インタフェースをキャストするときには常に PortableRemoteObject を使用してください。次に例を示します。
Propshome home = (PropsHome)
PortableRemoteObject.narrow(
ctx.lookup( "Props" ),
PropsHome.class );
Java EE の開発者は、ワーク コンテキストを使用してプロパティをアプリケーション コンテキストとして定義できます。アプリケーション コンテキストは複数のリモート要求にわたって暗黙的にフローされるので、下流工程のコンポーネントが呼び出し側のクライアントのコンテキストで作業できるようになります。ワーク コンテキストの使用により、プロパティをリモート呼び出しに含めずに渡すことが可能です。ワーク コンテキストは各リモート呼び出しで伝播されるので、呼び出されたコンポーネントではワーク コンテキストに定義されたプロパティを追加したり変更したりできます。同様に、呼び出し側のコンポーネントでもワーク コンテキストにアクセスして、新しいプロパティや更新されたプロパティを取得できます。
ワーク コンテキストは、こうした情報をリモート コンポーネント (診断モニタ、アプリケーション トランザクション、アプリケーション ロードバランシングなど) に渡す必要がある機能の実装と管理を容易にします。また、ワーク コンテキストは、サード パーティ コンポーネントに情報を提供するための便利なメカニズムです。
ワーク コンテキストは、WebLogic Server によってサポートされるすべての要求スコープにユーザ定義のプロパティを伝播できます。このため、ワーク コンテキストは要求スコープ内に存在するすべてのオブジェクト (RMI 呼び出しを含む) で使用できます。詳細については、『WebLogic Server アプリケーションの開発』を参照してください。
WLS RMI では、スタブにおいてセキュリティ コンテキストは引き継がれません。スタブを確立するスレッドは、そのスレッド コンテキスト内に適切なサブジェクトを持ちます。その後スタブが別のスレッドで使用されたり、現在のスレッド コンテキストが何らかの処理により変更された後にスタブが使用された場合、以降のスタブを使用した呼び出しは「SecurityException
」によって失敗する可能性があります。スレッドのコンテキストを変更する可能性のある処理としては、新たなイニシャル コンテキストの確立や WLST のプログラム的な実行などが挙げられます。JMS、JTA、または MDB を複数ドメイン コンフィグレーションで使用している場合にスレッド コンテキストを変更すると、クロスドメイン セキュリティに関する問題が頻繁に発生します。
RMI スタブが別のスレッドで使用される予定である場合は、アプリケーションで JSR-237 ワーク マネージャを使用して、スレッド コンテキストが新しいスレッドに伝播されるよう、スタブが作成されるスレッドのコンテキスト内で新しいスレッドをスケジューリングできます。これが不可能である場合、または元のスレッドのコンテキストが何らかの形で変更された場合、アプリケーションは JAAS でスタブを呼び出すためのコンテキストを再確立します。以下のパブリック API を使用すると、セキュリティ コンテキストを再確立できます。
非同期呼び出しの動作が適しているものの、まだ実装していないレガシー システムにとって、この機能は回避策となります。可能な場合は、以下のような適切な技術をレガシー システムに実装することをお勧めします。
レガシー システムのために RMI タイムアウトを使用する必要がある場合、以下のガイドラインを参照してください。
RequestTimeOutException
は常に呼び出し側に伝播されます。
![]() ![]() ![]() |