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

自律分散処理用モバイルエージェントシステム AgentSphere の開発
坂井功＊1，甲斐 宗徳＊2

AgentSphere: A Mobile Agent System for Autonomous Distributed Processing
Isao SAKAI＊1, Munenori KAI＊2,
ABSTRACT：In the design of a mobile agent, it changes a lot by whether about an agent, which of threekinds of mobility, Code Migration, Weak Migration, and Strong Migration, is adopted and implemented.
AgentSphere developed by our research is a mobile agent system based on the Strong Migration mobility.
Therefore, on the machine by which AgentSphere is running, a mobile agent can move to other machineseven from anywhere in a program code, and can resume processing. Although conventional developed
systems has realized Strong Migration by changing the JavaVM itself uniquely, our system has thefeature that, unlike such past systems, distributed processing program can be executed on the existing
JavaVM by using source code conversion. By using AgentSphere, improvement in both throughput andreliability are offered by low cost, and it becomes possible to build the autonomic distributed processing
system in which users without technical knowledge could also perform stabilized distributed processing
easilyKeywords：Mobile agent, Agent systems, Strong Migration, Distributed processing system(Received March 25, 2005)

１．はじめに識が必要となってくる。
そこで，本研究では，モバイルエージェントを用いて，近年，コンピュータネットワークの規模の拡大，情報処理能力・信頼性の向上を低コストで提供し，操作や，通信機器の急激な進化に伴い，ネットワーク利用者は急コーディングが簡単で，専門知識の無いユーザでも，手速に増大している。それに比例するかのように，ネット軽に分散処理を行えるような環境を提供し，安定した処ワークの利用方法も高度化して，様々な情報検索の要求理を実現することを目的としている。と応答や多様なマルチメディアデータがネットワーク上

ここでは，本研究での自律分散処理の特徴をさらに強において流通し始めている。このため，ネットワークを化させるため，昨年度まで利用していた AgentSpace（お介した情報処理の中核となるサーバマシンでは，膨大な茶の水女子大学，佐藤一郎氏の開発したモバイルエージ

計算を高速に処理するため，さらなる性能要求が高まっェントシステム）から，独自のモバイルエージェントシている。

ステム（AgentSphere）を導入することによって実現させその解決方法の１つとして，ネットワーク上に接続さることを目的としている。

れた複数のマシンに行うべき処理を分散させ，演算結果２．従来のシステムの概要を統合するという方式を取ることで，全体のスピードを向上させることを実現する分散処理が挙げられる。しか2. 1

し，分散処理の利用には，分散処理を行う環境を整えることや，分散処理のためのプログラミングなどの専門知

エージェントのモビリティについて

モバイルエージェントは，ユーザプログラム自体を遠隔ノードに送って実行する遠隔プログラミングという概＊1

情報処理専攻大学院生＊2
情報処理専攻助教授(kai@st.seikei.ac.jp)
Associate Professor, Dept. of Information Sciences

念を実現している。その設計において，プログラムの記述性に関係するものは，モバイルエージェントシステム−33−

がどのようなモビリティを採用しているかに依存する。

保存し，移動先で移動前の処理を再開できるようなソーモビリティとは，プログラムが移動することはどういうスコードに変換して処理を行う形となっている。しかし，ことなのかという意味づけである。プログラムのモビリ

次の 3 つの制限の元にユーザはプログラムを記述しなけ

ティの分類として大きく分けて次の 3 つが考えられる[1]。

ればならない。

１．遠隔実行（Code Migration）

１．複数のクラスで構成されたシステムは利用不可能

プログラムコードのみの移動

２．移動を行うかもしれないメソッドにはあらかじめ

２．弱いマイグレーション（Weak Migration）宣言しなければならないものがある

プログラムの他に実行途中のデータを伴った移動

３．for 文の初期化部，条件部，繰り返し部の中では

３．強いマイグレーション（Strong Migration）

移動することができない

プログラムコードとデータに加えて，プログラムさらに，エージェント実行前にソースコード変換をするの実行状態を伴った移動だけでなく，移動するたびにソースコード変換を行う必遠隔実行は，JavaApplet のようなプログラムの実行が要があると言った問題点もある。

ノード内で完結するようなもので，プログラムを遠隔ノ

モバイルエージェントシステムの構築にあたって，遠ードに送って実行が開始できればよい。

隔実行，弱いマイグレーション，強いマイグレーション

本システムで利用している AgentSpace[2]や Aglet[3]等の中の，どのモビリティを採用するかどうか決めなけれの Java ベースのモバイルエージェントシステムは，弱いばならない。

