成蹊大学理工学研究報告
J. Fac. Sci. Tech., Seikei Univ.
Vol.44 No.1 (2007) pp.25-33

強マイグレーションモバイルエージェントを実現するコード変換手法
田久保

雅俊*1，櫻井康樹*1，加藤 史彬*1，甲斐 宗徳*2

A Code Transformation Method Implementing Strong Migration Mobile Agent
Masatoshi TAKUBO*1, Yasuki SAKURAI*1, Fumiaki KATOH*1, Munenori KAI*2
ABSTRACT：The authors have been developing a Java-based, strong migration mobile agent systemcalled AgentSphere. It transforms strong migration agent source codes, written by users, into weakmigration agent source codes automatically, and then executes the transformed agents on any Java Virtual
Machines. The first version of AgentSphere has a defect of its performance, because it transformed
source codes at each statement level. In this paper, a new source code transformation method is proposed
and is integrated into AgentSphere. The new version of AgentSphere can transform strong migration
source codes at each program control structure level including a migration function, and improves theperformance of processing agents by reducing much overhead.
Keywords：Mobile Agent , Strong Migration , Source Code Transformation , Autonomic Distributed
Processing System(Received March 26, 2007)
ジェントを自由に記述することは困難であった。そこ

１. はじめにで，利用してきたモバイルエージェントシステムのモビ
並列分散処理とは，ネットワーク上に接続された複数

リティを強マイグレーション化して，移動前の処理を再のマシンに処理を分けることで，並列的に処理を行い，開する記述が可能なエージェントの実現方法を提案す

さらに一台のマシンにかかる負荷を分散させることで処る。

理の高速化や耐故障性の向上ができる手法である。

２．開発目的とする自律分散処理システムの概要

しかし，分散処理システムでは，変化し続けるシステ
ム全体の状況把握や管理が必要となるため，様々な状況

2.1 自律分散処理システムとモバイルエージェントを考慮してプログラムを記述しなければならない。これには分散処理に対する高度な知識や経験が必要となる上，自律分散処理システムとは，分散処理で難しいと言わ処理対象のプログラム記述に加えて，状況を制御するプ

れているシステムの状況把握やその制御をシステムに組

ログラムの記述をしなければならず，開発に時間がかか

み込み，システムやその周囲の状況の変化に応じて，シることが多い。

ステム自身が自律的に判断，対応できるようにしたシス

そこで我々は状況の判断・制御を自律的に行ってくれ

テムのことである。これにより，分散処理アプリケーシ

る自律分散処理システムを，モバイルエージェント技術

ョンを記述したいプログラム記述者は，分散させたい計を用いて試作してきた。

算処理のみを記述するだけで済み，開発にかかる時間をしかし，試作に用いてきたモバイルエージェントシス

大幅に減らすことが可能となる。システムの自律性を満

テムは，多くの Java ベースのモバイルエージェントシ

たすためには，システム内で動く各ソフトウェアが，他

ステムと同様に，弱マイグレーションのモビリティを利からのメッセージに応じた行動と，自ら取得した外部の用しているため，移動先で移動前の処理を継続するエー

情報に応じて判断を行い，その結果によって行動を計画
し，その計画に基づき行動できる必要がある。そこで筆

*1：工学研究科情報処理専攻修士学生*2：工学研究科情報処理専攻教授(kai@st.seikei.ac.jp)

者らは，自律分散処理システムを実現するにあたって，
モバイルエージェントを利用することにしてきた。

−25−

エージェントとは，人間の代理としてシステム上で自うち，まず Mediator というエージェントを起動するこ

律的に行動するソフトウェアであり，モバイルエージェとで分散処理を行うことができる。この Mediator は

ントとは，ネットワークを通じてマシン間を移動しながGUI を使って作られていて，実行するプログラムのクラらタスク処理を行うことができるエージェントのことをスファイルやデータファイルを入力すると，分散処理を言う。そして，モバイルエージェントシステムとは，モ

開始してくれる。この時，ネットワーク上に存在する各

バイルエージェントの動作（生成，消去，移動，保存，マシンの性能値に比例するように，処理量を分散するよ

複製，通信など）を提供するシステムのことである。既

うになっているため，ユーザはどのマシンにどのくらい存のモバイルエージェントシステムとしては，の処理を請け負わせるかを考えないですむ。また，処理AgentSpace（佐藤一郎氏）[1]や Aglets（日本 IBM 社）が終わった部分解も取得し，ユーザ指定の解の形式で出[2] ，JavaGO（東京大学米澤研究室） [3] ，MOBA（首藤力してくれるようになっている。さらに，システム内を一幸氏）[4]等が挙げられる。

