TRMI による分散オブジェクト開発の自動化 Automating the Development of Distributed Objects with TRMI 千葉雄一郎∗ 杉山安洋g Summary. TRMI (Transparent Remote Method Invocation) is a mechanism that allows objects to invoke methods of some other objects running on remote Java virtual machines, as if all the objects are running on the same virtual machine. In TRMI, objects are not required to implement special code for invoking methods of remote objects. Invocation of a remote method is carried out transparently to the objects. We have implemented TRMI using RMI, and verified that TRMI has almost same efficiency as Java RMI. 1 はじめに インターネットが発達した現代では，分散システムが人間生活に重要な役割を果たし ている．しかし，分散型のソフトウェアを開発することは，技術的に難しいことも多い． スタンドアロンのソフトウェアを開発するのと同じような手軽さで分散システムが開発 できれば，開発効率の向上が期待できる． 我々は，現在，スタンドアロンシステムを開発するのと同じ手軽さで分散システムを 開発できる方式の研究を行っている．研究の対象は，新規に分散システムを開発する場 合のみならず， 既存の非分散型のソフトウェアを分散型に発展させる場合も含んでいる． 現在は，その研究の第一段階として，Java 言語［5］で記述されたスタンドアロンプ ログラムを分散化させる方式の研究を行っている．この方式は，既存の Java プログラ ムに適応させることも可能であるが，新規に開発するプログラムを手軽に分散化させる ことにも適応可能である． Java 言語には，あるオブジェクトが自分自身とは異なる Java 仮想マシン上に存在す るオブジェクトのメソッド（リモートメソッド）を呼び出すことができる方式として RMI［1］がある．RMI を用いれば，比較的簡単にリモートメソッドの呼び出しを実装す ることが可能である．しかし，そのためには，クライアントであるオブジェクトおよび リモート側のオブジェクトには，分散システムであることを意識したコードが必要とな り，これが RMI を用いたプログラム開発から手軽さを奪っている． 我々は，RMI の概念を発展させ，各々のオブジェクトには分散システムであることを 意識させることなく，オブジェクトを複数の仮想マシン上に分散させ，他の仮想マシン 上のオブジェクトのメソッドを呼び出すことのできる TRMI（Transparent Remote Method Invocation）を開発した．本論文は，TRMI の概要と現在の実装について述べた ものである． 本論文の構成は以下の通りである．まず 2 章で，RMI の問題点を明らかにし，それを 解決するための TRMI の方式について述べる．3 章は，TRMI の現在の実装について述 べる．TRMI は RMI を用いて実装されている．4 章以降では，TRMI の RMI と比較し ての性能評価および関連研究との比較を述べ，最後に現在の実装の問題点をまとめて論 文を締めくくる． ∗ g Yuichiro Chiba, 日本大学大学院工学研究科情報工学専攻 Yasuhiro Sugiyama, 日本大学工学部情報工学科 FOSE2001 なお，本論文では，以下のような用語の使い分けを行う．あるオブジェクトが他のオ ブジェクトのメソッドを呼び出している場合，呼び出す側のオブジェクトをクライアン ト，呼び出される側のオブジェクトをサーバとよぶ．また，あるオブジェクトのメソッ ドが，ネットワーク越しに他の Java 仮想マシン上のオブジェクトから呼び出すことが できる時，そのメソッドをリモートメソッドと呼ぶ．リモートメソッドを含むオブジェ クトをリモートオブジェクトあるいはリモートサーバと呼ぶ． 2 透過的リモートメソッド呼び出し 2.1 RMI の概要と問題点 RMI とは，異なる Java 仮想マシン上に存在するオブジェクトのメソッド（リモート メソッド）を呼び出すための仕組みである．RMI を用いることにより，クライアントと なるオブジェクトは，通常のオブジェクトのメソッドを呼び出す方法に近い方法でリモ ートメソッドを呼び出すことが可能になる． RMI では，図 1 に示すように，クライアントがリモートサーバのメソッドを呼び出す 際に，スタブとスケルトンという 2 つのオブジェクトを経由する．スタブはクライアン ト側に生成され，スケルトンはサーバ側に作成される．スタブは，リモートサーバと同 じ外部インタフェースを持つ（即ち外部に公開されたメソッドのシグニチャがすべて一 致する）ので，クライアントは，通常のメソッド呼び出しに近い方式で，リモートサーバ のメソッドを呼び出す代わりにスタブのメソッドを呼び出すことができる．実際にリモ ートメソッドを呼び出すのはスタブの役割である．クライアントから自分自身のメソッ ドを呼び出されたスタブは，スケルトンを経由して，リモートサーバの対応する同名の メソッドを呼び出し，その実行結果をクライアントに返す． レジストリ 検索 クライアント RMI スタブ サーバ生成 プログラム 登録 ダウンロード リモート サーバ メソッド呼出し 実行結果 生成 アプリケーション層 RMI スケルトン RMI 層 図 1 RMI によるリモートメソッドの実行 スタブとスケルトンは，rmic と呼ばれるツールにより自動生成されるため，プログラ マは直接記述する必要はない．しかし，クライアント側では，参照したいリモートサー バのスタブを生成するという作業が発生する．クライアントがリモートサーバのスタブ を得るためには，レジストリと呼ばれるネームサーバを直接アクセスする必要がある． クライアントはレジストリを検索し，必要なリモートサーバが見つかった場合には，そ のスタブをレジストリからダウンロード1する． 一方，リモートサーバ側では，サーバのインスタンスを生成し，生成したインスタン スをレジストリに登録するプログラムを記述する必要が発生する．リモートサーバのク ラスに main メソッドを追加し，インスタンスの生成を行う場合もある．リモートサー 1 スタブのバイトコードは，レジストリ以外からダウンロードする場合もある． Automating the Development of Distributed Objects with TRMI バがレジストリに登録されると，スケルトンは自動的に生成される． このように，RMI は，一見は手軽にリモートメソッドの呼び出しを可能とするかのよ うに思えるが，実は，スタブのダウンロードや，リモートサーバのレジストリへの登録 などのために，クライアントやリモートサーバのクラスに，スタンドアロンシステムに は存在しないコードを記述する必要が発生してしまう． これは，主に，スタブやスケルトンのバイトコードの生成は，自動的に行われるもの の，実行上はクライアントがスタブやレジストリを直接アクセスしたり，リモートサー バをレジストリに明示的に登録したりする必要があるためである．これを層（レイヤ）と いう言葉を用いて表現すれば，図 1 のようになる．まず，スタブは，そのバイトコード は rmic により自動生成されるものの， クライアントにより直接アクセスされるために， クライアントやリモートサーバと同レベルの層に存在すると考えられる．この層をアプ リケーション層と呼ぶ．また，スケルトンは，そのバイトコードの生成およびインスタ ンスの生成ともに，クライアントやリモートオブジェクトからは透過的に行われるため に，アプリケーション層とは別の層に存在すると見ることができる．この層を RMI 層 と呼ぶ．最後に，レジストリであるが，これもクライアントおよびリモートオブジェク トから直接アクセスされるため， アプリケーション層に存在すると考えることができる． このように，RMI が複雑なのは， スタブやレジストリといった RMI 特有のオブジェク トが，一般のオブジェクトと同一のアプリケーション層に存在するためである． さらに，リモートサーバのクラスを定義するためには，いくつかの構文上の制限も存 在する．まず，リモートサーバは，自分がクライアントに対して公開するリモートメソ ッドの一覧からなる Java インタフェースを実装(implements)する必要がある．また， この Java インタフェースは，java.rmi.Remote インタフェースのサブインタフェース である必要がある．さらには，リモートサーバは，レジストリに登録可能であるために は，java.rmi.server.UnicastRemoteObject のサブクラスである必要があるという制約 も存在する．このように，RMI を用いて分散オブジェクトを実装するためには，実装上 に多くの制約が存在することがわかる． 2.2 TRMI の概要 TRMI を用いると，クライアントであるオブジェクトは，別の仮想マシン上のリモー トサーバのメソッドを，あたかも同一の仮想マシン上にそのサーバが存在するかのよう に呼び出すことが可能になる．しかも，クライアントやサーバには RMI の場合必要で あった分散処理のための特別のコードを追加する必要がない． TRMI でもスタブとスケルトン，およびレジストリは存在する．しかし，図 2 に示す ように，TRMI のスタブやスケルトンは，クライアントやサーバとは異なる TRMI 層に 存在し，クライアントやリモートサーバは，これらの存在を一切気にする必要はない． RMI の場合はクライアントやリモートサーバが直接アクセスしていたスタブやスケル トンおよびレジストリを，TRMI においてはクライアントやリモートサーバから隠すこ とにより，クライアントやリモートサーバには分散システムであることを意識させるこ となく，リモートメソッドの呼び出しが可能となる．このようなメソッドの呼び出しを 透過的リモートメソッド呼び出しと呼ぶ． 今後，RMI のスタブ，スケルトンと TRMI のスタブ，スケルトンを区別する必要が ある場合には，前者を RMI スタブ，RMI スケルトン，後者を TRMI スタブ，TRMI ス ケルトンと呼ぶこととする． FOSE2001 透過的メソッド呼び出し リモート サーバ クライアント アプリケーション層 TRMI スタブ 実行結果 検索 TRMI 層 メソッド呼び出し TRMI レジストリ TRMI スケルトン 登録 図 2 TRMI によるリモートメソッドの実行 クライアントがリモートサーバのメソッドを通常のメソッド呼び出しの方式で呼び 出すと，それが，TRMI スタブと TRMI スケルトンを経由して処理される．TRMI と RMI におけるスタブ，スケルトンの役割の主な違いは表 1 の通りである． TRMI スケルトンは，RMI スケルトン同様，リモート側に生成されるオブジェクト である．サーバ側の Java 仮想マシンでサーバのインスタンスを生成するコードが実行 されると，サーバのインスタンスの代わりに，TRMI スケルトンのインスタンスが生成 される．TRMI スケルトンは，生成されると，まず，サーバのインスタンスを生成する． さらに，自分自身をサーバの代わりにレジストリに登録する．従って，RMI では明示的 にリモートサーバをレジストリに登録する必要があったが，TRMI ではその必要はない． 表 1 RMI と TRMI におけるスタブとスケルトンの違い クライアント スタブ スケルトン リモートサーバ RMI TRMI (1) リモートオブジェクトをレジストリに検 索し，スタブを生成 (2) スタブのメソッドを呼び出す リモートメソッドの呼び出しを中継 リモートオブジェクトのメソッドを直接呼び出 す リモートメソッドの呼び出しを中継 (1) スケルトンをレジストリに検索しスケルト ンと接続を確立 (2) リモートメソッドの呼び出しを中継 (1) レジストリに登録される (2) リモートメソッドの呼び出しを中継 レジストリに登録される 一方，TRMI スタブは，リモートサーバと同一の外部インタフェースを持つオブジェ クトで，クライアント側に生成される．クライアントがリモートサーバのメソッドを呼 び出すコードを実行すると，代わりに TRMI スタブのメソッドが呼び出される．TRMI スタブは，TRMI スケルトンをレジストリに検索し，見つかった TRMI スケルトンと接 続を確立する．TRMI スタブは，自分自身のメソッドが呼び出されると，TRMI スケル トンを経由してリモートオブジェクトの同名のメソッドの呼び出しを行い，その実行結 果をクライアントに返す．従って，クライアントは TRMI スケルトンを TRMI レジス トリに検索し，TRMI スタブをダウンロードする必要は無い．また，TRMI スタブのメ ソッドを明示的に呼び出す必要は無く，あくまでリモートサーバのメソッドを直接呼び 出すと，そのメソッド呼び出しが，TRMI スタブのメソッドを経由して，透過的に処理 されるようになる． Automating the Development of Distributed Objects with TRMI 3 TRMI の実装 TRMI は，RMI を用いて実装した．TRMI スタブは，TRMI スケルトンと接続を確 立し，リモートサーバのリモートメソッドを呼び出すために RMI を用いる． 3.1 RMI を用いた TRMI の実装の概要 RMI を用いた TRMI の実装の概要は，図 3 の通りである．なお，TRMI レジストリ は，現在の実装では，RMI レジストリをそのまま用いている． 透過的メソッド呼び出し リモート サーバ クライアント RMI レジストリ 検索 登録 TRMI スタブ クライアント側 アプリケーション層 RMI スタブ ダウンロード RMI スケルトン TRMI層 TRMI スケルトン RMI 層 サーバ側 図 3 RMI を用いた TRMI の実装 まず，TRMI スケルトンは，RMI のリモートオブジェクトとして実装した．TRMI ス ケルトンは，生成されると，自分自身を RMI レジストリに登録する．TRMI スケルト ンが RMI レジストリに登録されると，TRMI スケルトンの RMI スケルトンが生成され る．リモートサーバの代わりに，TRMI スケルトンを RMI レジストリに登録すること により，RMI では必要であったサーバをリモートオブジェクト化する際に必要であった サーバクラスの変更が必要でなくなった．これらの変更とは，(i) java.rmi.Remote イン タ フ ェ ー ス を 継 承 し た リ モ ー ト メ ソ ッ ド の イ ン タ フ ェ ー ス の 実 装 ； (ii) java.rmi.server.UnicastRemoteObject の継承，などである．これらの変更に対応する 記述は，TRMI スケルトン中で行われる． 一方，TRMI スタブは，TRMI スケルトンを RMI レジストリにおいて検索し，その RMI スタブを生成する．こうすることにより，TRMI スタブは，TRMI スケルトンのリ モートメソッドを呼び出すことができるようになる．クライアント側では，RMI では本 来クライアントが行っていた RMI 特有の作業，即ち：(i) RMI レジストリへのリモート サーバの検索；(ii) RMI スタブの生成；(iii) リモートオブジェクトのメソッドの代わり に RMI スタブの同名のメソッドを呼び出す，といった作業を，TRMI スタブがクライ アントに代わって行う．これにより，クライアントは，自分の呼び出すメソッドを持つ オブジェクトがリモートオブジェクトであることを認識する必要がなくなった． また，TRMI スタブや TRMI スケルトンがリモートサーバのメソッドの呼び出しを中 継するメカニズムは以下の通りである．今回の実装では，TRMI スケルトンは，リモー トサーバと同じ外部インタフェースを持つオブジェクトとして実装した．クライアント がリモートサーバのリモートメソッドを呼び出すと，まず，同名の TRMI スタブのメソ FOSE2001 ッドが呼び出される．TRMI スタブのメソッドは，同名の TRMI スケルトンのメソッド を RMI を用いて呼び出す．TRMI スケルトンのメソッドは，サーバのメソッドを直接 呼び出し，実行結果を受け取る．その結果は，TRMI スタブに返され，さらに，クライ アントに返される． 3.2 TRMI スタブとスケルトンの生成 まず，TRMI スタブと TRMI スケルトンのバイトコードの生成は，後述するツール trmic によって行う． また，TRMI スタブや TRMI スケルトンのインスタンスの生成は，クライアントやサ ーバには透過的に行われる．この透過性の実現は，Java 仮想マシンのクラスローダを変 更［3］することにより実現した．クラスローダは，リモートサーバのインスタンスを 生成することを要求された場合，その TRMI スケルトンと TRMI スタブのバイトコー ドの存在の有無を確認し，存在する方のインスタンスを生成する．従って，クライアン ト側には，TRMI スタブのバイトコードを配置し，サーバ側には TRMI スケルトンのバ イトコードを配置しておく必要がある．RMI とは異なり，TRMI スタブと TRMI スケ ルトンのバイトコードの配置が重要となるので，それらのネットワーク経由でのダウン ロードはサポートしていない． 3.3 例外の取り扱い リモートオブジェクトを使用する際に注意が必要な点の一つは，例外(Exception)の取 り扱いである．リモートメソッドを呼び出す際に，通常のメソッド呼び出しでは発生し ないような例外が発生する可能性がある．現在の TRMI では，RMI を使用して実装を 行っているので，基本的には RMI Exception がその対象となる． TRMI では， リモートオブジェクト側で発生する RMI Exception を，通常の Exception へ変換してクライアントへ通知することにより，この問題に対応している．もし，クラ イアントがいくつかの Exception を自分自身で処理あるいは中継(throws)している場合 は，RMI Exception を TRMI スタブで捕捉し，クライアントの処理可能な Exception に変換してクライアントに渡すことにより，クライアントを変更することなく RMI Exception の処理ができるようにしている．なお，RMI Exception とクライアントが処 理可能な Exception の対応付けは，TRMI スタブを生成する際に，プログラマが選択で きる．なお，クライアントがもともと例外の処理を行っていない場合は，実行時エラー となる． なお，RMI では，サーバ側で発生した通常の例外は ServerException にラッピングさ れてクライアントへ転送される．よってクライアントは ServerException を調べること で，サーバ側で発生した通常の例外の詳細を知ることができる．TRMI では，TRMI ス タブがこのラッピングされた例外をもとの例外に戻し，クライアントへ通知することが できる． 3.4 リモートメソッドの引数および戻り値における参照の扱い Java では，あるオブジェクトが同じ Java 仮想マシンに存在するオブジェクトのメソ ッドを呼び出して，オブジェクトの受け渡しをする場合に，実際はオブジェクトそのも のを渡すのではなく，オブジェクトへの参照の受け渡しを行う．しかし，別の Java 仮 想マシンにあるオブジェクトのリモートメソッドを呼び出してオブジェクトの受け渡し Automating the Development of Distributed Objects with TRMI を行う場合には，オブジェクトへの参照を渡しても，Java 仮想マシンが違うために参照 先のオブジェクトを扱うことができない． このような場合 RMI では，メソッドの引数や戻り値として受け渡しされるオブジェ クトがリモートオブジェクトの場合は，そのオブジェクトのスタブを渡す．そうでない 場合は，そのオブジェクトがシリアライズ可能であれば，オブジェクトをシリアライズ して，オブジェクトのコピーを渡す． TRMI においては，リモートオブジェクトの参照が受け渡しされた場合は，そのリモ ートオブジェクトの TRMI スタブを受け渡しする．また，リモートオブジェクトでない が，シリアライズ可能なオブジェクトの場合は，シリアライズしてそのコピーを受け渡 す．ただし，シリアライズしてコピーを渡すと，参照を渡す場合と比べて，プログラム の動作が変わってくる可能性がある．シリアライズするかどうかの判断は，現在はプロ グラマに任せている． TRMI において，リモートオブジェクトの参照がリモートメソッドの引数や戻り値で 受け渡しされる場合の処理は図 4 の通りである．ここでは，あるリモートサーバ S が別 のリモートオブジェクトである X のインスタンスを生成し，その参照をクライアントに 渡す場合を例にして説明する．なお，図中では，あるリモートオブジェクト R があった 時，R の TRMI スタブ，TRMI スケルトン，RMI スタブ，RMI スケルトンを，それぞ れ R_tstub，R_tskel，R_stub，R_skel で表している． リモートサーバ S クライアント側 クライアント X のTRMI スケルトン X_tskel の参照 Ｘ_tstub の参照 アプリケーション層 X_tstub S_tskel 生成 X_tskel_stub の参照 生成 RMI 層 X_tskel_stub リモート オブジェクトX 生成 生成 S_tstub TRMI 層 生成 S_tskel_stub X_tskel X_tskel の参照 生成 S_tskel_skel X_tskel_skel サーバ側 図 4 リモートオブジェクトの参照の受け渡し まず，リモートサーバ S がリモートオブジェクト X を生成すると，X の代わりに X の TRMI スケルトン X_tskel が生成される．これは，前述したように，変更されたクラ スローダが行う．X_tskel は，X 自身を生成する．リモートサーバ S が，X の参照をク ライアント側に送ろうとすると，実はそれは，X の TRMI スケルトン X_tskel の参照で ある． それは，S の TRMI スケルトン S_tskel および， その RMI スケルトン S_tskel_skel を経由して，S の TRMI スケルトンの RMI スタブ S_tskel_stub に渡される．受け取っ た S_tskel_stub は，その参照が RMI のリモートオブジェクトである X の TRMI スケル トンの参照であることから，その RMI スタブ X_tskel_stub を生成し，その参照を S の TRMI スタブ S_tstub に渡す．S_tstub では，受け取った X_tskel_stub の参照をもとに， X の TRMI スタブ X_tstub を生成し，そのローカルな参照をクライアントに渡す．これ FOSE2001 Server.java trmic Server_tstub.java (TRMI スタブ) 呼び出し rmic Server_tskel_stub.java (RMI スタブ) クライアント側クラス Server_interface.java (RMI インタフェース) Server_tskel.java (TRMI スケルトン) Server_tskel_skel.java (RMI スケルトン) サーバ側クラス 図 5 trmic によるサーバプログラムの処理 により，クライアントが X の TRMI スタブの参照を受け取ることができ，その参照を経 由して X をアクセスできるようになる． 3.5 trmic について 我々は，TRMI による自動分散化を行う trmic というツールを開発した．この trmic は，TRMI スタブや TRMI スケルトンのソースコードをサーバのソースコードをもとに 生成するツールである．例えば，Server.java というサーバのソースコードを trmic で処 理すると，図 5 に示すような，クラスが生成される．また，rmic も自動的に呼び出し， 生成されたクラスの RMI スタブや RMI スケルトンを生成する． 図 6 に示すウィンドウは，trmic を制御するウィンドウである．右下のウィンドウで は，サーバを設置するマシンの IP アドレス，TRMI スケルトンへの main メソッドの追 加の有無等を設定できる．左のウィンドウでは TRMI による分散システムで発生する可 能性のある例外と通常の例外との対応づけを行うことができる．対応づけは初期値を用 いるほかに，クライアントに用意されている例外処理に合わせて適切な対応付けを行う ことや，例外発生時にシステムを強制終了させること等の選択が可能である．右上のウ 図 6 trmic の GUI Automating the Development of Distributed Objects with TRMI ィンドウでは，対象としているサーバクラスのリモートメソッドの引数や戻り値として クラスが使用されていた場合に，それぞれのクラスについてリモートオブジェクト化す るかシリアライズ可能とするかを選択していく．シリアライズ可能を選択する場合，ウ ィンドウの左側にあるアイコンに対し S を選択する．また，リモートオブジェクト化す る場合は，アイコンに対して R を選択する．なお，現時点では，シリアライズ可能にす る処理は実装が完了したが，リモートオブジェクト化の処理は実装途中である． 4 性能評価 RMI によって分散化したシステムが RMI スタブと RMI スケルトンの 2 つを中継し てサーバのメソッドを呼び出すことに対し，我々が開発したツール trmic を使用してシ ステムを分散化した場合は RMI スタブと RMI スケルトンに加えて TRMI スタブと TRMI スケルトンを中継してリモートメソッドを呼び出す．中継するオブジェクトの数 が増えることによって，オーバーヘッドがどの程度大きくなるかを以下の実験によって 調べた． 4.1 実験方法 TRMI の性能評価をするために，2 つのスタンドアロンのプログラム A と B を用意し た． プログラム A 文字を 1000 個入力してバブルソートを行うプログラム プログラム B 文字を複数個入力して，初めの文字 100 個を左に 1 つシフトする プログラム この実験では A と B のプログラムに対して，RMI による分散化と TRMI による分散 化を行ったプログラムを作る．バブルソートなどの処理はサーバ側のメソッドで行い， クライアントはそのメソッドを呼び出す処理を行う．実験では，クライアントがサーバ のメソッドを呼び出し，メソッドの処理開始から終了までにかかる時間の平均を測定し た．なお，測定した時間は，スタンドアロンのシステムにおけるオブジェクトの生成に かかる時間や，分散システムにおけるリモートオブジェクトの検索，スタブの生成など にかかる時間は含まない．なお，プログラム B については，引数の個数が 1000 個，2000 個，3000 個の場合にそれぞれ測定した．なお，プログラム B のシフト処理は，引数の 個数に依存しないものである． 実験を行ったマシンの条件を表 2 に示す．スタンドアロンのシステムによる実験はマ シン 1 上で行った．また，RMI と TRMI による実験は，サーバを 表 2 計測に使用したマシンの構成 マシン 1 上，クライアントをマシ ン 2 上でそれぞれ動作させ，実験 マシン 1 マシン 2 するマシンのメモリ使用状況など CPU Celeron333 Celeron400 が同じになるように，毎回コンピ メモリ 128MByte 192MByte ュータを再起動して実験を行った． JDK 1.3.0_02（SUN） 1.3.0（SUN） JIT OS LAN OFF OFF RedHatLINUX6.1 RedHatLINUX7.0 100BASE-TX 100BASE-TX 4.2 実験結果 表 3 に計測結果を示す．A およ び B における実験結果から，RMI と TRMI による分散システムにお FOSE2001 表 3 実験結果 A B(1000 個) B(2000 個) B(3000 個) スタンドアロン 2550.9 42.3 42.3 42.4 RMI 2715.3 206.7 347.9 488.0 TRMI 2715.9 206.9 348.1 488.3 （単位：ミリ秒） いて， メソッドの呼び出し開始から終了までの時間がほぼ同等であると言える． 従って， TRMI は RMI とほぼ同等の速度で処理することが可能であることがわかる．これは TRMI によって，TRMI スタブや TRMI スケルトンでの処理が増加するが，これらは 1 つの JVM 上で処理されるため，RMI を用いたリモートメソッドの呼び出しによるオー バーヘッドよりもはるかに小さいためである． また，リモートメソッド呼び出しにおけるオーバーヘッドの原因として，メソッド呼 び出しをネットワーク経由で行うためのオーバーヘッド（以下ネットワークのオーバー ヘッドと呼ぶ）と，引数のシリアライズにかかるオーバーヘッドが考えられるため，それ ぞれについてどの位の時間がかかっているのかを実験結果より考察した． 表 3 の B の計測結果から，引数 1000 個の場合のオーバーヘッドの全体は約 165ms である．また，B の引数を 2000 個，3000 個に変えた結果から，引数が 1000 個増加す ると，約 140ms のオーバーヘッドが増加することがわかる．これは，シリアライズの オーバーヘッドであると考えられる．これらのことから我々が実験を行った環境におい て，ネットワークにおけるオーバーヘッドは約 25ms であり，引数のシリアライズにか かるオーバーヘッドは引数 1 個あたり約 0.14ms であるといえる． 従って，TRMI と RMI による分散システムにおいて，オーバーヘッドは，シリアライズによるものがネットワ ークによるものよりも小さい．ただし，引数の個数が増えた場合にはネットワークによ るオーバーヘッドは殆ど増えないが，シリアライズによるオーバーヘッドは増加する． 5 既存の研究との比較 我々の開発した trmic に関連するツールとして RMIHelper［6］というツールが開発 されている．RMIHelper は RMI による分散化を自動で行うツールであり，透過的にリ モートメソッドを呼ぶことは出来ない．また，trmic ではリモートにおいて発生する例 外の扱いを通常の例外に対応付けすることで，開発者はネットワークを意識せずにリモ ートにおける詳細な例外処理を行うことができるが， RMIHepler ではリモートにおいて 発生する例外処理を手動で行うか，標準的な例外処理を自動で行うため，開発者への負 担が大きくなる．以上のことも含め，RMIHelper を用いるよりも trmic を用いる方が容 易に分散システムを開発できる．trmic と RMIHelper の比較を表 4 に示す． 表 4 既存の研究との比較 実現方式 リモートメソッド 呼び出し リモートにおける例外処理 開発者に必要と される知識 trmic TRMI 透過的 自動で通常の例外に変換 少ない RMIHelper RMI 非透過的 手動で行うか標準的な例外処 理を行う 多い Automating the Development of Distributed Objects with TRMI これらのことから，我々が開発した trmic は RMIHelper よりも開発者がネットワー クを意識せずにより透過的にリモートメソッドを呼び出すことができ，容易に分散シス テムを開発することができるため優れているといえる． 6 TRMI と既存の方式との比較 この章では TRMI と，既存の方式である RMI，HORB（Hirano Object Request Broker）［2］，CORBA（Common Object Request Broker Architecture）［4］を比較し，開 発者が分散システムであることを意識せずに，分散システムを開発することについて， どの方式が最も適しているのかを検討する．比較の対象とする RMI は 2.1 で説明したリ モートオブジェクトを呼び出すための方式であり，HORB は産業技術総合研究所の平野 聡氏によって開発された，リモートメソッドを呼び出すための方式である．そして CORBA は OMG（Object Management Group）によって仕様が標準化され，様々なプロ グラム言語で記述された，分散して存在する複数のシステムを統合することが可能な規 格である．比較は以下の項目について行う． （a）既存の非分散システムを分散化する際のソースコードの変更量． （b）リモートメソッドを呼び出す際の例外処理の行い方． （c）オブジェクトとリモートオブジェクトの参照の渡し方の同一性． まず（a）についてであるが，TRMI は最も変更量が少なく，独自の例外処理などを後 から加える必要の無い場合など，ソースコードに全く変更を行わずに分散化を行うこと が可能である．RMI と HORB は，ソースコードに必ず変更を行う必要がある．これは， RMI と HORB では，ツールによって自動生成したスタブやスケルトン，あるいはそれ に該当するクラスを使用することを，ソースコードに記述する必要があるためである． CORBA は最も変更量が多い．これは IDL（Interface Definition Language）を用いてプ ログラム言語に依存せずにメソッドを呼び出す仕組みを使用することをソースコードに 記述するためである． 次に（b）についてであるが，TRMI では分散システムを意識した例外処理は行わなく ても良い．これは 3.3 で述べた通り，リモートメソッドを呼び出す際に発生する例外を 自動的に通常の例外へと対応付けするためである．一方，他の方式では例外の対応付け が行われないため，分散システムを意識した例外処理を，開発者が手動で行う必要があ る． 最後に（c）についてであるが，TRMI，RMI，HORB では，リモートオブジェクの参 照の渡し方は，オブジェクトの参照の渡し方と同一の渡し方となる．一方 CORBA では， リモートオブジェクトを特定するための，通常のオブジェクトの参照とは異なるオブジ ェクトリファレンスを渡すことを明確に記述しなければならないため，参照の渡し方は 同一にならない． 表 5 TRMI,RMI,HORB,CORBA の比較 （a） （b） （c） TRMI 最も少ない 通常の例外へ対応付ける 同一 RMI 少ない 手動 同一 HORB 少ない 手動 同一 CORBA 多い 手動 異なる FOSE2001 以上の比較結果を表 5 に示す． 比較結果から，ソースコードの変更量が最も少なく， 分散システムを意識した例外処理を行わずに済み，オブジェクトとリモートオブジェク トの参照の渡し方が同一である TRMI が，分散システムを意識せずに分散システムを開 発することに最も適している．ただし TRMI は，分散システムを開発者に意識させない 方式であるため，開発者がリモート処理に関する例外処理を自分で行うことができない など，リモート処理の記述の自由度について，RMI などの他の方式に劣る場合がある． 7 まとめと今後の課題 我々は，trmic というツールを開発し，透過的にリモートメソッドを呼ぶことができ るようになり，開発者は容易に分散システムを開発することが可能となった．ただし現 時点では，trmic にはいくつかの制限事項があり，これらを解決することが今後の課題 である． クライアントとサーバが多対一あるいは多対多となる場合の分散化：現在の trmic で は，複数のクラスをリモート化する場合，どのクラスを最初に trmic で処理するかによ り，分散化がうまくいかない場合がある．そこで，既存のシステムを TRMI で分散化す る場合は，まずシステム全体を解析し，分散化の最適な手順を得られるようにするなど の改善が必要である． 非同期あるいは同期のリモートメソッドの並列呼び出し： ：すべてのリモートメソッド へのアクセスはスタブやスケルトンを経由して行われるため，これらのオブジェクトを 並列化しない限り，非同期のメソッド呼び出しは，実装できない． 機能の追加方式の確立：現在は，スタブやスケルトンには，ツールで自動生成されて しまうため，プログラマが，自分に必要な処理を追加することができない．何らかの形 で，スタブやスケルトンにプログラマのコードが追加できる方式を検討したい． また，今後の新たな検討事項として以下のことが挙げられる． • CORBA などの RMI 以外の技術によるシステムの自動分散化についての検討 • TRMI が効果的に適用できる分野と，適用できない分野についての分析と検討 これらの検討事項を解決していくことで多くのシステムに対して最も適した分散化を行えるよう なシステムに改善して行く予定である． 参考文献 ［1］ ［2］ ［3］ ［4］ ［5］ ［6］ Downing，T.B.，JavaRMI: Remote Method Invocation，IDG Books，1998 平野聡，HORB ドキュメント，http://horb.etl.go.jp/horb-j/doc/ Liang，S. and G. Bracha，Dynamic Class Loading in the Java Virtual Machine，in Proceedings of the OOPSLA’98，pages36-44，ACM，1998 Orfali，R. and D. Harkey，Java&CORBA C/S プログラミング，日経 BP 社，1999 Sun Micro Systems，Java2 SDK Standard Edition Documentation. http://java.sun.com/j2se/1.3/docs/ 油利耕平，溝口佳寛，RMI を用いた分散システム構築の自動化，FOSE2000 論文集， pp245-248，2000
© Copyright 2024 ExpyDoc
