WebLogic RMI の機能とガイドライン

以下の節では、WebLogic Server で使用するための RMI のプログラミングで用いる WebLogic RMI の機能について説明します。

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

WebLogic RMI コンパイラ（weblogic.rmic）は、リモートオブジェクトを生成しコンパイルするためのコマンドラインユーティリティです。weblogic.rmic では、クライアントサイドでカスタムリモートオブジェクトインタフェースのための動的プロキシを生成し、サーバサイドオブジェクトにホットコード生成を提供します。

動的プロキシクラスは、クライアントに渡されるシリアライズ可能クラスです。クライアントは、WebLogic RMI レジストリでクラスをルックアップすることによって、そのクラスのプロキシを取得します。クライアントは、あたかもローカルなクラスであるかのようにプロキシのメソッドを呼び出します。プロキシは、要求をシリアライズして WebLogic Server に送ります。

ホットコード生成では、クライアント上の動的プロキシからの要求を処理する、サーバサイドのクラスのバイトコードを作成します。動的に生成されたバイトコードは、クライアント要求をデシリアライズし、実装クラスに対して実行します。次に結果をシリアライズしてクライアントのプロキシへ送り返します。クラスの実装は、Weblogic Server の WebLogic RMI レジストリ内の名前に関連付けられます。

RMI オブジェクトがデプロイされている場合、weblogic.rmic を実行すると、プロキシクラスが自動的に作成され、実行時にホットコード生成機能によってバイトコードが動的に生成されます。weblogic.rmicの使い方については、「手順4．実装クラスを RMI コンパイラでコンパイルする」を参照してください。weblogic.rmicのコマンドラインオプションの一覧については、WebLogic RMI コンパイラのオプションを参照してください。

注意: クラスタ対応クライアントまたは IIOP クライアントの場合は、明示的に weblogic.rmic を実行するだけです（WebLogic RMI over IIOP を使用すると、クライアントは、Internet Inter-ORB Protocol（IIOP）を介して RMI リモートオブジェクトにアクセスできるため、RMI プログラミングモデルが拡張されます）。RMI over IIOP の使用方法の詳細については、『WebLogic RMI over IIOP プログラマーズガイド』を参照してください。

スタブとスケルトンから動的プロキシとバイトコードへの移行

WebLogic Server 6.1 より前のバージョンでは、weblogic.rmic を実行すると、クライアントにはスタブが、サーバサイドにはスケルトンコードが生成されました。今回のバージョンでは、クライアントサイドで生成されていたスタブは動的プロキシに、サーバサイドのスケルトンはバイトコードに置き換えられています。これにより、クラスの生成が不要になりました。

バージョン 6.1 より前の WebLogic RMI オブジェクトをバージョン 6.1 以降の WebLogic Server で実行できるようにするには、それらのオブジェクトに対して weblogic.rmic を再度実行します。これにより、必要なプロキシおよびバイトコードが生成され、デプロイ済みの RMI オブジェクトが有効になります。動的プロキシの詳細については、RMI の動的プロキシを参照してください。

リモートオブジェクトが EJB の場合は、weblogic.ejbc を再度実行すると、バージョン 6.1 より前の WebLogic Server オブジェクトがバージョン 6.1 以降で動作するようになります。weblogic.ejbc の使用方法の詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズガイド』を参照してください。

リモートオブジェクトに対して、-oneway、-clusterable、-stickToFirstServer のうちの 1 つまたは複数のパラメータを使用して weblogic.rmic を再度実行するか、または weblogic.ejbc を再度実行すると、そのオブジェクトのデプロイメント記述子が生成されます。

WebLogic RMI コンパイラは、Java コンパイラがサポートしているオプションをすべて受け入れます。たとえば、コマンドラインのコンパイラオプションに -d \classes examples.hello.HelloImpl を追加できます。ほかにも、Java コンパイラがサポートしているすべてのオプションを使用でき、これらのオプションは直接 Java コンパイラに渡されます。

次の表に、java weblogic.rmic オプションを示します。これらのオプションは、java weblogic.rmic の後、リモートクラス名の前に入力します。