巡回しながら，システム全体の動的な情報を取得・更新
し，AgentSpace のダウンなどに対してエージェントの2. 2 AgentSpace を用いた自律分散処理システムの再生成などの対処を行ってくれる管理エージェント[6]や，Mediator の監視・サポートを行う MediatorSupporter[7]概要
本研究では，オープンソースであるためモバイルエー

エージェントなど，不慮の事故に対処するエージェント

ジェントシステムの動作原理の解析やシステムの改造がを導入することで，ユーザにシステムの耐故障性の面で容易で，エージェント移動時に情報を圧縮して送るため気を使う必要をなくしている。この他にも，システムの移動が速いという理由から，AgentSpace を用いて自律状態を把握しやすくするための分散管理モニタ[8]や，エ

分散処理用のプラットフォームの開発を行ってきた。こージェント間のデータのやりとりをサポートする通信用の自律分散用プラットフォームの構成の一例を図１に示

エージェント[9]なども作成し，できるだけユーザは分散す。

処理対象の計算処理部のプログラム記述だけに集中できるように努めている。
二つ目の目的である「様々な種類のプログラムを実行

AgentSpace
HUB

可能な汎用性の高いシステム」を充たすために，SPMD
形 式 の プ ロ グ ラ ム と ， MPMD(Multiple Program
Multiple Data)形式のプログラムのどちらでも自由に記述できるようにした[5]。現在，SPMD 形式のプログラムの実行開始用のエージェントとして Mediator がある。
MPMD 形式のプログラムは，エージェント間の通信を

図１ システムの構成例

含めてユーザがすべてを詳細に記述する必要がある。そのため，各エージェント間の通信関係を簡単に把握しな

図１に示すように，システムはネットワークに接続さがら記述ができる本研究用の分散処理エディタを作成しれた複数のマシンからなる。エージェントはており，これを用いることによって SPMD，MPMD 形

AgentSpace 上にしか存在できないので，分散処理に参式どちらのプログラムも記述が比較的簡単にできるよう加するマシンでは AgentSpace を起動させておく必要が支援している。

ある。AgentSpace を起動すると，自律分散処理に参加する全マシンの性能値と IP アドレスが，マシンリスト

2. 3 強マイグレーションの必要性

として各 AgentSpace に保持される。

ネットワークに繋がれたコンピュータの性能は全て同

この自律分散処理用プラットフォームの目的は，「分散

じではなく，各コンピュータは分散処理以外の処理も行処理の手法について詳しくない人でも簡単に分散処理のっているため発揮できる性能は常に一定ではない。そこ

恩恵を受けられるシステムを構築すること」と，「様々なで本システムでは，分散処理開始時直近における各コン

種類のプログラムを実行可能な汎用性の高いシステムにピュータの性能値に合わせて自律的に各コンピュータにすること」である。

割り当てる仕事量を調整する機能を構築している。

一つ目の目的を充たすために，ユーザのサポートを行

分散処理を開始するときに Mediator によって生成さう様々なエージェントやシステムを作成した。これらのれるタスクエージェントは，SPMD 形式のプログラムと−26−

して記述されているため同じ仕事量を持っていて，このタに相当する情報が必要となる。

タスクエージェントの数が各コンピュータに割り当てらしかし，これを Java で実装するのは容易ではない。

れる仕事量に相当する。タスクエージェントを生成した

これを満たすために，Java を用いた既存の強マイグレー

Mediator は性能値の高いコンピュータにより多くのタション方 式のモバイルエージェント の MOBA で は

スクエージェントを割り当てていく。

JavaVM の変更やネイティブメソッドの追加によってロ

ただしこの割り当ては，分散処理開始時の各コンピュ

ーカル変数やプログラムカウンタを取得している。

ータの性能によるものであり，一度分散されたタスクエ

JavaGO ではソースコードを変換することで実行状態のージェントがその後の状況に応じて自由に移動できるわ

保存と復旧の機能を付加している。しかし，MOBA のけではない。例えば，分散処理中のコンピュータに分散

JavaVM を変更する手法の場合，JavaVM のバージョン

処理とは別の要因で非常に大きな負荷がかかり，タスク

アップごとに修正を行わなければならず，システム開発

エージェントの処理の完了が大幅に延期されるというよの負担が大きい。また，JavaGO では，エージェントのうな事態においてもエージェントはただ待つしかない。

移動を実現するためにランタイムシステムを拡張していそこで，そのような場合にシステムが自動的に性能の良る。そのため，拡張されたバイトコードインタプリタやいコンピュータへタスクエージェントを移動させ，大幅

特定の JIT コンパイラ上でしか動かないものになっていな処理の遅延を防ぐ機能が必要となる。

て移植性が失われるという欠点があった。

