| Oracle® Fusion Middleware Oracle WebLogic Server RMIアプリケーションの開発 12c (12.2.1.2.0) E82859-02 |
|
 前 |
 次 |
この章には次の項が含まれます:
WebLogic RMIはクライアントとサーバーのフレームワークに分けられています。実行時のクライアントはサーバーのソケットを持たないため、接続をリスニングしていません。クライアントはサーバーを介して接続を取得します。サーバーだけがクライアントのソケットを認識します。このため、クライアントにあるリモート・オブジェクトをホストする場合、クライアントはWebLogic Serverに接続していなければなりません。WebLogic Serverはクライアントへのリクエストを処理して、クライアントへ情報を渡します。つまり、クライアント側のRMIオブジェクトには、クラスタ内であっても単一のWebLogic Serverを介してのみアクセスできます。クライアント側のRMIオブジェクトがJNDIネーミング・サービスにバインドされている場合、そのオブジェクトへのアクセスは、そのバインドを実行したサーバーにアクセスできる場合に限り可能です。
WebLogic Serverは認証、認可、およびJava EEのセキュリティ・サービスを実装しています。詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』を参照してください。
Oracle WebLogic Serverでは、Java Platform, Enterprise Edition (Java EE)プログラミング・モデルのトランザクションがサポートされています。WebLogic RMIアプリケーションでのトランザクションの使用の詳細は、以下を参照してください。
Oracle WebLogic Server JTAアプリケーションの開発のWebLogic Server RMIアプリケーションのトランザクションでは、WebLogic RMIアプリケーションでのトランザクションの実装の概要について説明します。
Oracle WebLogic Server JTAアプリケーションの開発のRMIアプリケーションのトランザクションでは、のRMIアプリケーションでトランザクションを実装する場合の一般的なガイドラインを示します。
以下の節では、WebLogic ServerでサポートされるRMIオブジェクトのフェイルオーバーとロード・バランシングについて説明します。
クラスタリングされたRMIアプリケーションのフェイルオーバーは、オブジェクトのレプリカ対応スタブを使用して行われます。クライアントがレプリカ対応スタブを通じて障害が発生したサービスに対して呼出しを行うと、スタブはその障害を検出し、別のレプリカに対してその呼出しを再試行します。
クライアントでJava EEサービスを利用できるようにするために、WebLogicは、特定のサービスのRMIスタブを、特定の名前でJNDIツリーにバインドします。RMIオブジェクトの他のインスタンスがクラスタ内の他のサーバーにデプロイされると、RMIスタブはその場所で更新されます。クラスタ内のサーバーに障害が発生すると、他のサーバーのJNDIツリー内のRMIスタブが更新されてサーバーの障害を反映します。
特定のRMIオブジェクトのレプリカ対応スタブを生成するには、WebLogic RMIコンパイラの-clusterableオプションを指定します(表5-1を参照)。例:
$ java weblogic.rmic -clusterable classes
詳細は、Oracle WebLogic Serverクラスタの管理のEJBとRMIのレプリケーションとフェイルオーバーを参照してください。
RMIオブジェクトのロード・バランシング・アルゴリズムは、クラスタリングされたオブジェクトで取得されるレプリカ対応スタブに保持されます。特定のRMIオブジェクトに対してロード・バランシング・アルゴリズムを、WebLogic RMIコンパイラの-loadAlgorithm <algorithm>オプションを使用して指定します。オブジェクトに構成したロード・バランシング・アルゴリズムは、クラスタのデフォルトのロード・バランシング・アルゴリズムをオーバーライドします。WebLogic Server RMIコンパイラでは、以下のロード・バランシング・アルゴリズムをサポートしています。
ラウンドロビンのロード・バランシング
重みベースのロード・バランシング
ランダム・ロード・バランシング
サーバー・アフィニティ・ロード・バランシング・アルゴリズム
たとえば、RMIオブジェクトのロード・バランシングをラウンドロビンに設定するには、次のrmicオプションを使用します。
$ java weblogic.rmic -clusterable -loadAlgorithm round-robin classes
RMIオブジェクトのロード・バランシングを重みベースのサーバー・アフィニティに設定するには、次のrmicオプションを使用します。
$ java weblogic.rmic -clusterable -loadAlgorithm weight-based -stickToFirstServer classes
詳細は、Oracle WebLogic Serverクラスタの管理の EJBとRMIオブジェクトのロード・バランシング を参照してください。
パラメータ・ベースのルーティングでは、ロード・バランシング動作をより詳細なレベルで制御できます。クラスタリングされたオブジェクトを、weblogic.rmi.cluster.CallRouterインタフェースを使用してCallRouterに割り当てることができます。これはパラメータにより各呼出しの前に呼び出されるクラスです。CallRouterはそのパラメータを自由に調べ、呼出しの送り先となるネーム・サーバーを返します。
weblogic.rmi.cluster.CallRouter.
Class java.lang.Object
Interface weblogic.rmi.cluster.CallRouter
(extends java.io.Serializable)
パラメータ・ベースのルーティングを可能にするには、このインタフェースを実装するクラスをRMIコンパイラ(rmic)に与える必要があります。以下のオプションを使って(すべて1行に入力します)、サービス実装時にrmicを実行します。
$ java weblogic.rmic -clusterable -callRouter <callRouterClass> <remoteObjectClass>
リモート・メソッドが呼び出されるたびに、クラスタリング可能なスタブからコール・ルーターを呼び出します。コール・ルーターは、その呼出しの宛先のサーバーの名前を返します。
クラスタ内の各サーバーは、コンソールで定義された名前で固有に識別されます。これらの名前は、メソッド・ルーターがサーバーを識別するための名前となります。
ExampleImplというクラスを例に説明します。このクラスは、メソッドfooでリモート・インタフェースExampleを実装します。
public class ExampleImpl implements Example {
public void foo(String arg) { return arg; }
}
このCallRouterを実装したExampleRouterでは、'arg' < "n"の場合にすべてのfoo呼出しがserver1 (server1に届かない場合はserver3)に送られ、'arg' >= "n"の場合にすべての呼出しがserver2 (server2に届かない場合はserver3)に送られます。
public class ExampleRouter implements CallRouter {
private static final String[] aToM = { "server1", "server3" };
private static final String[] nToZ = { "server2", "server3" };
public String[] getServerList(Method m, Object[] params) {
if (m.GetName().equals("foo")) {
if (((String)params[0]).charAt(0) < 'n') {
return aToM;
} else {
return nToZ;
}
} else {
return null;
}
}
}
次のrmic呼出しは、ExampleRouterとExampleImplを関連付けて、パラメータ・ベースのルーティングを有効にします。
$ rmic -clusterable -callRouter ExampleRouter ExampleImpl
リモート・コールが完了するタイムアウト期間を指定できます。あるいは、クライアントがweblogic.rmi.extensions.RequestTimeoutExceptionを受信します。
WebLogic Serverには、次の接続タイムアウトと読取りタイムアウトがあります。
接続タイムアウトを使用して、ブートストラップと再確立の対象となるサーバーへの接続をクライアントが待機する時間を定義します。次の表で、このタイムアウトの設定方法について説明します。
表3-1 接続タイムアウトの設定
| 説明 | スコープ |
|---|---|
システム・プロパティ: |
サーバー |
|
サーバー |
|
チャネル |
|
スレッド |
読取りタイムアウトを使用して、クライアントがサーバーからのレスポンスの受信を待機する時間を定義します。次の表で、このタイムアウト値を設定する様々な方法について説明します。
表3-2 読取りタイムアウトの設定
| 説明 | スコープ |
|---|---|
リモート・スタブのルックアップに使用されるJNDI (InitialContext)環境で |
インタフェース(スタブ) |
リモート・オブジェクト実装クラスでメソッド・レベル・アノテーション( |
メソッド |
非アノテーション付きクラスの |
メソッド |
EJB Bean実装クラスでメソッド・レベル・アノテーション( |
メソッド |
EJB記述子( |
メソッド |
読取りタイムアウトを実装する際は次のことを考慮します。
WebLogic Server EJB Bean実装では、トランザクション・タイムアウト(@TransactionTimeoutSeconds)がremote-client-timeoutよりも大きい場合、トランザクション・タイムアウトが優先されます。
複数の読取りタイムアウトの優先順位は、次のルールで決まります。
クライアントのrtd.xmlで指定されたタイムアウトは、他のどの読取りタイムアウトよりも優先されます。
RmiMethodアノテーションを使用して指定されたタイムアウトは、WLContext.RESPONSE_READ_TIMEOUTよりも優先されます。
次のコードでは、タイムアウトを含むrtd.xmlファイルの例を示します。
<rmi Name="foo">
<method
name="methodname"
timeout="timeoutinmilliseconds">
</method>
</rmi>
クライアントでrtd.xml fileを生成するには、クライアントとサーバーの両方で-Dweblogic.RefreshClientRuntimeDescriptor=trueを設定します。フラグがtrueの場合、rtd.xmlファイルをクラスパスで使用できるかどうかの確認が行われます。使用可能な場合、ファイルは読み取られ、指定された値が使用されます。
weblogic.rmicを使って、レプリケートされないスタブをクラスタ内に生成することもできます。このようなスタブは、「固定」サービスと呼ばれています。これらのスタブは登録されたホストからのみ使用可能であり、透過的なフェイルオーバーやロード・バランシングは提供しません。固定サービスはレプリケートされたクラスタ全体のJNDIツリーにバインドされるので、クラスタ全体で使用可能になります。ただし、固定サービスをホストする各サーバーが故障しても、クライアントは別のサーバーにフェイルオーバーすることはできません。
特定のRMIオブジェクトのレプリケートされないスタブを生成するには、WebLogic RMIコンパイラの-clusterableオプションは指定しません(表5-1を参照)。例:
$ java weblogic.rmic classes
動的プロキシまたはプロキシは、リモート・オブジェクトのクライアントで使用されるクラスです。このクラスには、実行時にクラスが作成されたときに指定されるインタフェースのリストが実装されます。RMIでは、動的に生成されたバイトコードとプロキシ・クラスが使用されます。プロキシ・クラスは、クライアントのJava仮想マシン(JVM)で呼び出されるインスタンスです。プロキシ・クラスは、呼び出されたメソッド名とその引数をマーシャリングして、リモートのJVMに転送します。リモート呼出しが終了して戻された後に、プロキシ・クラスはクライアント上でその結果のマーシャリングを解除します。生成されたバイトコード(リモートJVMに存在)は、リモートJVM上で呼び出されたメソッドと引数のマーシャリングを解除し、リモート・オブジェクトのインスタンスのメソッドを呼び出した後、結果をマーシャリングしてクライアントに戻します。