マイグレーションを採用している。それは，Java に予め2. 2備わっている機能（ヒープ領域内のデータの直列化）で強いマイグレーションの必要性容易に実現可能だからである。プログラムの記述法は，本システムでは，弱いマイグレーションベースのモバエージェントの状態（生成，送信，受信，消滅，複製，イルエージェントシステム AgentSpace を採用している。

保存）に応じて，コールバックするメソッドが決まってそのため，エージェント移動後の処理や，バックアップおり，そのメソッド内にプログラムを記述する(図 1)。

ファイルを復元したときの処理は常に同じ場所から実行

create(){ョンベースで設計するとなると，移動後の処理や，バッLocal で処理
migrate(Host A)；

Local･･･で処理}

クアップファイルを復元したときの処理をあらかじめ記述する必要があるため，エージェントを設計するユーザ

HostA で処理migrate(Host B)；arrive(){移動先で処理･･･}される(図 1)。つまり，これらの機能を弱いマイグレーシ

run(){の負担が掛かる。しかし，強いマイグレーションベースのモバイルエージェントなら，ユーザはこれらのことをHostB で処理気にすることなくエージェントを設計することができる}

ため，エージェント開発コストを削減することができる。
図 1 弱マイグレーション

図２ 強マイグレーション

この節では，本システムの概要と，強いマイグレーシ

強いマイグレーションを採用したモバイルエージェンョンベースのモバイルエージェントシステム

トシステムでは，弱いマイグレーションのようなエージ（AgentSphare）を採用すると，どのような影響があるの

ェントの状態に応じた処理を考慮せずに，プログラムをかを述べる。

記述することができる(図 2)。昨今のエージェントブーム

2. 2. 1

タスク分散用エージェント（Mediator）のきっかけとなった Telescript[1]は，これを採用したモバMediator[6]とは，AgentSpace 上で稼動するエージェンイルエージェントシステムであるが，インタプリタで実トベースのアプリケーションである。Mediator は，ユー行される Telescript 言語でプログラムを記述しなければザからのタスク指定などの入力を受ける。Mediator を起ならない。Java 言語ベースのモバイルエージェントシス

動すると，使用可能なマシンの表示や処理結果が出力さテムでは，MOBA[4]や JavaGO[5]が挙げられる。MOBAれる GUI が表示される（図 3）。

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

その GUI からユーザがタスクを指定し，実行を開始すて，プログラムカウンタやスタック領域内の情報を移動ることによって，ネットワーク上の AgentSpace が稼動しすることで実現している。しかし，JIT コンパイラを利ているマシンに，性能値を基にして，タスクエージェン用することができず，独自の JavaVM をダウンロードすト（Distributed Agent）を分散させる。そして，各マシンる必要がある。JavaGO では移動時にローカル変数を全てで処理を終了したタスクエージェントは，再び，分散を−34−

３．AgentSphere システムAgentSphere は以下の 4 つの特徴を持つモバイルエー
ジェントシステムである。
１．強いマイグレーションを採用
２．既存の JavaVM で実行可能
３．ソースコード変換
４．コード中のどこからでも移動可能
3. 1

ソースコード変換

強いマイグレーションコードを，Java で提供している
図３

Mediator の稼動機能だけで実現させるために，ソースコード変換を使用した。ユーザコードはこのソースコード変換器によって行った Mediator の存在するマシンの AgentSpace に戻り，ステートメントコード，状態データ，ランタイムコード

Mediator によって，これらの処理結果（解）が統合され，を取得する（図 4）。

最終的な解が Mediator のウインドウに出力される。
このようにタスクの分散処理を行うが，AgentSpace ベースのタスクエージェントは，自身の処理を終了するまで，そのマシンに滞留しなければならない。つまり，実行を開始したタスクエージェントは，外部アプリケーシ
ョンや他のタスクエージェントによって処理速度が著しく低下した場合や，分散処理に参加したマシンが増減する場合など，状況に応じた動的な移動はできない。強い
マイグレーションベースのモバイルエージェントシステ

図４

ソースコード変換

ムならば，タスクエージェントの実行を開始した場合でも，実行状態を保持した移動ができるため，環境の変化

ステートメントコードはユーザコードの文の構造を見に応じたエージェントの移動が実現する。

返して，分割したステートメントを statementN（N＝整2. 2. 2数）というメソッドに，for の内部のステートメントや if

管理エージェント

