JavaVM 上での非手続オブジェクト転送を可能とする直列化方式の構築
赤井 雄樹
＊1，山口 大祐
＊2，甲斐 宗徳
＊3An Implementation of Serializing Method for Non-procedural Object Transfer between JavaVMs
Yuuki AKAI
＊1, Daisuke YAMAGUCHI
＊2, Munenori KAI
＊3ABSTRACT： In a heterogeneous processing environment in a computer network where multiple PCs
running JavaVM on them are connected to, it is very useful to make any class instance movable among any PCs. However, JavaVM can’t inherently load and execute unknown classes dynamically which are not in the class path specified at startup of the JavaVM. In this research, we propose and develop a new mechanism to recognize and execute any unknown class dynamically by implementing a hierarchical class loader, special object stream and dispatch mechanism for transferred objects. This proposed technology is useful and indispensable component technology for parallel distributed processing system based on mobile agent system with strong migration mobility. This technology makes it possible to implement various non-stop software services.
Keywords：Java serializing method, Non-procedural object transfer, strong process migration,
parallel distributed processing
（Received April 5, 2011） １．はじめに １．１．研究背景 現在でも，コンピュータの利用により解決したいが計 算量が膨大なため解決が困難な問題はまだ数多く残って いる。そのような問題を解くために一つのコンピュータ のハードウェアを拡張して高速化していくのは物理的限 界の存在やコスト面が大きなハードルとなる。そこでそ れらの問題をソフトウェア面から解決する一つの策とし て並列分散処理がある。これは，ネットワークに接続さ れている複数のマシンの余剰となっている計算資源を有 効に活用し，一台のコンピュータ以上の高速処理を達成 するものである。 ネットワークを介した分散処理において，核となる部 分の一つにどのようなデータを相互にやり取りするかと いう事が挙げられる。
ORB，CORBA，Struts等，一般的に知られるフレー ムワークがあるが，その基本的な利用はサーバクライア ント型である。本研究では，巡航型の実行コードを可能 とする為のシステム設計とそれに付随する技術に関する 調査・検証・実装方式の提案を行う。 計算資源として多くのPCを用いたいという事と，要 求されるPCの環境が均一でなくても一つのネットワー クとして構成できる事，また計算処理をそのネットワー ク内の最適なPCを選択して実行可能である形が好まし い。具体的な例を挙げれば，UNIX 環境のクラスタと Windows 環境のクラスタ上で同じ計算主体が相互に転 送可能である形である。このようなヘテロ環境での相互 接続を可能にする手段として，JavaVMとそのVM上で のネットワーク処理を用いる事でOSやマシン構成を考 慮することなく一般的なPCとしてネットワーク構成さ れていれば計算環境として使う事が可能となる。 JavaVM 上での通信処理であれば，ObjectStream を 用いることで透過的にインスタンスを扱うことができる。 ローカルのPCとリモートのPCで継続してインスタン ス操作が可能なのである。このインスタンスとはクラス から生成されたオブジェクトであり，計算処理中のメン バ変数を保持している。 しかしながら，インスタンス情報はクラス固有であり， そのクラスを構成する情報がローカル PC とリモート PC で異なる場合には，インスタンスを透過的に扱うこ とが出来ない。例えばローカルPC上にのみに存在する クラスの情報をリモートPCが知りえない為である。 成蹊大学理工学研究報告 J. Fac. Sci. Tech., Seikei Univ. Vol.48 No.1 (2011) pp.9-13
*1：理工学研究科理工学専攻修士学生
*2：理工学研究科理工学専攻修士学生
RMI
等の多くの実装ではクラス解決の為に，URI
で 指定されたサーバなどに動的に問い合わせる事で解決す るが，実行開始するPC
への物理的なネットワーク通信 経路のトポロジによっては明確な遅延になる上，多くの リモートPC
から実行開始するPC
への不定的かつ大量 のリクエストが飛ぶことが想定される。 その為，インスタンスを転送後に復元させるため，必 要なクラス情報データ転送の方法を考える必要がある。 本研究で想定しているのは規模が不定で随時増加減少 するPC
群からなるネットワークである。その環境下で 計算主体としてのクラスインスタンスをどのようにすれ ば復元できるのかという事に焦点をあて，その実現に必 要な機能とJavaVM
環境下での制約や，実現可能な実 装を示す。 過去数年にわたり，著者は分散環境における自律型ア プリケーションフレームワークのAgentSphere
1)の開発 に携わってきたが，これはAgentSphere
が目指すマイグ レーション機能を実現するための根底的な技術開発でも ある。 １．２．並行研究：モバイルエージェントシステム AgentSphere の概要 ネ ッ ト ワ ー ク で 繋 が れ た コ ン ピ ュ ー タ 上 でAgentSphere
を起動することにより，そのマシンはAgentSphere
ネットワークに参加したことになる。AgentSphere
は他のマシンから移動してくるモバイルエ ージェントに活動の場を提供する。また，自身のマシン からのエージェントの起動を行うことができる。エージ ェントは各マシンの負荷状況を考慮して移動するなど自 律的に振舞う。これにより自律型並列分散処理を実現す る。 １．３．昨年度までの研究の流れ2003
年度まで，本研究では既存のモバイルエージェ ントシステムであるAgentSpace
を利用し，その拡張を 行ってきた。しかし，AgentSpace
はエージェントのモ ビリティに弱マイグレーションを採用しており，実行状 態を完全な形のまま移動することができない。そこで， モビリティとして強マイグレーションを採用する独自の システムであるAgentSphere
の開発へと移行した。 強マイグレーションを実現するJavaVM
を用いたシ ステムとしては，JavaGo
などの先例がある。それらは 強マイグレーションを実現しているものの，JavaVM
の 改変が行われているためJavaVM
のバージョンアップ が行われるたびに修正を行う必要がある。そこで，本研 究では，JavaVM
の編集なしに強マイグレーションを実 現するための理論研究が行われてきた。それによりコー ドの変換手法が確立され，コード自動変換器が開発され た。そして，2008
年度からはそれを利用して実際にシ ステムとして運用可能にするための研究が始まり，2009
年度ではユーザインタフェース及びエージェント 活動管理機構の拡充を行った。 １．４．本年度研究目的Java
の標準的な実装にはリモートのクラス機能を呼 び出す実装は存在するが，受動的に転送クラスを認識し， 動的に起動中のVM
にプラグインする機構は存在しな い。加えて，リモートへのオブジェクトインスタンス転 送をおこなう場合に，未知クラスを扱う標準的な設計は 存在しない。 本年度は昨年度までの研究段階で限定的な実装であっ た部分の改修および，拡張を行う。具体的にはクラスの 動的更新と差分更新を可能とするクラスローダの設計， 遠隔オブジェクトインスタンスの復帰(デシリアライズ) を可能とするオブジェクトストリームの設計，未知クラ スの転送を考慮した通信方式の構築を行う。その上で， これらの機能を用いる事で可能となる巡航型クラスの原 子転送とオブジェクトデシリアライズ及びメソッド呼び 出しの有効な実装を検証する。２．巡航型クラスの原子転送とオブジェクト直列化
２．１．概要 分散オブジェクトでかつ，そのオブジェクトが巡航型 の機能を備えるために必要な機能の一つに未知クラスの 受け入れがある。これはローカルとリモートという 2 点 間において，ローカルで読みだされ実行したクラスとそ のオブジェクトインスタンスをリモートへ転送する場合 に，リモートがクラスを動的に認識し，そのオブジェク トインスタンスを復帰(デシリアライズ)させる事を指す。 ローカルでの認識クラスをリモートに認識させる事とオ ブジェクトシリアライズ・デシリアライズの仕組みは一 貫しているようで別の理屈で作られており，(Java の標 準仕様といえる)この二つの仕組みを連携させる必要が ある。 ２．２．オブジェクトシリアライズ・デシリアライズJava
においてシリアライズインターフェースを備え るクラスはシリアライズ可能である。これはインスタン スをバイナリ化する事であり，このバイナリを転送すれば，転送先でデシリアライズする事が可能である。しか しながら，リモート環境下へオブジェクトをシリアライ ズするのであれば，その構成クラスの情報が必要であり， 標準のシリアライズ機能をそのまま利用することは難し い。 インスタンスの送信元であれば，クラスからクラスロ ーダを参照できることから送信用のデータを特定出来る 為，拡張は容易であるが，送信先のリモート環境下でオ ブジェクトを復帰するには予めクラス解決をする必要が あり，その実現にはクラスローダ生成・選択の必要があ る。 ２．３．オブジェクトシリアライズ・デシリアライズ クラスローダの一般的な設計では検索委譲先として親 クラスローダへのリンクを持つとされる(後述)。つまり， ユーザクラスローダを設計した場合，祖先にシステムク ラスローダを持つ必要がある。この仕組みは
Java
の標 準 API と実行時カレントディレクトリのJava
プログラ ムのクラスを認識しているクラスローダがシステムクラ スローダである為，標準API
のクラス等を扱うクラス をユーザクラスローダで読み込んだ場合に必要であり， すべてのクラスはObject
型継承である以上，必ずこの 設計となる。 しかし，最終的にシステムクラスローダへのリンクが 可能であれば親子関係のリンク設計に関しては自由度が 高く，クラスの動的追加，更新の頻度に応じてマルチレ ベル化設計が可能である。親側で定義されたデータ構造 クラスを用いる事や親側で定義されたクラスを継承する といった使い方を想定した設計が可能である。このクラ スローダを2.2
節でのオブジェクトストリームに組み込 む形となる。 また，クラスのロードの際には，そのクラスが用いて いるクラスの再帰的なロードを行うのだが，実行時の呼 び出し順序と，シリアライズ時の呼び出し順序，デシリ アライズ時の呼び出し順序は少しずつ異なり，この順序 が問題とならないように設計する必要がある。 ClassLoaderA ClassLoaderB ClassLoaderMA ClassLoaderMB ClassLoaderC User-Level Middle-Level System-Level ブートストラップ システム Fig.02.3 マルチレベルクラスローダ設計例 ２．４．オブジェクトシリアライズ・デシリアライズ 多階層化と細分化の為にクラスローダを分割するにあ たって，考慮すべき点がある。それはクラスローダ間の 委譲関係であり，これはクラスローダの親子関係のよう に表現される。クラス間継承関係の親子とは異なり， 「あるクラスローダがクラス解決を図る前に検索要求を 一旦委譲する先」を親と呼ぶ。 クラスローダを設計するに当たり，クラスローダクラ スを継承して作成するが，予め用意されているコンスト ラクタには，その委譲先としての親クラスローダを引数 として渡すようになっている。つまり，クラスローダを Java の慣習に則り作成するのであれば，親クラスロー ダを一つ想定して作るべきである。クラスローダはこの 親子関係を用いて再帰的にクラス検索とクラス解決をし ており，この標準で用意されているルーチンを使って多 階層化を実現する。 クラスローダの検索委譲の例を挙げる。 Fig.02.4-1 クラス集約例Fig.02.4-1
の例では三つのクラス関係を示す。Class A があり，Class B
はClass A
をメンバとして持ち，さ らにClass C
がClass B
をメンバとして持つ場合に，Class A
はClass B
と同じクラスローダか，Class B
より親のクラスローダに読まれている必要があり，さらに
Class B
はClass C
と同じクラスローダかClass C
より親のクラスローダに読まれている必要がある。 子クラスローダは一つの親クラスローダの参照を持ち， クラス解決の為の検索時に，検索を委譲する先として用 いる。
Fig.02.4-1
の例ではClass C
が出現した際に，Class C
にはメンバとしてClass B
が含まれる為，これ を解決しなければならない。その際にClassLoaderC
は，親の
ClassLoaderB
に検索委譲をし，Class B
を解決す る。同様にClass A
はClassLoaderA
で解決される。こ の例の場合には集約に対して関連するクラスローダの委 譲先が一元的であるため，問題はなく，クラス間の継承 関係の場合でも単一継承しか許容されない為，ClassLoader
間の委譲関係は単純に済む。 しかし，集約関係の場合には複雑なクラスローダ親子 関係を必要とする場合がある。以下に例を示す。 Fig.02.4-2 複数からの集約例Class ListA
とClass MapB
というクラスが存在し，それぞれが
ClassLoaderA
とClassLoaderB
によってロードされているとする。これらは互いに親子関係はない
とする。この時
Class DataC
をそれらの子にあたるClassLoaderC
で読み込むとする。Class DataC
はメンバに
Class ListA
とClass MapB
を
持つ。この場合，検索委譲先が一個であると，該当クラスを見つけることが できない。
Class DataC
は意味的に複数の親を持つ必要がある。 クラス間継承であればJava
は単一継承である為，親は 唯一で事足りるかもしれないが，メンバに関してはそう で あ る と は 言 え な い 。 そ の 為 ，ClassLoaderC
はClassLoaderA
とClassLoaderB
のどちらも検索できな ければいけない。それを可能とする為には，クラスロー ダを複数内部に持つクラスローダを設計する必要があ る。 Fig.02.4-3 クラスローダをラップするクラスローダ Fig.02.4-3 では，クラスローダをラップするクラスロ ーダの設計を示している。2.3 節で示したマルチレベル 化の細かな実装例となる。クラスローダは検索委譲先の 親を一つだけ持つことが出来るので，クラスローダをラ ップするクラスローダを委譲先としている。ラップする クラスローダは，ラップされるクラスローダが該当クラ スを解決できるかどうかを順に精査していき，可能なク ラスローダが見つかった場合はラップされているクラス ローダで解決し，見つからなかった場合は更に委譲先へ と検索要求をする。 ラップされるクラスローダには，クラスデータのバイ ナリを取得できる機能を搭載し，この情報を用いてクラ スローダのリモートでの再生成を行う。この事は次節で 説明する。 ２．５．未知クラスの転送を考慮した転送方式 オブジェクトのデシリアライズの為にはクラスのバイ ナリデータが必要である。この事は2.2
節，2.3
節及び2.4
節で説明した。しかし，クラスバイナリデータは単 体であるとは限らず，独自実装した構造体のようなクラ スを用いている場合がある。その場合，クラスが用いて いるクラスを含めて転送しなければいけない。転送すべ きクラス一覧を生成する方法として，該当クラスローダ 自身が解決可能なクラス一覧のバイナリデータをすべて 送るという形である。 この設計の場合，厳密にはある特定のクラスにとって 不要なクラスのデータさえ一緒に送る事がある。この設 計にする理由の一つに，「Java
のクラス解決のタイミン グは実行時に出現したタイミングである」という事が挙 げられる。 対案の設計として，クラスが出現した情報をすべてロ ギングし，そのクラスデータを一つにまとめて送るとい う設計が考えられるが，次の想定から却下した。 例として挙げられるのは，頻度の低い例外処理中での み使われるクラスが存在した場合，ローカルで例外が発 生しない状態のまま転送し，リモートで例外が発生した 時にクラス解決が不可能であるというものだ。 オ ブ ジ ェ ク ト の シ リ ア ラ イ ズ に 際 し て ， ObjectStream を用いて，オブジェクトインスタンスの 情報とクラスデータを一つにまとめて送る事でリモート 先での復帰を実現する。しかし，インスタンスからクラ スデータを取得し，シリアライズデータに付加する形で 転送を行うと失敗してしまう。Fig.02.5-1 継承クラス例 インスタンスデータ中でのクラスの出現順序が継承関 係などで必要とされる順序と異なるためで，オブジェク ト復帰時にクラス解決の再帰呼び出しで失敗する為であ る。 Fig.02.5-2 復帰に失敗する例 その為，インスタンスのシリアライズデータよりも前 にクラスのデータを付加する形にデータの並び替えを行 い。予めクラスローダ構成を動的に再構築した上でイン スタンスのデシリアライズを行う様にし，復帰を可能と した。 Fig.02.5-3 データ順序の変更
３．おわりに
本 研 究 で は ， 分 散 オ ブ ジ ェ ク ト の 復 帰 に 関 す るJavaVM
上での現実的な実装手法を提案した。今年度の 開発においては，先行研究から続くAgentSphere
のコ ンセプトのうち分散性に関わる部分の開発となり，この 分散処理におけるオブジェクトの非手続転送という部分 はAgentSphere
にとっては，システムの効率性や保守 性を謳う為に必須の部分である。ネットワーク分散処理 を扱うアプリケーション外にも，クラスローダ単体で見 た場合にはオンライン取得からの動的更新自体に実用性 があり，さらにオブジェクト転送を可能にする事でクラ ス構成環境と実行途中のインスタンスオブジェクトを移 動できる。その為，分散処理の一つの形として，汎用性 と妥当性を考慮した実装ができたと考える。謝辞
本研究は科研費（基盤研究(C)21500041）の助成を受けた ものであることをここに記し，謝意を表します。参考文献
1）
