Oracle® Fusion Middleware Oracle WebLogic Server RMIのプログラミング 11g リリース1(10.3.4) B61626-02 |
|
前 |
次 |
以下の節では、RMIおよびRMI over IIOPを使用してプログラミングを行う際の推奨設計パターンについて説明します。
Oracleでは、RMIユーザーはjava.rmi
を使用することをお薦めします。http://java.sun.com/javase/6/docs/api/java/rmi/package-summary.html
を参照してください。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呼出しを含む)で使用できます。詳細は、『Oracle WebLogic Serverアプリケーションの開発』を参照してください。
WLS RMIでは、スタブにおいてセキュリティ・コンテキストは引き継がれません。スタブを確立するスレッドは、そのスレッド・コンテキスト内に適切なサブジェクトを持ちます。その後スタブが別のスレッドで使用されたり、現在のスレッド・コンテキストが何らかの処理により変更された後にスタブが使用された場合、以降のスタブを使用した呼出しは「SecurityException」
によって失敗する可能性があります。スレッドのコンテキストを変更する可能性のある処理としては、新たなイニシャル・コンテキストの確立やWLSTのプログラム的な実行などが挙げられます。JMS、JTA、またはMDBを複数ドメイン構成で使用している場合にスレッド・コンテキストを変更すると、クロス・ドメイン・セキュリティに関する問題が頻繁に発生します。
RMIスタブが別のスレッドで使用される予定である場合は、アプリケーションでJSR-237ワーク・マネージャを使用して、スレッド・コンテキストが新しいスレッドに伝播されるよう、スタブが作成されるスレッドのコンテキスト内で新しいスレッドをスケジューリングできます。これが不可能である場合、または元のスレッドのコンテキストが何らかの形で変更された場合、アプリケーションはJAASでスタブを呼び出すためのコンテキストを再確立します。以下のパブリックAPIを使用すると、セキュリティ・コンテキストを再確立できます。
weblogic.security.Security.getCurrentSubject()
- スレッドの現在のオブジェクトを取得します。
weblogic.security.Security.runAs()
- サブジェクトを再開します。
非同期呼出しの動作が適しているものの、まだ実装していないレガシー・システムにとって、この機能は回避策となります。可能な場合は、以下のような適切な技術をレガシー・システムに実装することをお薦めします。
非同期RMI呼出し
JMSおよびメッセージドリブンBean (MDB)
HTTPサーブレット・アプリケーション
レガシー・システムのためにRMIタイムアウトを使用する必要がある場合、以下のガイドラインを参照してください。
RMIタイムアウトは、以下の3つの条件が満たされる場合にのみ使用します。
メソッド呼出しは多重呼出し不変であり、状態の変更はない
メソッド呼出しがトランザクション非対応である
呼出しにJMSリソースが関与していない
リクエストがタイムアウトするときに、別のクラスタ・ノードへの透過的なフェイルオーバーは行われません。RequestTimeOutException
は常に呼出し側に伝播されます。
サーバーではタイムアウトしたリクエストの処理が続行されます。クライアントは呼出しを再試行する前に、サーバーでのそのリクエストの状態を確認する必要があります。
サーバーがタイムアウトになると、クライアントはクライアント側のクラスタ参照でサーバーをアクセス不能として指定できます。これにより、指定された時間にわたってそのサーバーに呼出しが送られなくなります。