この機能実現には，エージェントが任意の時点で処理を中断して実行途中のデータを保持し，移動先のコンピ

3. 2 強マイグレーション化のための手法
本研究では，移植性や JVM のバージョンアップに対ュータ上で中断時点からの処理の再開ができることが必要となる。

するシステム開発者の負担を減らすために，JavaVM にしかし，現在利用しているモバイルエージェントシス

手を加えることなく強マイグレーション方式のモバイル

テム AgentSpace のモビリティは弱マイグレーションでエージェントシステムを実現することを目指している。

あるため移動時に持っていく実行時データでは，中断ししかも，記述上は，プログラム中に単に migrate(移動先た時点からの再開を行うには不十分である。そこで，本ホスト名);のように記述すれば，マイグレーションが可研究では，中断時点での再開が可能な実行時データを持能で，この続きから実行できるようにしたい。

って移動する強マイグレーション方式のモバイルエージ

そのための手法として，スタック領域内のローカル変数の取得・復元には後述する JPDA を用いた手法を，プェントシステムを実装することにした。

ログラムカウンタ相当の情報の取得・復元にはソースコ

３. エージェントの強マイグレーション化

ード変換手法を用いて実現した。以下に，それぞれの手法について説明する。

3. 1 強マイグレーション化に必要な情報
Java においてプログラムが使用するメモリ領域には，

3. 3 スタック領域の取得・復元

実行コード領域，スタック領域，ヒープ領域がある。

スタック領域の中身を取得するために，JPDA(Java

Java を用いてモバイルエージェントを実装する際に，Platform Debugger Architecture)を使用した。これは，サン･

予め Java に備わっているシリアライズ機能を用いるこ

マイクロシステムズ社が提供する JavaVM に標準的に実とによって，実行コードに加えてヒープ領域内の情報の装されており，Java アプリケーションのデバッグに使用保存が可能となっている。しかし，スタック領域内の情されるもので，実行中のスレッドや実行情報へのアクセ

報やプログラムカウンタを実行状態として保存する機能

スが可能となっている[10]。本研究では，この機能を用いは現状の JavaVM ではサポートされていない。

ることによって，スタック領域のデータを取得することプログラムカウンタを取得・復元できれば移動直前のにする。

位置からのプログラムの再開が可能となる。また，スタック領域内に保持されているローカル変数の値を取得・

図２は，ローカル変数を取得し，持ち出し可能にするまでのプロセスの概要を示したものである。

復元できれば，移動前の計算結果を無駄にせず，実行を再開することができるようになる。そのため強マイグレーション方式のモバイルエージェントシステムを実現するためには，スタック領域内の情報とプログラムカウン−27−

直列化して別マシンへ移動

3. 4 ソースコード変換
実行状態を完全な形で保存するためには，スタックの中身だけでなく，プログラムカウンタも必要となってくる。JPDA では，このプログラムカウンタに類似したデJVMスタック

JPDA

Value型ータを扱っており，これを取得することは可能となってヒープ領域直列化可能データ

ローカル変数群いる。しかし，この取得したプログラムカウンタを用いてプログラムを途中から実行する機能は，JPDA でもサ直列化可能データポートされていない。そこで，本研究ではソースコード
図２ ローカル変数持ち出しまでのプロセスの変換を行うことにより，同等の機能をサポートするこエージェントは，スレッド上で実行される。そこで，とにした。

JPDA を用いてエージェントが実行されているスレッド

従来のソースコード変換は，処理の一行一行をステーにアクセスし，スタック内のローカル変数の値を取得す

トメント関数に分けたステートメントコードと，そのスる。しかし，このローカル変数の値は JPDA 特有のクラテートメントフローを制御するランタイムコードの二つス(Value 型)となっているため，外部への持ち出しが許可にユーザコードを変換する方式だった。この方式では，されていない。そこで，この値をシリアライズ（直列化）

ステートメントを一行一行関数に区切る再構成を行い，可能な変数に変換し，ヒープ領域内に格納する。そうす

どの関数を移動後に実行すれば良いかを制御することで，ることで，JVM を変更することなく，Java に備わってい移動直前の処理から再開することが可能となっていた。

るシリアライズ機能のみを用いて実行コード領域・ヒー

しかし，この方式では移動直前のスタックフレームのプ領域そしてスタック領域内のローカル変数を保存して構造を復元していないためユーザ関数からのマイグレー

別マシンに送信することができるようになる。

トや，繰り返し回数の判明していない繰り返し文中のマローカル変数の復元は，移動前のローカル変数の値をイグレートなど，
変換できない制御構造があった。また，対応するローカル変数に代入することで実現する。このステートメント関数中に実行処理文は１行しか記述され代入文は後述のソースコード変換時に挿入する。