管理エージェント[7]は他の AgentSpace の情報（使用可の内部（条件部）のステートメントは branchStatementN

能なマシンの IP アドレス，マシンの性能値，滞在するタというメソッドに書き込んだものである（図 5）。その際，スクエージェントの ID）を受け取り，タスク分散可能なユーザコードに提供されるプリミティブは次の 5 つであマシンや，Mediator のタスク負荷分散処理，ダウンしたる。

タスクエージェントの発見を行う。管理エージェントが１．エージェントの移動:migrate(address)

ダウンしたタスクエージェントを発見したとき，それを２．エージェントの保存:backup()Mediator に伝え，Mediator がそのタスクエージェントを３．エージェントの生成:create(fileName)再発行する形となる。しかし，AgentSpace ベースのタス

４．エージェントの複製:duplicate()

クエージェントでは，始めから処理を行わなければなら５．エージェントの消去:destroy()ない。強いマイグレーションベースのタスクエージェン

状態データは，AgentInfo クラスを直列化・圧縮したもトならば，自身を定期的にバックアップし，それを管理ので，AgentInfo には，ロードするクラス名やそのオブジエージェントに持たせることで，ダウンしたタスクエー

ェクト，生成したステートメントコードを元に，実行をジェントを発見した場合，管理エージェント自身からタ開始するステートメント，実行するステートメント，実スクエージェントの再生が可能となる。また，再生され行する分岐ステートメント，次に実行するステートメン

たタスクエージェントは，バックアップした場所から処ト，分岐先のステートメント等の情報を格納する。

理を再開することができる。

ランタイムコードは AgentInfo からステートメントの情報を受け取り，ステートメントを実行させたり，次に−35−¨

受信したデータの解凍

AgentWriter¨

エージェントを直列化しファイルに保存する

AgentSphere を起動することによって，そのマシン上でエージェントが存在することができる。ユーザに提供するプリミティブを元にしたエージェントの状態は，図 6 で表現される。

図５ ユーザコードとステートメントコード
実行するステートメントを決定して AgentInfo に渡したり，エージェントの動作（移動，保存，生成，複製，消去）を管理するコードである。
生成されたコードは既存の Java コンパイラにより，クラスファイルを取得できる。この 2 つのクラスファイルと状態データを合わせたものがモバイルエージェントに

図６ エージェントの状態遷移図なる。
3. 2. 1
3. 2

AgentSphere

エージェントの生成

AgentSphere がユーザから状態データを受け取ったとモバイルエージェント（ステートメントクラス・ラン

き に ， AgentManager は ス レ ッ ド を 継 承 す る ク ラ ス

タイムクラス，状態データ）を動作させるアプリケーシ

AgentRuntime を生成し，状態データの解凍・復元を行う。

ョンである。これは以下のクラスで構成されている。

そして，状態データから生成するクラスファイル名を受け取り，Java クラスローダを使用してエージェントを実AgentServer¨

AgentSphere の起動行するクラス（ランタイムクラス）を生成する。そして，ランタイムクラスをインスタンス化してランタイムオブ

AgentManager¨

全てのクラスを管理ジェクトを取得し，コールバックしてランタイムを実行¨

エージェントの要求に応じたシステムへの呼びする。

出しを実行

3. 2. 2¨エージェントを実行するためのスレッドを継承実行するステートメントを受け取り，ステートメントクするクラスラスの対応するメソッドを呼び出すことによって実行する。そして，分岐したときや分岐しないとき，関数が終AgentLoader¨

ユーザからのファイル入力待ちをするクラス了したときなどの条件を元に次に実行するステートメントを決定し，そのステートメントを AgentInfo に格納す

AgentReader¨

直列化データの復元するためのクラスる。
3. 2. 3AgentClassLoader¨

AgentInfo クラスからロードするクラス名を取実行するステートメントが migrate メソッドや backup
メソッドを呼び出したとき，ランタイムオブジェクトは，ステートメントオブジェクトと自身のオブジェクトをエージェントの直列化・圧縮を行い，送信する

AgentInfo に格納し，AgentSphere がその AgentInfo を直列化し，zip 形式で圧縮を行う。そして，指定されたアドレ

AgentReceiver¨

エージェントの送信・保存得し，クラスファイルのロードを行うクラス
AgentSender¨

エージェントの実行生成されたランタイムオブジェクトは，AgentInfo からAgentRuntime

エージェントの受信待ちをするスへ移動，もしくは，ディスクに保存する。

−36−

3. 2. 4

エージェントの受信・復元用して処理を行った。図 7 のシステムの要求プリミティ

