2 WebLogic RMIの機能

この章では、WebLogic Serverで使用するためのRMIのプログラミングに必要なWebLogic RMIの機能とガイドラインについて説明します。

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

WebLogic RMIクライアント

WebLogic RMIはクライアントとサーバーのフレームワークに分けられています。実行時のクライアントはサーバーのソケットを持たないため、接続をリスニングしていません。クライアントはサーバーを介して接続を取得します。サーバーだけがクライアントのソケットを認識します。このため、クライアントにあるリモート・オブジェクトをホストする場合、クライアントはWebLogic Serverに接続していなければなりません。WebLogic Serverはクライアントへのリクエストを処理して、クライアントへ情報を渡します。つまり、クライアント側のRMIオブジェクトには、クラスタ内であっても単一のWebLogic Serverを介してのみアクセスできます。クライアント側のRMIオブジェクトがJNDIネーミング・サービスにバインドされている場合、そのオブジェクトへのアクセスは、そのバインドを実行したサーバーにアクセスできる場合に限り可能です。

WebLogic RMIのセキュリティのサポート

WebLogic Serverは認証、認可、およびJava EEのセキュリティ・サービスを実装しています。『WebLogicセキュリティ・サービスによるアプリケーションの開発』を参照してください。

WebLogic RMIのトランザクションのサポート

Oracle WebLogic Serverでは、Java Platform, Enterprise Edition (Java EE)プログラミング・モデルのトランザクションがサポートされています。WebLogic RMIアプリケーションでのトランザクションの使用の詳細は、以下を参照してください。

RMIオブジェクトのフェイルオーバーとロード・バランシング

以下の節では、WebLogic ServerでサポートされるRMIオブジェクトのフェイルオーバーとロード・バランシングについて説明します。

クラスタリングされたRMIアプリケーション

クラスタリングされたRMIアプリケーションのフェイルオーバーは、オブジェクトのレプリカ対応スタブを使用して行われます。クライアントがレプリカ対応スタブを通じて障害が発生したサービスに対して呼出しを行うと、スタブはその障害を検出し、別のレプリカに対してその呼出しを再試行します。

クライアントでJava EEサービスを利用できるようにするために、WebLogicは、特定のサービスのRMIスタブを、特定の名前でJNDIツリーにバインドします。RMIオブジェクトの他のインスタンスがクラスタ内の他のサーバーにデプロイされると、RMIスタブはその場所で更新されます。クラスタ内のサーバーに障害が発生すると、他のサーバーのJNDIツリー内のRMIスタブが更新されてサーバーの障害を反映します。

特定のRMIオブジェクトのレプリカ対応スタブを生成するには、WebLogic RMIコンパイラの-clusterableオプションを指定します(表4-1を参照)。たとえば:

   $ java weblogic.rmic -clusterable classes

『Oracle WebLogic Serverクラスタの管理』EJBとRMIのレプリケーションとフェイルオーバーに関する項を参照してください。

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>

リモート・メソッドが呼び出されるたびに、クラスタリング可能なスタブからコール・ルーターを呼び出します。コール・ルーターは、その呼出しの宛先のサーバーの名前を返します。

クラスタ内の各サーバーは、WebLogic Serverコンソールで定義された名前で固有に識別されます。これらの名前は、メソッド・ルーターがサーバーを識別するための名前となります。

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呼出しは、ExampleRouterExampleImplを関連付けて、パラメータ・ベースのルーティングを有効にします。

   $ rmic -clusterable -callRouter ExampleRouter ExampleImpl
カスタム呼出しルーティングと連結の最適化

オブジェクトがレプリカを呼び出している同じサーバー・インスタンス上にレプリカがある場合、ローカル・レプリカを使用する方が効率的なので、その呼出しはロード・バランシングの対象にはなりません。『Oracle WebLogic Serverクラスタの管理』連結されたオブジェクトの最適化に関する項を参照してください。

リクエスト・タイムアウト

リモート・コールが完了するタイムアウト期間を指定できます。あるいは、クライアントがweblogic.rmi.extensions.RequestTimeoutExceptionを受信します。

WebLogic Serverには、次の接続タイムアウトと読取りタイムアウトがあります。

接続タイムアウトの使用

接続タイムアウトを使用して、ブートストラップと再確立の対象となるサーバーへの接続をクライアントが待機する時間を定義します。次の表で、このタイムアウトの設定方法について説明します。

表2-1 接続タイムアウトの設定

説明 スコープ

システム・プロパティ: -Dweblogic.ConnectTimeout=seconds

サーバー

KernelMBean.ConnectTimeoutプロパティを設定します

サーバー

NetworkAccessPointMBean.connectTimeoutプロパティを設定します。デフォルト以外のチャネルの場合のみ、サーバー・スコープ設定をオーバーライドします。このチャネル定義を使用して確立された接続のみがこのタイムアウトの影響を受けます。