ていないが，そこで使われている変数を宣言し，移動直図３に示すのは，実行再開位置にソースコード変換時

前の値へと復元するために何行ものローカル変数復元代に挿入するローカル変数復元代入文の一例である。

入文を挿入する必要があった。このため，一行の処理を行うのにオーバヘッドが大きくなってしまうという問題

create(){int x ;
double d;・・・
migrate();//実行再開位置
x = ac.getIntegerValue(“x”);
d = ac.getDoubleValue(“d”);
・・・}点があった。
本論文では，これらの問題点を解決するために新たなソースコード変換手法を提案する。
3. 4. 1 ソースコード変換手法の概要
新しいソースコード変換手法では，プログラムコード
中に記述された移動用関数である migrate 関数の位置で実行時データを取得して移動し，到着後に移動直前の状態に復元するように変換する。これにより，ステートメ

図３ ローカル変数復元代入文

ント一行一行に対して，ローカル変数の取得・復元処理

JPDA にはスタックフレームにアクセスし，そのスタを行わないですむので，オーバヘッドを減らすことがでックフレームに直接値をセットする別の機能がサポートきる。

されている。しかし，その方法では，スタックフレーム

この新しい変換手法を実現するためにまず，エージェにアクセスするために対象となるスレッドを一定時間停ントが持って移動する情報の中に，マイグレーション直止させておかなければならず，
代入以上に時間がかかる。

後かどうかを示すフラグ MigFlag を用意した。このフラ

そのオーバヘッドをかけないために，ここでは移動前のグが true のときには移動直後であることを示し，初期値

ローカル変数の値を代入することでローカル変数の復元

は false である。

を実現している。

この MigFlag を使い，移動直後には実行再開位置までの計算処理を全てスキップするようにソースコードを変換する。こうすることで，移動前のプログラムカウンタ−28−

を保存して続きが実行できるのと同じ状態を実現するこの宣言が行われる。そしてフラグの判定では，今度はとにした。

MigFlag が true のため else 文へ入る。
この else 文の中で，変換は移動関数である migrate()が存在するスコープを

ローカル変数に移動前に取得しておいたローカル変数の中心に考える。まず，変換の前準備として，そのスコー値を代入し，MigFlag を false に戻す。

プ内で定義している宣言文をスコープの前半にまとめる

これにより，ローカル変数の復元が行え，migrate 関数

ように変換する。

直後の位置から実際の計算処理を再開することができる

こうすることでできた「宣言部・処理群・migrate 関ようになる。

数・処理群」という流れが変換対象の基本形となる。

3. 4. 2 ソースコード変換手法の詳細

図４は，この基本形をどのように変換するか，というソースコード変換の基本方式・実行再開までの流れを変換の基本方式を示したものである。

説明したが，この変換・実行再開方式を，どのような状
況，どのような制御構造をとるプログラムにおいても利

変換前

{

変換後

用可能にするためにいくつかの変換仕様を決めた。以下

{
宣言部
処理群A
migrate();
処理群Bにその仕様について説明する。

宣言部
if(MigFlag == false){
処理群A
migrate();}else{
ローカル変数復元部
MigFlag = false;
}
処理群B

}

MigFlag:移動直後か判断するフラグ(1) 複数のスコープが関係する場合
前節で説明した変換概念は，単一のスコープ中での変換であったが，これが多重スコープになっても変換の基本は変わらない。図５は多重スコープが存在するソース
コードの変換の流れを示したものである。

}

migrate 関数と，それ以前の処理群（処理群 A）を内包した条件文 if(MigFlag == false)を挿入

②

}

(c)

宣言部１
処理群 A
{
宣言部２
if(MigFlag == false){
処理群 B
migrate();}else{
ローカル変数復元
MigFlag = false;
}
処理群C
}
処理群D

する

宣言部１
if(MigFlag == false){
処理群A
}
{
宣言部２
if(MigFlag == false){
処理群B
migrate();}else{
ローカル変数復元
MigFlag = false;
}
処理群C
}
処理群D