状態データをネットワーク・ファイルから受信したとrun(){き，エージェントの生成と同様に，AgentManager はスレ

n = 0.0;

ッドを継承するクラス AgentRuntime を生成し，状態デー

for(i=0;i<N;i++){タの解凍・復元を行う。そして AgentInfo からランタイn++;

ムオブジェクトを取得し，ランタイムオブジェクトの実

System.out.println(n);行メソッドをコールバックする。AgentInfo は送信・保存システムの要求プリミティブする命令を実行した後のステートメント位置を格納して}いるため，それをランタイムオブジェクトは取得し，対System.out.println(“Answer= “+n);応するステートメントオブジェクトのメソッドを呼び出すことによって，移動・保存前の処理の続きを実行する

図7

動作確認のためのコード

図８

エージェントの生成:N=1ことができる。

４．評
4. 1

価

ソースコード変換

1000 万回代入式と四則演算を繰り返すコードをそれぞれ逐次実行したときの処理時間と，2 つのコードをそれぞれ変換し AgentSphere 上で実行したときの処理時間を計測した（表 1）
。
表1
変換前

処理性能
変換後

オーバーヘッド

代入式

214msec

553msec

339msec

四則演算438msec

763msec

325msec

上記の 2 つは，共に 1000 万回繰り返して処理をしている。つまり，AgentSphere 上では，1 つのステートメント

ブには，エージェントの生成:create(fileName)，エージェを 1000 万回実行していることになり，ステートメントをントの保存:backup()，エージェントの消去:destroy()，エ

1 回実行するのに，次に実行するステートメントを決め，ージェントの移動:migrate(address)，エージェントの複

その情報を AgentInfo に格納するためのオーバーヘッド

製:duplicate()がある。for 文の条件式部分 N は，繰り返しが生じる。この処理を AgentSphere 上で実行したときの回数であり，動作確認をするものに応じて変化させた。

オーバーヘッドは，二つの処理を平均して 331msec（1

図 8 は実行中のエージェント（test1.agent）から新しく回あたりでは 33.1nsec）生じることを表している。しかエージェント（test2.agent）を生成する動作を表している。

し，繰り返し文の中をステートメントに分割するという

図 8 の赤線を見ればわかるように test2.agent を test1.agent

ことは，その中でエージェントを移動・保存するメソッ実行時に生成することが確認できた。

ドがあるということを表している。通常，代入命令だけ

図 9 はエージェントを保存する動作を表していて，変して 1000 万回移動したり，バックアップを取るようなプ

数 n のインクリメントが実行・出力されるたびに，そのログラムの設計はしない。実際はステートメントの処理実行状態とデータをディスクに保存している。そのファ量を大きくし，間隔を持ったエージェントの移動や保存

イ ル 名 は ，「 エ ー ジ ェ ン ト 名 @BAK@ エ ー ジ ェ ン トを行うようにするのが普通である。

ID.agent」という形式でディスクに保存される。ここでは，また，変換前のコードと変換後のコードの容量を比較

ディスクに保存するファイル名は test@BAK@0.agent（エすると 2.5 倍あった。

ージェントの ID は定義されていないのでここでは 0）となっている。実行状態が保存されているか確認するため，

4. 2モバイルエージェントの動作確認

test@BAK@0.agent を入力したところ，test.agent が最後モバイルエージェントの動作（生成・保存・消去・移に保存した箇所からの処理を再開することが確認でき動・複製）を確認するために，図 7 のソースコードを利た。また，エージェントの保存 1 回のオーバーヘッドは−37−

2.21msec 生じることがわかった。

図 12 エージェントの複製:N=1

図 10 はエージェントを消去する動作を表していて，変数 n を 5 回インクリメントし出力するプログラムである
図9

エージェントの保存:N=5が，途中で処理を終了するプリミティブ（destroy()）を挿入したため，処理が中断してしまった状態を表している。
図 11 は，変数 n をインクリメントし，出力されるたびに，実行状態保持して，ローカルホスト自身への移動を繰り返した様子を表している。
図 12 はエージェントの複製を表していて，変数 n を 1回インクリメントしたときの値と，その実行状態が複製され，実行しているエージェントの処理結果と，複製されたエージェントの処理結果の出力を確認することがで

図 10

きた。

エージェントの消去:N=54. 3

他のエージェントシステムとの比較

昨年度まで使用されていたモバイルエージェントシス
テム AgentSpace と AgentSphere を使用して，エージェントがリモートマシンに移動してから，ローカルマシンに戻るまでのオーバーヘッドを計測した。これを実行するためにユーザが記述するコードは AgentSphere では図13，AgentSpace では図 14 である。
モバイルエージェントシステムにおけるコードの記述性（図 13，図 14）を比較すると，明らかに AgentSphereでコードを記述するほうが簡単に実装できる。このコードを 10 回実行したとき，AgentSpace では，平均 187msec掛かるのに対し，AgentSphere では平均 168msec で実行することができた。つまり，1 回の送受信におけるオーバーヘッドは，AgentSpace は 93.5msec，AgentSphere は84msec である。また，AgentSphere の変換されたソースコードに対するクラスファイルのサイズ（通信量）は

図 11 エージェントの移動:N=5AgentSpace で記述したソースコードに対するクラスファ−38−

態を保持した移動やバックアップ機能をユーザに低コスrun(){トで提供することができた。それ以外にも，エージェン

stime = System.currentTimeMillis();トの基本機能である，エージェントの生成，消去，複製migrate(remoteAddress);等の動作も確認することができた。しかし，本研究でのmigrate(localAddress);

自律分散処理システムには，まだ対応できる段階にはな

ftime = System.currentTimeMillis();っていない。そこで，対応することが可能なモバイルエ

System.out.println(ftime - stime);ージェントシステムにするためには，エージェント間の}通信や，エージェントの ID を決定する機能を実装する
図 13 AgentSphere で記述するコード必要がある。また，エージェントがファイルやウインドウを使いたいときは，送信時やバックアップ時におけるファイル・ウィンドウの計算リソースの解放，受信時やcreate(){stime = System.currentTimeMillis();バックアップファイルを実行させる時は，ファイル・ウdispatch(remoteAddress);

ィンドウの計算リソースの獲得を行えるようなコード変}換が必要となる。本研究の自律分散処理システムにarrive(){AgentSphere を導入することによって，マシンの性能値の急激な変化や分散処理に参加しているマシンの増減に伴

if(remote){ったタスクエージェントの再負荷分散や，管理エージェ

dispatch(localAddress);}

ントがタスクエージェントのダウンを認識したとき，実if(local){行状態を保持したタスクエージェントの再生が実現することができるようになる。

ftime = System.currentTimeMillis();System.out.println(ftime - stime);

参考文献

}
}

［１］
図 14 AgentSpace で記述するコード

服部文夫，坂間保雄，森原一郎「わかりやすいエージェント通信」オーム社出版［２］
イルのサイズ（通信量）の 2 倍ほど多くなってしまうが，こ の コ ー ド を 実 行 す る に あ た っ て ， AgentSphere は

1998

佐藤一郎「AgentSpace：モバイルエージェントシステム」日本ソフトウェア科学会 1998-12［３］

AgentSpace よりも 9.5msec 早くなる。しかし，このIBM Tokyo Research Laboratory
http://www.trl.ibm.com/aglets/index.htm［４］AgentSpace は，自律分散処理を行うための処理や，エー

首藤一幸，村岡洋一「Java 言語環境におけるスジェント情報（エージェント識別子等）の登録，エージレッド移送手法と移動エージェントへの応用」

ェント間通信の準備等のオーバーヘッドがあり，情報処理学会 研究報告 pp.39-46［５］

AgentSphere には，現段階では，それらの機能は実装され米澤明憲 関口龍郎 橋本政朋「移動コード技術ていない。そのため，AgentSpace よりも高速な移動を実に基づくモバイルソフトウェア」

現できたと考えるわけではない。しかし，AgentSpace はhttp://web.yl.is.s.u-tokyo.ac.jp/amo/JavaGo/doc/［６］

弱いマイグレーションベースのモバイルエージェントシ

小川大介

他「モバイルエージェントを用いたステムに対し，AgentSphere は強いマイグレーションベー

自律分散処理システムの構築−タスクエージスのモバイルエージェントシステムであるため，実行状

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

態を保持した移動やバックアップ機能をユーザに低コス

年度電気学会電子・情報・システム部門大会公演論文集 pp.1116-1120,2003-8

トで提供することができるという利点はあると考える。
［７］

５．おわりに

坂井功

他「モバイルエージェントを用いた自律分散処理システムの構築−自律分散処理をサポートする管理エージェントの作成−」2003
年度電気学会電子・情報・システム部門大会公

強いマイグレーションベースのモバイルエージェント

演論文集 pp.1142-1146,2003-8

システム AgentSphere を構築したことによって，実行状−39−