チャネル

WLContext.CONNECT_TIMEOUTを設定して、サーバーへの接続を確立します。(コンテキストのスコープ内で、接続のブートストラップと失われた接続の再確立の両方に使用されます。)

スレッド

読取りタイムアウトの使用

読取りタイムアウトを使用して、クライアントがサーバーからのレスポンスの受信を待機する時間を定義します。次の表で、このタイムアウト値を設定する様々な方法について説明します。

表2-2 読取りタイムアウトの設定

説明 スコープ

リモート・スタブのルックアップに使用されるJNDI (InitialContext)環境でWLContext.RESPONSE_READ_TIMEOUTを設定します。

インタフェース(スタブ)

リモート・オブジェクト実装クラスでメソッド・レベル・アノテーション(@RmiMethod(timeout=<値>))を指定します。

メソッド

非アノテーション付きクラスのrtd.xmlファイルのメソッド定義でタイムアウト属性を設定します。「タイムアウトを含むrtd.xmlファイルの例」を参照してください

メソッド

EJB Bean実装クラスでメソッド・レベル・アノテーション(@TransactionTimeoutSeconds(<timeout>)))を指定します。

メソッド

EJB記述子(weblogic-ejb-jar.xml)でリモート・クライアント・タイムアウトを指定します。「タイムアウトを含むweblogic-ejb-jar.xmlファイルの例」を参照してください

メソッド

読取りタイムアウトを実装する際は次のことを考慮します。

  • WebLogic Server EJB Bean実装では、トランザクション・タイムアウト(@TransactionTimeoutSeconds)がremote-client-timeoutよりも大きい場合、トランザクション・タイムアウトが優先されます。

  • 複数の読取りタイムアウトの優先順位は、次のルールで決まります。

    • クライアントのrtd.xmlで指定されたタイムアウトは、他のどの読取りタイムアウトよりも優先されます。

    • RmiMethodアノテーションを使用して指定されたタイムアウトは、WLContext.RESPONSE_READ_TIMEOUTよりも優先されます。

タイムアウトを含むrtd.xmlファイルの例

次のコードでは、タイムアウトを含むrtd.xmlファイルの例を示します。

<rmi Name="foo">
   <method
       name="methodname"
       timeout="timeoutinmilliseconds">
   </method>
</rmi>

クライアントでrtd.xml fileを生成するには、クライアントとサーバーの両方で-Dweblogic.RefreshClientRuntimeDescriptor=trueを設定します。フラグがtrueの場合、rtd.xmlファイルをクラスパスで使用できるかどうかの確認が行われます。使用可能な場合、ファイルは読み取られ、指定された値が使用されます。

タイムアウトを含むweblogic-ejb-jar.xmlファイルの例

次のコードでは、weblogic-ejb-jar.xmlファイルでremote-client-timeoutを指定する方法の例を示します。

<weblogic-enterprise-bean>
     <ejb-name>AccountBean</ejb-name>
     . . .
     <remote-client-timeout>5</remote-client-timeout>
</weblogic-enterprise-bean>

固定サービスの作成

weblogic.rmicを使って、レプリケートされないスタブをクラスタ内に生成することもできます。このようなスタブは、「固定」サービスと呼ばれています。これらのスタブは登録されたホストからのみ使用可能であり、透過的なフェイルオーバーやロード・バランシングは提供しません。固定サービスはレプリケートされたクラスタ全体のJNDIツリーにバインドされるので、クラスタ全体で使用可能になります。ただし、固定サービスをホストする各サーバーが故障しても、クライアントは別のサーバーにフェイルオーバーすることはできません。

特定のRMIオブジェクトのレプリケートされないスタブを生成するには、WebLogic RMIコンパイラの-clusterableオプションは指定しません(表4-1を参照)。たとえば:

   $ java weblogic.rmic classes

RMIの動的プロキシ

動的プロキシまたはプロキシは、リモート・オブジェクトのクライアントで使用されるクラスです。このクラスには、実行時にクラスが作成されたときに指定されるインタフェースのリストが実装されます。RMIでは、動的に生成されたバイトコードとプロキシ・クラスが使用されます。プロキシ・クラスは、クライアントのJava仮想マシン(JVM)で呼び出されるインスタンスです。プロキシ・クラスは、呼び出されたメソッド名とその引数をマーシャリングして、リモートのJVMに転送します。リモート呼出しが終了して戻された後に、プロキシ・クラスはクライアント上でその結果のマーシャリングを解除します。生成されたバイトコード(リモートJVMに存在)は、リモートJVM上で呼び出されたメソッドと引数のマーシャリングを解除し、リモート・オブジェクトのインスタンスのメソッドを呼び出した後、結果をマーシャリングしてクライアントに戻します。