オブジェクト共有空間を利用した分散プログラミング支援フレームワーク

オブジェクト共有空間を利用した
分散プログラミング支援フレームワーク
SOR
A Distributed Programming Framework using Shared Object Space: SOR
前田直人
上田和紀
Naoto MAEDA Kazunori UEDA
早稲田大学大学院理工学研究科情報科学専攻
Graduate School of Information and Computer Science, Waseda University
e-mail: fmaeda,uedag@ueda.info.waseda.ac.jp
概要
オブジェクト共有空間という抽象化を利用した、Java 言語環境による分散プログラミング支援フ
レームワーク SOR を提案する。オブジェクト共有空間は、格納されるデータの単位がオブジェ
クトであり、格納されたオブジェクトの内部状態はメソッド呼び出しによって変更、通知される、
オブジェクト指向に基づいたモデルである。オブジェクト共有空間の実装を利用することで、異
なる JVM 間での仮想的なオブジェクトの共有や、オブジェクトの永続化が可能となり、分散シ
ステムの記述を容易にする。また、その実装において proxy による通信の隠蔽や、共有オブジェ
クトの物理的な位置の隠蔽、移動や複製による通信効率の向上や、耐故障性の付加が可能である。
1 はじめに
異なるホスト上のプロセスが協調して特定の処理を
ワーク SOR
(Shared Object Repository) を提案する。
SOR はオブジェクト共有空間を実装するための枠組み
と、その枠組みに沿って実装されたオブジェクト共有
行うような分散システムの記述は従来の集中型のシス
空間をユーザに提供するための
テムの記述と比較して非常に困難である。分散環境上
される。
SOR システムで構成
で動作するシステムは、セキュリティ、耐故障性、相
オブジェクト共有空間とは扱うデータの単位がオブ
互運用性、通信効率等を考慮して設計、実装する必要
ジェクトであり、次の機能を持っている抽象的なモデ
がある。近年登場した Java 言語環境はプラットフォー
ム非依存であり、動的なクラスローディング、堅牢な
セキュリティ構造等の分散環境に適した機能や性質を
提供する。そのため、Java を利用した分散システムの
研究は数多く行われている。
分散システムの多くは情報の共有がその主な目的の
一つであり、仮想的にオブジェクトの共有を行うことで
分散システムの記述を支援することが考えられる。既に
JavaSpaces という共有空間に基づいた分散プログラミ
ング支援システムが公開されているが、JavaSpaces [4]
はオブジェクトの流れに基づいた分散プログラミング
モデルに従う必要があり自由度が少ない。
本稿では、オブジェクト共有空間というモデルを利
用した、Java による分散プログラミング支援フレーム
ルである。
オブジェクトの格納
オブジェクトの削除
オブジェクトのメソッドの呼び出し
格納されたオブジェクトは、メソッド呼び出しを通じ
て、内部状態を変更し、返り値によって内部状態を通
知する。
SOR はオブジェクト共有空間を利用することで、異
なる JVM 間での仮想的なオブジェクトの共有と、格
納されたオブジェクトの永続化を提供し、異なる場所
で複数の人間が同じデータを利用して作業するような、
CSCW における同期分散型や非同期分散型の分散シス
テムの記述の支援を目標としている。また、格納され
たオブジェクトの物理的な配置、並列アクセスや移動
SharedSpace for CSCW
による通信効率の向上、複製や二次記憶への保存によ
SharedSpace for agents
る耐故障性の付加等をオブジェクト共有空間の実装で
対応することにより、分散特有の諸問題をオブジェク
Sharable Object
ト共有空間内に隠蔽することが可能である。
本稿では、まず
SOR の方針及び構造と、Java によ
SOR
るオブジェクト共有空間を実装するための枠組みにつ
いて述べ、さらにその枠組みに基づいて実装したオブ
JVM
ジェクト共有空間を紹介する。
図
2
SOR
2.1
2.3
方針
オブジェクト共有空間の実装は様々な手法が考えら
れ、対象とする分野の分散システムの性質やそれが動
1: SOR システム概念図
オブジェクト共有空間の枠組み
SOR はオブジェクト共有空間を実装するためにクラ
スやインタフェースを提供する。この節では枠組みに
ついて述べる。
作する環境によって、効率の良い実装手法は異なる。
例えば、オブジェクトの配置として移動や複製を行う
かどうか、またオブジェクトの永続化は行うかどうか
等で分類することができる。従って、SOR は Java に
よるオブジェクト共有空間実装のための枠組みを規定
し、その枠組みに沿って実装されたものは、ユーザの
プログラムに変更を与えないか、若干の変更で済むよ
うに設計する。次に対象とする分野を明確にし、オブ
2.3.1
共有オブジェクト
共有空間に格納可能なオブジェクトを共有オブジェ
クトと呼ぶ。共有オブジェクトは Java のオブジェクト
であり、外部からの遠隔メソッド呼び出しを受け付け
る。内部状態として primitive と、他のオブジェクトへ
の参照を保持する。共有オブジェクトとそのインスタ
ジェクト共有空間の実装を行い、再利用が可能と思わ
ンス変数によって参照されるオブジェクトで、一つの
れるオブジェクトは
グループが形成され、格納時にはそのグループ全体の
SOR のクラスライブラリとして
作成する。ユーザはオブジェクト共有空間の中から実
装する分散システムに適したものを選択して利用し、
もし必要であれば、オブジェクト共有空間を独自に実
装する。
コピーが共有空間の実装に渡される。
共有オブジェクトは格納される前は通常のオブジェ
クトとして扱うことが可能であり、SOR のオブジェク
ト共有空間に格納することで外部からのメソッド呼び
出しを受け付けるようになる。
2.2
SOR システムの構成
SOR システムとは、SOR が提供する枠組みに従っ
て作成された、オブジェクト共有空間の実装をユーザ
に提供するためのシステムである。各ホストでそれぞ
れ動作している SOR サーバが協調して一つの SOR シ
ステムを形成する。SOR サーバは内部に一つ以上のオ
2.3.2
遠隔メソッド呼び出し
SOR のオブジェクト共有空間に格納された共有オブ
ジェクトへの参照として proxy [5, 6] を利用する。利
用する側はローカルな proxy へアクセスすることで共
有オブジェクトへのメソッド呼び出しを行なう。これ
ブジェクト共有空間の実装を保持しており、オブジェ
により、通常のオブジェクトに対するメソッド呼び出
クト共有空間の実装は他の
しと同一の文法で共有オブジェクトのメソッド呼び出
SOR サーバ内にある同種
のオブジェクト共有空間の実装と協調して一つの仮想
しを記述できる。既存の ORB では呼び出されるオブ
的な共有空間を形成する。
ジェクトの場所は固定されており、共有空間内でのオ
ユーザから見た SOR システムの概念図 (図 1) と SOR
システムの実装の概観 (図
2) を以下に示す。
ブジェクトの移動や複製に対応することが困難である。
従って、SOR では独自に遠隔メソッド呼び出しのため
の機構を用意する。
既存の ORB の遠隔メソッド呼び出しでは、分散オブ
ジェクトが引数や返り値として渡される場合、代りに
その proxy が値として送られる。それ以外のオブジェ
Network
Sharable Object
SharedSpace Impl.
SOR System
SharedSpace
SOR Server
SharedSpace
JVM
Host A
Host B
図
Host C
2: SOR システム実装の概観
クトはその複製が転送される。SOR では格納された共
位置を確定するための仕組みが必要となる。複製を行
有オブジェクトのメソッド呼び出しの引数としてまだ
う場合は、特定の一貫性モデルを選択し、オブジェクト
格納されていない共有オブジェクトが渡された場合、
のメソッドの read/write 属性を判断する必要がある。
共有空間への格納として処理する。引数として指定さ
共有オブジェクトの移動や複製は proxy を通しての
れた未格納の共有オブジェクトはその複製が共有空間
アクセスによってプログラマからは隠蔽することが可
へと転送され、呼び出された共有オブジェクトには引
能であると考えているが、実際に実装して検証を行う
数として指定された共有オブジェクトの proxy が渡さ
のは今後の課題である。
れる。したがって、共有空間内で共有オブジェクトが
他の共有オブジェクトを参照する場合は必ず proxy を
通しての参照となる。これにより、格納された共有オ
ブジェクトの移動や複製を共有オブジェクトとインス
2.3.4
クラス構成
オブジェクト共有空間のインタフェースとして、以
タンス変数として参照されるオブジェクトのグループ
下の 5 つのメソッドをもった RepositoryContext クラ
単位で行うことが可能である。共有オブジェクトでは
スを提供する。
ないオブジェクトや proxy は引数及び返り値として複
製が渡される。
2.3.3
共有オブジェクトの配置
SOR を利用するプログラマは、共有空間内の共有オ
ブジェクトが実際にどのホスト上にあるのかを知る必
要はなく、物理的な位置を意識せずに共有オブジェク
トにアクセスすることができる。
オブジェクト共有空間の実装で共有オブジェクトを
put 共有空間にオブジェクトを格納する
remove 共有空間からオブジェクトを削除する
bind 登録したオブジェクトと名前を関連付ける
unbind オブジェクトと名前の関連付けを削除する
lookup 名前から関連付けられたオブジェクトを探し
出し参照を返す
RepositoryContext の実装のクラス構成を図 3 に示
どのように配置するかは、主に通信効率に関わる問題
す。
である。共有オブジェクトの配置戦略は大まかに以下
ObjectRepository 共有オブジェクトを管理するた
の 3 通りに分類できる。
1. 複製なし移動なし
2. 複製なし移動あり
3. 複製あり
1 は最も基本的な配置であり、必要なリソースの位置
が固定される場合が考えられる。2 は共有オブジェクト
に能動的な移動の機能を提供する場合や、移動によっ
て通信性能の向上を図る場合が考えられる。3 は読み
込みを並列に行うことによる通信性能の向上や、複製
の作成による耐故障性の付加などが考えられる。
移動を行う場合は、現時点に置けるオブジェクトの
めのクラス。ObjectRepository は put された共
有オブジェクトに共有空間内で一意になるよう
な識別子を割り当て、その識別子と共有オブジェ
クトへの参照を管理する。put は内部に識別子を
もった
proxy をインスタンス化して返す。一定
期間参照の起きなかった共有オブジェクトをメモ
リからディスクへ追い出し参照が再び起きた時
にディスクからメモリへ戻す責任を持つ。
ProxyGenerator
遠隔手続き呼び出しのための proxy
クラスファイルを共有オブジェクトのクラスファ
イルから生成する。共有オブジェクトの配置戦略
RepositoryContext
オブジェクトは put されたホスト上の ObjectRepos-
itory が管理をする。移動や複製は行なわない。proxy
ProxyGenerator
ProxyGenerator
generate
Proxy Classfile
機能
3.1
ObjectRepository
はインスタンス変数として共有オブジェクトの位置を
SharableObject
保持し、メソッド呼び出しの際は共有オブジェクトが
実際に存在する SOR サーバと直接通信を行なう。
NamingService
NamingService
Proxy
永続化
RMI
Return Proxy
lookup
Proxy
RMI
ClientObject Client
Process
図
3:
bind
put
NamingService に bind されている共有オブジェクトは
proxy からの参照がなくなっても ReferenceManager に
よって回収されない。共有オブジェクトが回収される
ClientObject
Client
Process
のは proxy からの参照がなくかつ NamingService から
も参照されていない場合のみである。
Observable クラス
SOR における遠隔メソッド呼び出しはクライアントの
クラス構成の概略図
オブジェクトから共有オブジェクトへの一方通行であ
として複製を行なう場合は proxy の生成時に共有
オブジェクトのメソッドを検査して、read/write
属性を判断する方法が考えられる。
proxy を関連づけて保持する NamingService ク
ラスを提供する。NamingService クラスは特殊
な共有オブジェクトであり、固有の識別子を持
RepositoryContext の実
装によりアクセスされ、単純な名前付けサービ
しては特に有用なパターンであると考えられるためそ
の回避策として Observable クラスを提供している。
3.2
分散プログラムの記述
分散プログラムの例として、本実装を利用したカウ
スを提供する。bind 、unbind 、lookup は実際に
ンターの記述について述べる。カウンターは内部に int
は
を一つもった共有オブジェクトである。内部状態を変
NamingService への遠隔メソッド呼び出しと
なる。
ReferenceManager proxy が共有オブジェクトへの
参照となる。従って、現在存在する
proxy の数
を把握しておけば回収するべきタイミングを判
断できる。JavaRMI の分散ガベージコレクショ
ンにならい、共有オブジェクトの参照は一定期
間で無効になり、参照を保持するために一定期間
毎に参照を更新する方法を採用している。SOR
では分散ガベージコレクションのためのクラス
ReferenceManager を提供する。
3
ンパターンを適用することができない。Observer デザ
インパターンはオブジェクトの共有というモデルに関
NamingService ブートストラップのために名前と
つ。NamginService は
り、CallBack を行う共有オブジェクトを記述できない。
そのため共有オブジェクトにたいして Observer デザイ
実装の一例
前の節で述べた枠組みに従い、オブジェクト共有空
間を試作した。この節では試作した実装について紹介
する。
更するメソッドとして inc を持つ。inc メソッドにより
値を一つ増やした共有オブジェクトは、変更をカウン
ターを監視している全てのオブジェクトに通知する。
プログラムを図
4 に示す。
public class SharableCounterImpl
extends sor.basic.ObservableImpl
implements SharableCounter {
int count;
public SharableCounterImpl(){
count= 0;
}
public int inc(){
setChanged();
count++;
notifyObservers(new Integer(count));
return count;
}
}
図
4: ObservableCounter の実装プログラム
共有オブジェクトの Observer になるには update メ
ソッドを実装して Proxy の addObserver(Observer) に
4
tifyObservers() が呼ばれたらその Proxy によって Observer の update メソッドが呼び出される仕組みになっ
Java を利用した分散オブジェクトシステムは数多く
研究されている [1, 2, 3]。分散オブジェクトシステム
よって自身を登録すれば良い。共有オブジェクトの no-
ている。
関連研究
は分散システムを構築する上での基本的な機能しか提
この共有空間を利用することで同期型のチャットや
供していないため、特定の分散オブジェクトにアクセ
共有ホワイトボードはもちろんデータを永続化するこ
スが集中して隘路が発生することを考慮したり、耐故
とで非同期型の掲示板等の分散システムを容易に記述
障性を考慮しながらプログラムを記述する必要がある。
できる。さらに共有オブジェクトを複数組み合わせて
SOR では、オブジェクトへの並列アクセスや耐故障性
利用することでより複雑な
といった分散特有の問題をオブジェクト共有空間内で
CSCW アプリケーション
の実装に役立てることが可能である。
解決することで、分散システムを構築する際に分散特
有の問題を切り分けて考えることが可能である。
3.3
遠隔メソッド呼び出しの性能の比較
JavaSpaces [4] はオブジェクトの共有を行う空間を
SOR と類似しており、共有空間
提供するという点で
Java の代表的な分散オブジェクトである JavaRMI と
に格納されたオブジェクトのメソッド呼び出しが出来
本実装が提供する遠隔手続き呼び出しで速度の比較を
Linda のタプルスペースに基づいており、タプルの照
おこなった。primitive である int を引数にとってそのま
ま返り値として返すメソッドをそれぞれ実装し
100000
回呼び出しそれを 5 回おこなって平均を算出した。同
様に引数と返り値を
Integer にしたものに対しても実
験を行った。呼び出すオブジェクトと呼び出されるオ
ブジェクトとは同じホスト上で動作している。
int
1.20
7.11
引数
JavaRMI
本実装
単位:ms
引数
Integer
3.12
7.13
Solaris SPARC JDK 1.1.5, Native Thread, JIT Compiler
使用, Solaris2.6, SunUltraSPARC-II 248 MHz
表
1:
ないという点で SOR と異なっている。JavaSpaces は
合によってプロセス間でオブジェクトのやり取りを行
う。ある空間から別の空間へオブジェクトが流れてい
くことにより分散システムが形成される。一方、SOR
は共有空間に格納したオブジェクトのメソッド呼び出
しを通じてオブジェクトのやり取りを行う。異なる場
所で複数の人間が同じデータを利用して作業するよう
な分散システムの記述は、オブジェクトが流れるモデ
ルと比較して、SOR のオブジェクトを直接共有するモ
デルの方が適している。また、プロセス間で頻繁にメッ
セージがやり取りされる場合、Linda モデルの実装は
タプルの照合を効率的に行う必要がある。一方、SOR
は共有空間に格納したオブジェクトのメソッド呼び出
しを通じてオブジェクトのやり取りを行うため照合の
遠隔メソッド呼び出しにかかる時間の比較
手間がかからない。
また、本研究はオブジェクトの共有と永続化を提供
JavaRMI と比較して 2 倍以上時間がかかる原因は、
SOR が Skeleton とよばれるクラスの作成を行ってい
ないことに起因する。Skeleton クラスは Stub クラス
と対応しており、Stub はメソッドの番号を送ることで
Skeleton はオブジェクトの対応するメソッドを直接呼
び出している。一方 SOR は Skeleton がないために、
メソッドの名前や引数の型と言った余分な情報を送る
必要がある。これらの
marshaling の時間がオーバー
ヘッドの原因になっている。
従って、遠隔メソッド呼び出しについては Skeleton
を作成することで、今後 JavaRMI と同等の性能を出
DSR [7] 、PerDiS [8] 等とも関連する。DSR や
PerDiS は特定の言語に依存せずにオブジェクトの共有
及び、永続化をサポートする。どちらも明確に CSCW
する
の分野のアプリケーションを対象として打ち出してお
り、オブジェクトの永続と共有が CSCW の分野に適し
ていることが示されている。さらに、扱うデータのセ
キュリティも重要な問題であり、双方の研究で議論さ
れている。SOR は Java のみで記述されていることに
より
Java のもつ利点を完全に活かすことが可能であ
り、また、ユーザにとって利用しやすいことが期待さ
れる。
すことが可能である。また、共有空間の実装でローカ
ルホストに共有オブジェクトをキャッシュすることで
更なる性能の向上が見込まれる。
5 まとめと今後の目標
Java によるオブジェクト共有空間の実装手法につい
て述べ、オブジェクト共有空間を利用した分散プログ
ラミング支援フレームワーク SOR を提案した。オブ
and persistency, Proc. 13th Int. Conf. on Distributed Computing Systems, IEEE Computer
Society, pp. 20{29, 1993.
ジェクト共有空間は proxy による通信の隠蔽と共有オ
ブジェクトの位置透過性を提供する。さらに複製を作
成することで並列アクセスによる効率の向上が可能で
あり、複製のオリジナルが消失した場合もコピーから
オリジナルを選出することで耐故障性を高めることが
可能である。また、スレッドを保持した共有オブジェク
トの移動を行うことにより負荷分散の応用も考えられ
る。オブジェクト共有空間の実装は柔軟に入れ替えが
可能であり、必要に応じて、ユーザのプログラムに変
[8] Marc Shapiro, Sytse Kloosterman, and Fabio
Riccardi: PerDiS | a Persistent Distributed
Store for Cooperative Applications, Proceedings
of the 3rd Cabernet Plenary Workshop, IRISA
Rennes, France, 1997.
http://www.perdis.esprit.ec.org/papers/
更を加えることなくその性能を改善することができる。
オブジェクト共有空間は、CSCW の分野を対象とし
た分散システムのサポート、エージェントの協調の場、
ファイルシステムやデータベースとしての利用等様々
な応用が考えられる。
今後の目標として、まず、共有オブジェクトの移動
及び複製への対応、メソッド呼び出しの高速化が挙げ
られる。また、セキュリティや負荷分散に関しても考
慮していく必要があると考えている。
参考文献
[1] Sun Microsystems, Inc.: Java Remote Method
Invocation Specication, 1997.
http://java.sun.com/products/jdk/rmi/
[2]
平野聡: 分散 Java 実行のためのポータブルな ORB
の構成法, 情報処理研究報告 96-OS-73, pp. 55{60,
1996.
[3] ObjectSpace: ObjectSpace Voyager Version
2.0.0 User Guide, 1997.
http://www.objectspace.com/developers/voyager/white/
[4] Sun Microsystems, Inc.: JavaSpaces Specication, 1998.
http://java.sun.com/products/javaspaces/
[5] Marc Shapiro: Structure and Encapsulation in
Distributed Systems: the Proxy Principle, Proc.
6th Int. Conf. on Distributed Computing Systems, IEEE Computer Society, pp. 198{204,
1986.
[6] Andrew Birrell, Greg Nelson, Susan Owicki, and
Edward Wober: Network Objects, DEC SRC
Res. Rep. 115, 1994.
[7] Kazuhiro Kato, Atsunobu Narita, Shigekazu Inohara, and Takashi Masuda: Distributed shared
repository: a unied approach to distribution

Download Report