{

{

元を行う代入文と MigFlag のリセット処理を挿入

{

}

(a)

①の if に対する else 文を作り，そこに宣言部の復変換前に，宣言文をまとめていたのは，宣言文と計算

宣 言 部１処 理 群A{
宣言部 ２
if(MigFlag == false){
処理群 B
migrate();マイグレートブロック}else{
ローカル 変 数 復 元
MigFlag = false;}
処 理 群C
}処 理 群D

宣言部 １
処理群 A
{
宣 言 部２処 理 群Bmigrate();処 理 群C}
処理群 D

具体的にどのように基本形を変換したかを以下に示す。
①{{

図４ 変換の基本方式

宣言部１
if(MigFlag == false){
処理群 A
}
{
宣言部 ２
if(MigFlag == false){
処 理 群Bmigrate();}else{
マイグレートブロック
ローカル 変 数 復 元
MigFlag = false;
}
処理群 C
}
処理群 D

}

}

}

(b)

(d)

(e)

処理文が混在していると，①の条件判断回数が増えてし
まい，実行再開までのオーバヘッドが増加する可能性が

図５ 多重スコープが関係するコードの変換あるからである。
このようにして変換が行われたソースコードが実際に(a)が変換対象となるコードの初期状態で，多重スコー

どのように動き，いかにして途中実行が実現されるかをプとなっている。まず，一番内側の，migrate 関数が存在説明する。

するスコープに着目する。すると，そのスコープは基本

まず，エージェントは生成時か到着時かを問わず常に同じ決まった関数から実行が開始される。そして，処理形となっている。これを基本方式で変換すると(b)のようになる。

に必要なローカル変数の宣言が行われる。次の，MigFlag

ここで，変換したスコープをマイグレートブロック呼を調べる条件文では，MigFlag の初期値は false であるたぶことにする。すると，(c)のように，外側のスコープはめ処理群 A が実行される。そして migrate 関数で別マシ「宣言部・処理群・マイグレートブロック・処理群」と，ンへと移動する。この時，migrate 関数の内部処理で基本形と似た形となっている。
これも基本方式に則って，

MigFlag が true に切り替わる。

(d)のように変換することができる。ただし，マイグレー

エージェントが目的のマシンへ到着すると，プログラ

トブロックの中でローカル変数の復元処理を行ってしま

ムの先頭から実行が開始される。そして，ローカル変数

ったので，外側のスコープでは復元処理を必要としない。

−29−

そのため，基本方式の①の手順のみを行えば良い。する

内の変換は可能である。

と(e)のように変換される。これにより，何重にスコープ

ここで，変換されたユーザ関数全体をマイグレーショがある構造であろうと，変換することができる。

ンブロックとおくと，ユーザ関数を呼び出しているスコ

図６のように，migrate 関数が関係していないスコープープも基本形と似た形となるので，変換することができに対しては，そのスコープそのものを処理群の一部としる。この時，ユーザ関数は必ず呼び出さなければならなてまとめることができるので，スコープごとスキップす

いため，スキップする条件文の中には含めず，変数の復るように変換を行うことができる。

元等が含まれた else 文を抜けた後に記述される。こうす

{
宣言部１
処理群A
{
宣言部２
処理群B
{
処理群E
}
migrate();
処理群C
}
処理群D

宣言部１
処理群A
{
宣言部２
if(MigFlag == false){
処理群B’
migrate();}else{
ローカル変数復元
MigFlag = false;
}
処理群C
}
処理群D

宣言部１
処理群A
{
宣言部２
処理群B
{
処理群B’
処理群E
}
migrate();
処理群C
}
処理群D

}

ることで，移動直前の JavaVM スタックの構造まで復元

{

{

}

することが可能となっている。
{

{
宣言部１
処理群A
function();
処理群B
}

}

function(){
宣言部２
処理群C
migrate();
処理群D}

図６ migrate 関数が関係していないスコープの変換
ところで，実行状態を復元している最中には，migrate関数やマイグレートブロックが含まれるスコープには無

{
宣言部１
処理群A
マイグレーションブロック
function();
処理群B

宣言部１
if(MigFlag == false){
処理群A}else{
ローカル変数の再現
MigFlag = false;}function();
処理群B}
function(){
宣言部２
if(MigFlag == false){
処理群C
migrate();}else{
ローカル変数復元
MigFlag = false;
}
処理群D
}

}

図８ ユーザ関数からマイグレートする場合の変換

条件に入る必要がある。スコープに入るかどうかは，if
文や for 文などの条件文で判断する場合が多い。
そこで，(3) プログラム中に複数の migrate 関数がある場合

この条件文に「MigFlag ==true」という条件式を追加し，ソースコード変換時に，プログラムコード中に migrate

これを元の条件文との論理和に変換した。
MigFlag が true

関数がいくつ存在するかはわかるので，その数だけの時には，復元を行うために無条件でスコープに入り，

MigFlag を用意する。現在，MigFlag は boolean 型の Vector

false の時には元の条件文の真偽でスコープに入るかがとなっている。

決まることとなる。図７は if 文や for 文に，どのように条件式が挿入されるかを示している。

そして，ソースコード変換時に，各 migrate 関数にシーケンスとなる番号を付け，その番号に対応する
MigFlag を使って処理をスキップするか判断する。

if文}
if(条件文){
宣言部
・・・

for文

ある migrate 関数から見ると，他の migrate 関数によっ}for(初期化部;MigFlag == true|| 条件文;更新部){
宣言部
・・・て挿入された条件文などは，その migrate 関数に関係のないスコープとなっている。そのため，他の migrate 関
数や挿入した条件文はすべて処理群の一部として考え変換することができる。このように，migrate 関数の変換は}if(MigFlag == true || 条件文){
宣言部
・・・

}
for(初期化部;MigFlag == true|| 条件文;更新部){
宣言部
・・・

図７ 条件文に追加する条件式

別の migrate 関数の変換に対して不干渉なので，それぞれの migrate 関数ごとに独立して，変換を行うことができる。
(4) 再帰関数からマイグレートする場合
関数中からのマイグレートは変換が可能で，移動前の(2) ユーザ関数からマイグレートする場合

スタックフレームの構造も復元が可能であると説明した。

次に，migrate 関数がユーザの作成した関数の中に存在再帰関数からのマイグレートも可能性としては考えられした場合に，どのように変換するかを説明する。図８はる。しかし，再帰関数は再帰の深さだけスタックフレー

ユーザ関数からマイグレートする場合のソースコード変ムが積まれていくので，再開時にもまったく同じスタッ換方法を示したものである。

クフレーム構造を復元する必要がある。

ユーザ関数であっても，その関数内は単一あるいは複数のスコープで構築されている。そのため，ユーザ関数

図９は，再帰関数の中からのマイグレートを可能とする変換手順を示したものである。

−30−

func(){
宣言部１
処理群A
migrate();
処理群B
func();
処理群C}

func(){
宣言部１
if(!MigFlag ||recurDepth == recurDest){

初期状態

再帰復元用の処理挿入後

func(){
宣言部１
if(!MigFlag ||recurDepth == recurDest){
if(!MigFlag){が提案してきた自律分散処理のプラットフォームを処理群A

migrate();}else{
ローカル変数の復元部
MigFlag == false;}

処理群A
migrate();

処理群B}
recurDepth++;func();
recurDepth--;}イルエージェントシステムを AgentSphereと名づけ，
我々
AgentSphere に合わせて再構築することとした。従来の自律分散処理の機能の移植をより簡単にするため，処理群B}else{
ローカル変数復元部}
recurDepth++;func();
recurDepth--;

処理群C

AgentSphere のシステムを AgentSpace と類似したシステ
ム構成にすることにした。

処理群C}

そのため，AgentSpace にも存在した以下のような機能

変換完了時を AgentSphere に追加した。

図９ 再帰関数からマイグレートする場合の変換

4. 1. 1 エージェント ID
移動する時には，その時の再帰の深さを保持しておき，

ネットワークに複数存在するエージェントを一意に識

移動先で目的の深さになるまで再帰処理をスキップしな

別するためのエージェント ID の実装を行った。
これは，がら関数呼び出しを行い，スタックフレームを復元する。

ハッシュコード，生成された時間，アドレス，生成され復元が完了したら，migrate 関数の位置から実行を再開すたマシンでのシーケンスな番号を組み合わせている。こる。
このような流れとなるように，再帰関数を変換する。

の ID はエージェントが生成された時に割り振られる。

そのために，再帰の深さをカウントし記憶しておくた

4. 1. 2 ユーザとシステム間のインタフェース機能

めの変数として recurDepth と recurDest を用意した。

ユーザがエージェントの生成，移動，消去，情報開示

変換の手順は次のようになる。

などをシステムに指示できるコマンド機能を次のように
追加した。

I.

再帰関数の直前に recurDepth++を挿入

II.

再帰関数の直後に recurDepth--を挿入(1) エージェント起動コマンド load『load ファイル名』と入力すると，指定されたファIII. 再 帰 関 数 以 前 の 処 理 を 全 て if (!MigFlag ||イルを読み込み，エージェントを生成する。
(2) エージェントの情報開示コマンド list , info

recurDepth == recurDest)でスキップ
IV. else 文中に，そのスタックでのローカル変数を復移動や削除などの指示をエージェントに出すために，元する処理を挿入

そのエージェントを特定する情報が必要となる。そのようなエージェントの情報を開示するコマンドとして次のこれらの手順を踏んで変換された結果が図９の中央の二つを用意した。

変換結果となる。あとはこのコードを変換の基本方式で『list』と入力すると，現在活動中の全てのエージェン

変換することで，変換が完了する。

トの ID(識別子)を表示させる。

変換されたコードを実行し，再帰関数に至り，再帰が『info ID』入力で自身のマシンの中から同じ ID のエ

行われると，recurDepth が再帰の深さをカウントしていージェント情報を引き出し，実行中のファイル名，エーく。そして，移動時に recurDest にその値をコピーする。

ジェントのクラス名などを出力する。

そして，recurDepth を初期値の 0 に戻し，移動後には復(3) エージェントの転送コマンド go

元のために recurDepth のカウントを行う。

『go

ID 送り先の IP アドレス』

recurDepth＜recurDest の時には，スタックフレームのエージェントの ID でエージェントを指定し，送信先復元が済んでいないとみなし，再帰関数以前の処理を全のマシンの IP アドレスを指定することでエージェントてスキップする。

の送信を行えるようにした。

このように再帰関数からのマイグレートも実現できる(4) その他のコマンドが，実行効率上は，スタックフレームの復元が大きなオー『destroy ID』と入力することにより，指定したエー

バヘッドとなるので，利用することはあまり推奨できない。

ジェントを削除する。
『help』により，以上のコマンド一覧が出力される。

４．強マイグレーション方式のモバイルエージェ

4. 1. 3 複数のエージェントを生成・管理する機能

ントシステム AgentSphere

本研究の目指す自律分散処理システムでは，一つのAgentSphere に複数のエージェントが存在することが必

4. 1 AgentSphere の機能拡張
３章で説明した手法を用いた強マイグレーションモバ

要である。そこで，AgentSphere 内に存在する複数のエー
ジェントの情報をリストとして管理する機能を作成し，−31−

複数のエージェントが同時に存在することが可能となる動作が行われているかを確認した。図 10 には，動作確認

ようにシステムを拡張した。

に用いた migrate 関数記述後のソースコードの一例を，

4. 1. 4 エージェントとシステム間のインタフェース機能

そして図 11 にはソースコード変換後のコードを示す。

エージェントが AgentSphere にアクションを行おうとこのコードは，ソートを行う配列のデータの中で一番する時には，システム内の対応するクラスやデータに直小さい値が確定したら次のマシンに移動し，次に小さい

接アクセスしている。一方，ユーザが記述するような分値を確定し，最初のマシンに戻って処理を行うというよ

散処理用のエージェントプログラムにおいても，エージ

うな処理を行っている。そして，移動前のマシンでの配ェントからシステム側へのアクションを記述することが列の状態が保存されているかの確認を行っている。

考えられる。

表１は，今回評価に使用したマシンである。マシン A

しかし，それを記述するためには，対応するクラスやの１台で処理を行った結果を図 12 に示す。次に，２台のデータについて詳しく知っている必要があり，本研究のマシンで処理を行った時のマシン A での結果を図 13−

目的とする「分散処理の手法について詳しくない人でも１に，マシン B での結果を図 13−２に示す。

簡単に分散処理の恩恵を受けられるシステムを構築する

図を見て分かるとおり，移動前の配列の状態を保持しこと」に相反することとなる。さらに，エージェントプながら移動し，移動後ではその続きから処理を行っていログラムから，AgentSphere のシステム全てにアクセスでるのがわかる。

きるようでは，セキュリティ上非常に危険である。

public class BubbleSort extends StrongMigAgent
implements Serializable{
private String IPaddress;
private AgentInfo Ainfo;
public void create() {/** 確認用のソート対象データ*/
int[] array = { 117, 75, 24, 32, 98,72, 88, 43, 60,
35};

そこで，エージェントとシステム間のインタフェースとなるクラスを設けた。ユーザが記述するエージェントプログラムでは，このクラスを利用するだけでシステムへのアクションをとることができると同時に，このクラスで許可されている事以上のアクションをシステムに行

if(Ainfo.MigFlag == 0){
print(array);
System.out.println("Sort Start!!");}else{//ローカル変数復元部
array = this.getArrayIntegerValue("array",0);}sort( array );うことができないようにした。
4. 2 AgentSphere の動作確認
今回このシステムの動作確認をするに当たって，デー
タ数 10 個のバブルソート(昇順)を２台のマシン間で行う//ソートの結果の確認
System.out.println("SortFinished!!");
print(array);}

ことにした。あらゆる制御構造にも対応していることを確認するため，ソースコード中の色々なスコープ内に
migrate 関数を記述し，それぞれの場合においても正しく

public void sort( int[] array ) {int tmp=0; //作業領域
for( int i=0;Ainfo.MigFlag!=0 || i<array.length-1;i++ ) {
if(Ainfo.MigFlag == 0){
for( int j=0;j<array.length-i-1; j++ ) {if(array[j] > array[j+1] ) {tmp = array[j];array[j] = array[j+1];
array[j+1] = tmp;}}
if(i%2 == 0) IPaddress = "133.220.114.108;
else IPaddress = "133.220.114.240";
System.out.print(i + " : ");print(array);migrate(IPaddress,1);}else{//ローカル変数復元部
array =
this.getArrayIntegerValue("array",0);tmp = this.getIntegerValue("tmp",0);i = this.getIntegerValue("i",0);Ainfo.MigFlag = 0;}}}

import java.io.Serializable;
import agentsphere.*;public class BubbleSort extends StrongMigAgent implements Serializable {public void create() {int data[] = ソートを行うデータ;
sort(data);}
void sort(int[] data){
int i, j, temp;
for ( i = 0; i < data.length - 1; i++ ) {for ( j = data.length - 1; j > i; j-- ) {if ( data[j - 1] > data[j] ) {temp = data[j - 1];
data[j - 1] = data[j];data[j] = temp;}}
print( data ); /*配列表示用の関数*/
if (i%2==0) migrate(“IPAddress2”);else migrate(“IPAdress1”)}}}

図 10 動作確認に用いたソースコードの一例
表１ 動作確認に使用したマシン一覧
マシン名
CPU名
クロック数
マシンA Core 2 Duo
2.2GHz
マシンB PentiumD
2.8GHz

メモリ
2.0GB
1.0GB

図 11 ソースコード変換後のコード

−32−

参考文献
[1] 佐藤一郎：「AgentSpace：モバイルエージェントシ
ステム」,日本ソフトウェア科学会, Dec.1998[2] 日本 IBM 東京基礎研究所：

http://www.trl.ibm.com/aglets/ , Jul.2006 参照可[3] 米澤明憲,関口龍郎,橋本政朋：「移動コード技術に基づくモバイルソフトウェア」

http://homepage.mac.com/t.sekiguchi/javago/index-j.html, Jul.2006 参照可[4] 首藤一幸 :図 12 一台のマシン（マシン A）での実行画面

http://www.shudo.net/moba/ ,Jul.2006

参照可[5] Ryusuke Sasaki, et al.: “Implementation And

Evaluation Autonomic Distributed Processing
System Using Mobile Agent”, Proc.of IEEE Pacific
Rim conference, No.237, Aug.2005[6] 坂井功, 相河寛典：「モバイルエージェントを用いた
自律分散処理システムの構築−自律分散処理をサポートする管理エージェントの作成−」2003 年度電気学会電子・情報・システム部門大会講演論文集,

pp.1142-1146,Aug.2003[7] 佐々木竜介, 遠藤
図 13−１マシン A航, 青山迅, 清水敏宏, 小川大介, 坂井 功：
「モバイルエージェントを用いた自律図 13−２マシン B

分散処理システムの構築−自律分散処理システムに

５．終わりにおける性能とユーザビリティの向上−」2004 年度電気学会電子・情報・システム部門大会講演論文集,

スタック領域の取得，ソースコード変換を行うことにpp.1036-1040, Sep.2004

よって，既存の JavaVM に変更を加えることなく，強マ[8] 小川大介, 佐治大介, 村本洋明：「モバイルエージェ

イグレーションエージェントの記述ができるようになっントを用いた自律分散処理システムの構築−タスク

た。

エージェントの記述法とタスク分散の効率化−」

また，新しいソースコード変換方式にすることで，プ

2003 年度電気学会電子・情報・システム部門大会講

ログラムの制御構造に依存したソースコード変換しか行えなかった従来のシステムを，制御構造に依存せずに

演論文集, pp.1116-1120,Aug.2003[9] 田久保雅俊, 佐々木竜介, 内藤智史, 小川大介：「モバ

migrate 関数を記述することができるようになった。

イルエージェントを用いた自律分散処理システムの本研究では，ユーザがエージェントに記述する強マイ構築 −エージェント間通信命令の実装と分散処理

グレーションコードを弱マイグレーションコードにソー

エディタの試作−」2005 年度電気学会 電子・情報・

スコード変換する仕様を定めた。しかし，ソースコード

シ ス テ ム 部 門 大 会 講 演 論 文 集 , GS15-4,

変換を自動で行えるソースコード変換機はまだ作成してpp.1034-1039, Sep.2005

いない。今後の課題としては，本年度決定したソースコ[10] Torsten Illmann,et.al, “Transparent Migration ofード変換仕様に基づいて，ソースコードを自動で変換す

Mobile Agents Using the Java Platform Debugger

る自動変換機の作成，移動オーバヘッドに関する評価をArchitecture”, Mobile Agents: Proceedings of the行い，ソースコード変換仕様・ローカル変数取得復元機

5th International Conference, Ma 2001 Atlanta, Ga,

能を改善し性能の向上を目指すこと，取得・復元できる

December 2-4, pp.198- 212, 2001

ローカル変数の種類を拡張することなどが挙げられる。

−33−