11 アプリケーション設計のベスト・プラクティス

この章では、RMIおよびRMI over IIOPを使用してプログラミングを行う際の推奨設計パターンについて説明します。

この章には次の項が含まれます:

java.rmiの使用

RMIユーザーはjava.rmiを使用することをお薦めします。http://docs.oracle.com/javase/6/docs/api/java/rmi/package-summary.htmlを参照してください。Weblogic APIにはweblogic.rmi APIが含まれていますが、これは非推奨となっており、互換性APIとしてのみ提供されています。互換性APIとして提供されているその他のWebLogic APIは以下のとおりです。

PortableRemoteObjectの使用

コードの移植性を保持するために、ホーム・インタフェースをキャストするときには常にPortableRemoteObjectを使用してください。例:

Propshome home = (PropsHome)
PortableRemoteObject.narrow(
ctx.lookup( "Props" ),
PropsHome.class );

WebLogicワーク・コンテキストの使用

ベスト・プラクティスは、ワーク・エリアを使用する方法です。

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() - サブジェクトを再開します。