オプション	説明
-help	オプションの説明を表示する。
-version	バージョン情報を出力する。
-dispatchPolicy <queueName>	サービスが WebLogic Server の実行スレッドを取得するために使う、コンフィグレーション済みの実行キューを指定する。詳細については、「実行キューによるスレッド使用の制御」を参照。
-idl	リモートインタフェース用の IDL を生成する。
-idlOverwrite	既存の IDL ファイルを上書きする。
-idlVerbose	IDL情報についての冗長な情報を表示する。
-idlStrict	OMG 規格に従って IDL を生成する。
-idlNoFactories	値型 (value type) のファクトリメソッドを生成しない。
-idlDirectory <idlDirectory>	IDL ファイルを作成するディレクトリを指定する（デフォルトはカレントディレクトリ）。
-clusterable	そのサービスをクラスタ化可能（WebLogic Server クラスタ内の複数のサーバがホストできる）として指定する。各ホスティングオブジェクト、またはレプリカは、共通名でネーミングサービスにバインドされる。そのサービススタブがネーミングサービスから取り出される場合、それはレプリカのリストを保持するレプリカ対応参照を含み、レプリカ間のロードバランシングやフェイルオーバを行う。
-loadAlgorithm <algorithm>	-clusterable と組み合わせた場合だけ使用可能。ロードバランシングおよびフェイルオーバに使用する特定のアルゴリズムのサービスを指定する（デフォルトは weblogic.cluster.loadAlgorithm）。ラウンドロビン、ランダム、重みベースの中から 1 つ選択できる。
-callRouter <callRouterClass>	-clusterable と組み合わせた場合だけ使用可能。ルーティングメソッド呼び出し用に使われるクラスを指定する。このクラスは weblogic.rmi.cluster.CallRouter を実装する必要がある。指定した場合、各メソッド呼び出しの前にそのクラスのインスタンスが呼び出され、そのメソッドパラメータに基づいてルーティングするサーバを指定できる。サーバ名または null が返される。null は現在のロードアルゴリズムが使用されることを示す。
-stickToFirstServer	-clusterable と組み合わせた場合だけ使用可能。セッション維持型ロードバランシングを有効にする。最初の要求をサービスするために選ばれたサーバが、後続のすべての要求にも使用される。
-methodsAreIdempotent	-clusterable と組み合わせた場合だけ使用可能。このクラスのメソッドが多重呼び出し不変であることを示す。これにより、リモートメソッドが呼び出される前に起きた障害かどうか保証できなくても、通信障害があれば、スタブはその復旧を試みることができるようになる。デフォルトでは（このオプションが使われなければ）、スタブはリモートメソッドが呼び出された前に起きたことが保証されている障害に関してだけ再試行する。
-replicaListRefreshInterval <seconds>	-clusterable と組み合わせた場合だけ使用可能。クラスタのレプリカリストをリフレッシュする試みの最小間隔を指定する（デフォルトは 180 秒）。
-iiop	サーバから IIOP スタブを生成する。
-iiopDirectory	IIOP プロキシクラスが作成されるディレクトリを指定する。
-commentary	注釈を出力する。
-nomanglednames	コンパイル時にリモートクラスに固有のプロキシが作成される。
-keepgenerated	WebLogic RMI コンパイラを実行するときに、生成したスタブクラスファイルとスケルトンクラスファイルのソースを保持できる。

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

WebLogic RMI コンパイラには、他にも以下のような機能があります。

動的プロキシまたはプロキシは、リモートオブジェクトのクライアントが使用するクラスです。このクラスは、作成されるときに、実行時に指定されたインタフェースのリストを実装します。

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

WebLogic RMI コンパイラは、デフォルトの動作により、リモートインタフェース用のプロキシと、そのプロキシを共有するリモートクラス用のプロキシを作成します。プロキシは、リモートオブジェクトのクライアントが使用するクラスです。RMI では、動的に生成されたバイトコードとプロキシクラスが使用されます。

たとえば、WebLogic RMI コンパイラでは、example.hello.HelloImpl と counter.example.CiaoImpl は、一対のプロキシクラスとバイトコード、つまりリモートオブジェクト（このサンプルでは example.hello.Hello）によって実装されたリモートインタフェースに適合するプロキシで表わされます。

リモートオブジェクトが複数のインタフェースを実装する場合、プロキシの名前とパッケージは 1 組のインタフェースをエンコードすることによって決定されます。WebLogic RMI コンパイラの -nomanglednames というオプションを使って、デフォルトの動作をオーバーライドできます。このオプションを使用すると、コンパイル時にリモートクラスに固有のプロキシが作成されます。クラス固有のプロキシが検出された場合は、そのプロキシはインタフェース固有のプロキシに優先します。

さらに、WebLogic RMI のプロキシクラスでは、プロキシは final ではありません。同じ場所に配置されたリモートオブジェクトへの参照は、プロキシではなくオブジェクトそのものへの参照です。

rmic を実行すると、WebLogic Server のホットコード生成機能により、メモリ内にサーバクラス用のバイトコードが自動生成されます。バイトコードは、リモートオブジェクトの必要に応じて、動的に生成されます。現在のバージョンの WebLogic Server では、weblogic.rmic を実行しても、オブジェクトのスケルトンクラスは生成されません。

WebLogic Server の RMI 通信では T3 プロトコルが使用されます。このプロトコルは、WebLogic Server と他の Java プログラム (クライアントやその他の WebLogic Server を含む) との間のデータ転送用に最適化されたプロトコルです。サーバインスタンスは、接続先の各 Java 仮想マシン (JVM) を追跡し、JVM のすべてのトラフィックを転送するための T3 接続を作成します。

たとえば、Java クライアントが WebLogic Server 上のエンタープライズ Bean および JDBC 接続プールにアクセスすると、1 つのネットワーク接続が WebLogic Server の JVM とクライアントの JVM との間に確立されます。T3 プロトコルは 1 つの接続上のパケットを見えない形で多重化するため、EJB および JDBC のサービスでは、専用のネットワーク接続を単独で使用しているかのように記述することができます。

2 つのサーバインスタンスや 1 つのサーバインスタンスと 1 つの Java クライアントなど、T3 接続された任意の 2 つの Java プログラムは、定期的にポイントツーポイントの「ハートビート」を使用して、使用可能な状態であることを通知および判定します。各エンドポイントは定期的にハートビートをピアに送るとともに、ピアから継続してハートビートを受け取ることでピアが使用可能な状態であると判定します。

サーバインスタンスがハートビートを送る頻度は、ハートビート間隔 (デフォルトでは 60 秒) で決まります。

ピアからのハートビートがある回数届かなかないと、サーバインスタンスはピアが使用不可の状態であると判定します。この回数は、ハートビート周期 (デフォルトは 4) によって決まります。

したがって、各サーバインスタンスは、ピアをアクセス不能であると判定するまでに、ピアからメッセージ (ハートビートまたは他の通信) のない状態で最大 240 秒 (4 分) 待ちます。

タイムアウトのデフォルト値は変更しないことをお勧めします。