分散マルチメディアミドルウェアの移植経験に基づく CORBA と Ice の

分散マルチメディアミドルウェアの移植経験に基づく
CORBA と Ice の比較及び評価
小佐原大輔
若林正男
徳永英治
中島達夫
早稲田大学理工学部コンピュータ・ネットワーク工学科
要旨
Ice（Internet Communication Engine）は ZeroC, Inc. が公開しているオブジェクト指向分散
ミドルウェアである．従来のオブジェクト指向分散ミドルウェアである CORBA と比べて，複
雑な仕様を避けた習得容易性を実現しながらも，充分なスケーラビリティとセキュリティを実
現している．しかし，仕様の差異からは，実際の開発における Ice の有用性を充分に論じるこ
とは難しい．
そこで我々は，CORBA を用いて実装したミドルウェアを実際に Ice へ移植し，仕様上の差異
からは実感できない，経験に基づいた CORBA と Ice の比較及び評価を行う．主な比較・評
価項目は，移植中の不整合，移植中に実感したプログラミング抽象度の違い，移植後のソース
コード量及びバイナリの大きさの変化，オーバヘッドの比較，アプリケーションの実装にあた
える影響，などである．
1
る Ice へ移植し，その経験を基に，それら２つの
導入
オブジェクト指向分散ミドルウェアの比較，評価を
将来のユビキタスコンピューティング環境（以下，
行った．MiRAGe は CORBA を基盤とした，ユ
ユビキタス環境）では，生活や社会の至る所にコン
ビキタス環境のための分散マルチメディアミドル
ピュータが存在し，自律的に連携することにより，
ウェアである. しかし，CORBA の仕様は非常に複
我々の生活に大きな利益をもたらす．しかし，ユビキ
雑であり，MiRAGe の開発には非常に多くの労力
タス環境におけるシステムは，多様なプラットフォー
を要した．また，今後の運用，保守，拡張において
ムを持ち，あらゆる場所に分散したコンピュータに
も多くの労力が必要であることが予想できた．し
よって構成される為，システム開発者にかかる負担
たがって，より容易な開発，保守が可能な分散オブ
は非常に大きい．そこで，プラットフォームの差異
ジェクトミドルウェアが必要であった．そこで我々
を吸収し，分散環境の複雑さを隠蔽する分散ミド
は，ZeroC, Inc. が提案及び実装し，GPL に基づい
ルウェアの利用が有効である．分散ミドルウェアは
て公開されているオブジェクト指向分散ミドルウェ
多様性の吸収やネットワーク透過性を提供するだけ
ア Ice（Internet Communication Engine）[2] に着
でなく，名前解決などの標準的な分散サービスやス
目した．Ice は CORBA と比べて，複雑な仕様を避
レッド，オブジェクトモデルなどのプログラミング
けた習得容易性を実現しながらも，充分なパフォー
モデルを提供するため，システムの開発容易性，拡
マンスを実現している．我々は新しい MiRAGe の
張性及び管理容易性に大きな影響を与える．従って，
基盤として Ice を採用し，CORBA からの移植を
ユビキタス環境におけるシステムの品質を向上させ
行い，その開発及び保守容易性とパフォーマンスを
るためには，適切な分散ミドルウェアの適用が必要
評価した．今回の移植経験から，仕様上の差異のみ
である．しかし，プログラミングモデルを含む分散
では得られない様々な評価を得ることが出来た．こ
ミドルウェアの評価は，仕様の比較だけでは難しい．
れらの評価から得られた知見は，将来のユビキタス
環境における分散オブジェクトミドルウェアの応用
そこで我々は，以前に開発した分散マルチメディア
に非常に有用である．
ミドルウェア MiRAGe[7, 8] を，従来基盤としてい
た，標準的な分散オブジェクト環境である CORBA
本論文の構成は以下の通りである．2 節では
から, 次世代の分散オブジェクトミドルウェアであ
CORBA から Ice へ移植した我々の分散マルチメ
–1–
ディアミドルウェア MiRAGe についての概要を述
べる．3 節では，オブジェクト指向分散ミドルウェ
アについて概説し，MiRAGe を CORBA から Ice
へ移植した理由についても述べる．4 節では移植の
経験とそこから得られた評価として，仕様の差異か
ら生じた移植中の不整合，移植中に実感したプログ
ラミング抽象度の違いについて述べる．また，定量
的評価として，移植後のソースコード量の変化やバ
図 1: MiRAGe アーキテクチャ
イナリの大きさ，オーバヘッドの比較，MiRAGe を
用いたアプリケーションに与える影響を述べる．5
節で移植の経験及び評価についての考察を述べる．
6 節で関連研究について述べ，7 節をまとめとする．
照先を環境の変化に応じて動的に切り替える状態動
的適合機構を実装しており，ポリシを実装すること
でユビキタス環境の動的な変化に半自動的に対応す
2
MiRAGe について
2.1
る [7, 8]．
MiRAGe の概要
MiRAGe は，ユビキタス環境 [9, 6] におけるマ
ルチメディアアプリケーション開発に要求される，
多様性，分散処理，動的再構成の管理を抽象化し
たミドルウェアであり，CORBA 互換 ORB であ
る omniORB[5] を基盤として設計及び実装されて
いる．
分散マルチメディアアプリケーションを構築す
るソフトウェア部品として，CORBA 通信インタ
フェースを持つメディアコンポーネントを定義して
おり，それらコンポーネントを接続することで分散
マルチメディアアプリケーションを容易に構築する
ことができる．
各メディアコンポーネントはマイクロモジュー
2.2
MiRAGe のアプリケーション例
MiRAGe の主なアプリケーションは，ユビキタ
ス環境における分散複合現実感やフォローミービデ
オのような動的なマルチメディアストリーミング制
御である．図 2 では，負荷の高い複合現実感処理
を分散し，PDA で 3D イメージの動的なスーパー
インポーズを可能にしたアプリケーションである．
MiRAGe の状態管理機構は，ユーザに物理的に近
いカメラをセンサを用いて動的に感知し，そのカメ
ラからのマルチメディアストリームを自動的にユー
ザの持つ PDA へ接続する．
ルから形成される．マイクロモジュールには VU
System[4] に良く似た，ソース（マルチメディアデー
タを送信する）
・フィルタ（マルチメディアデータ
を処理する）
・シンク（マルチメディアデータを受
信する）の 3 つのタイプを持つ．
MiRAGe は，分散したメディアコンポーネントが
持つマイクロモジュール間のマルチメディアストリー
ムを容易に接続，切断するための機能を CORBA イ
ンタフェースとして提供している（図 1）．
また，MiRAGe は CORBA のオブジェクト生成
に必要な煩雑な処理を隠蔽するライブラリを用意し
ており，アプリケーション開発者は CORBA を利
用したアプリケーション開発に必要な複雑な処理を
図 2: 分散複合現実感
比較的意識せずに開発できる．
さらに，MiRAGe は CORBA オブジェクトの参
–2–
3
分散オブジェクトミドルウェア
通信先の実装言語を意識する必要性はない．
また，CORBA における CORBA サービスのよ
本節では，MiRAGe の基盤技術である，オブジェ
うに，Ice においても Ice サービスと呼ばれる拡張
クト指向分散ミドルウェアについて述べる．CORBA
が存在する．
及び Ice の概要を示し，その仕様上の差異について
概説する．また，非オブジェクト指向の分散ミドル
3.3
ウェアについても述べる．最後に，以上で挙げた差
異を基に，MiRAGe を CORBA から Ice へ移植す
3.1 節，3.2 節で述べたように，CORBA と Ice は
非常に類似した分散ミドルウェアではあるが，様々
な点において仕様上の差異が認められる．ここで
は特に，MiRAGe の実装に影響を与える差異を述
べる．
る必要性について述べる．
3.1
Ice vs CORBA
CORBA
CORBA（Common Object Request Broaker Architecture）は OMG によって標準化されている，分
散オブジェクト間のメッセージ通信を ORB を介し
て位置透過的に実現するミドルウェア基盤技術で
オブジェクトモデル
Ice と CORBA のオブジェク
トモデルでは，オブジェクト参照の表現に大きな差
異が見られる．Ice はリモートホスト上のオブジェ
クト参照を表す Proxy という型を用意している．
ある．
同様の技術に DCOM や Java RMI などが存在す
Proxy は CORBA のオブジェクト参照型と同様の
役割を果たすが，より明確な記述で表現される．以
下に Proxy 型の記述例を示す．この例では，オブ
ジェクトは SimplePrinter という ID で，アドレス
192.168.123.51 の 10000 番ポートを利用しており，
転送プロトコルとして TCP/IP を利用しているこ
とがわかる．
るが，これらは特定の環境や言語においてのみ動作
する．一方，CORBA は IDL（Interface Definition
Language）によってオブジェクトの実装と定義を
分離しているため，環境や言語に依存しない分散ア
プリケーションの構築が可能である．現在、OMG
が IDL マッピングを定義している C, C++, Ada,
Smalltalk, COBOL, Java 言語が利用可能である．
SimplePrinter:tcp -p 10000 -h 192.168.123.51
CORBA では，CORBA サービスと呼ばれる外
部拡張インタフェースを用いて ORB の機能を拡
一方で，CORBA のオブジェクト参照型は，一
張及び補完することができる．例えば，オブジェク
見してオブジェクトの情報が理解できる記述ではな
ト・リファレンスの登録と検索を実現するネーミン
い．また，CORBA におけるオブジェクト参照のエ
グ・サービスやセキュリティ・サービスといった各
ンコーディングは，IOR や Corbalock，corbaname
種サービスを用意しており，これらの機能を盛り込
といった複数の方式が存在しているために，オブジェ
んだ高度なアプリケーションを実装することも可能
クト参照の比較には特別な関数を呼ぶ必要がある．
である．
CORBA のオブジェクト参照は，プログラムの複雑
さを増す大きな要因の一つとなっている．
3.2
Ice
多言語環境
インタフェース定義言語とのマッピン
Ice は ZeroC, Inc. によって開発された分散オブ
ジェクトミドルウェアである．Ice は CORBA のよ
グは，CORBA, Ice 共に，JAVA, C++ とのマッピン
うな既存の分散オブジェクトミドルウェアの利点を
Ada, SmallTalk, C などの言語をサポートする．
CORBA の主な目的の一つとして，古いプラット
グをサポートしている．CORBA は他に，COBOL，
踏襲しつつも非常にシンプルに設計されている．
CORBA と同様に，Ice もオブジェクトの実装と
インタフェース定義を完全に分離させている．イン
フォームで実装されているプログラムと新しいプ
タフェース定義は CORBA IDL に類似した Slice
比較的古い言語のサポートが充実している．対して
というインタフェース定義言語を用いて定義する．
Ice は，C#, PHP, Python, Visual Basic など比較
CORBA IDL と同様に言語独立性が保たれており，
的新しい言語とのマッピングをサポートしている．
ラットフォームで実装されたものとの統合があり，
–3–
外部サービス
3.4
CORBA, Ice 共に分散オブジェクト
環境に必要な様々な外部サービスを提供している．
しかし，CORBA では仕様が策定されているにも
関わらずほとんど実装が見られないサービスや，仕
様が曖昧で異種 ORB ベンダ間のインタオペラビリ
ティが充分でないサービスも多い．対して Ice は，
仕様を策定している ZeroC, Inc. が全ての仕様のリ
ファレンス実装を提供している．また，CORBA 標
準ではサポートされていない非同期なメソッドディ
スパッチ，ファイヤーウォールや NAT を越えるた
めのサービス，通信の暗号化，UDP 上の通信など
を実現するサービスが標準で提供されている．
MiRAGe を現実的な環境で動作させるために，こ
れら付加サービスの安定したサポートは非常に重要
である．
その他の分散ミドルウェア
CORBA や Ice の他に，分散アプリケーションを
構築するための技術として，SOAP や XML-RPC
などの Web サービス技術がある．これら Web サー
ビス技術の特徴は，XML によるメッセージングを
採用したことで，柔軟で汎用性の高いデータ・アク
セス機能を備えた点や，下位プロトコルとしてイン
ターネットで広く利用されている HTTP を使用し
ている為に，異なったプラットフォームや異なった
言語間で相互接続性の高い RPC 環境が構築できる
点にある．
3.5
Ice 選択に至る動機
以上で挙げた差異を基に，MiRAGe を CORBA
から Ice へ移植する必要性について述べる．
オブジェクト指向分散ミドルウェアを基盤とした
C++ マッピング CORBA における C++ マッ
ピングは非常に複雑であり，特にメモリ管理の煩雑
さは，多くの開発者を苦心させる CORBA の悪し
き特徴である．熟練した開発者でも，メモリリーク
をしないアプリケーションを構築するためには細心
の注意を払わなくてはならない．
システムである MiRAGe おいて，MiRAGe を扱う
プログラマはミドルウェアが提供する分散オブジェ
クトのモデルを直接扱うことになる．Ice のシンプ
ルで容易に理解可能なオブジェクトモデルが与える
利益は大きい．
また，ユビキタス環境における分散マルチメディ
一方 Ice の C++ マッピングは，インスタンスを
アを扱うためのシステムである MiRAGe にとって，
動的にスマートポインタタイプとして割り当てるた
今後実装される新しいサービスとの統合は重要とな
め，メモリ管理の労力が激減する．スマートポイン
る．よって，Ice がサポートする新しい言語とのマッ
タのマッピングを実現している ORB ベンダ固有の
ピングは重要な要素である．
CORBA 実装も存在するが，CORBA の仕様とし
ては策定されていない為，多プラットフォーム間で
移植性のあるコードにはならない．
MiRAGe のシステム内部は主に C++ で実装さ
れている．Ice を基盤とすることによりメモリ管理
を単純化できれば，今後の拡張及びメンテナンスが
劇的に容易になる．
分散オブジェクトのプログラミングでは
また，MiRAGe のマイクロモジュールはそれぞ
スレッドを扱う場合が多い．しかし，CORBA の
れスレッドを持ち，C++ で実装されている．Ice は
仕様には，プログラミングレベルでのスレッドの
標準でスレッドライブラリをサポートしているため，
仕様が存在しない．スレッドライブラリを提供する
実装の拡張及び管理が容易になり，様々なプラット
CORBA 互換 ORB も少なくないが，それらはプ
フォームで動作することを保証できる．
ラットフォーム特有の API である．これは，特に
C++ でのアプリケーション構築で問題を発生させ
SOAP や XML-RPC などの Web サービス技術
と比較した場合，MiRAGe を使ったアプリケーショ
る．C++ のスレッドの実現方式は各プラットフォー
ン開発はオブジェクト指向設計に強く依存している
ム（主にオペレーティングシステム）によって異な
ため，これら非オブジェクト指向分散ミドルウェア
り，それら全てに対応するソースコードを記述する
を基盤技術として利用することは難しい．また，各
には多大な開発コストを要する．Ice は標準で C++
分散オブジェクトの状態管理やアクティベーション
のスレッドライブラリを提供している．Ice のスレッ
も MiRAGe において重要な機能であり，それら機
ドライブラリを利用する C++ のコードは Ice が動
能が欠けた Web サービス技術は基盤技術として適
作するどのプラットフォームでも動作する．
切でない．
スレッド
–4–
以上の理由により，Ice を移植基盤として選択す
module IFACE
{
typedef unsigned long DataType;
typedef unsigned long ObjectId;
typedef unsigned long StreamId;
typedef unsigned long SubStreamId;
typedef unsigned short Priority;
るに至った．
4
MiRAGe の Ice への移植評価
本節では，実際に MiRAGe を CORBA から Ice
に移植することによって得られた CORBA に対す
る Ice の実装上の差異を示し，定性的評価とする．
interface MConnIface {
void configureStream(in ObjectId nTargetId, in StreamInfo info);
void startStream(in ObjectId nTargetId, in StreamId nStreamId);
void stopStream(in ObjectId nTargetId, in StreamId nStreamId);
};
};
また，定量的評価としてソースコード量とパフォー
マンス測定を行う．
4.1
4.1.1
struct StreamInfo {
StreamId nStreamId;
SubStreamId nSubStreamId;
ObjectId nDestination;
Priority nPrio;
};
移植上の経験
図 3: MiRAGe IDL 定義の一部
IDL 定義と Slice 定義
インタフェース定義言語である CORBA IDL と
Ice Slice は類似しているが，幾つかの差異がある．
MiRAGe の移植の際に最も影響の大きかった点の
一つは CORBA IDL が C 言語に良く似た typedef
文法を持つのに対して，Ice Slice に型エイリアスの
定義が無いことであった．
ZeroC, Inc. は分散オブジェクト環境における型エ
イリアスの存在は複雑さを増加させ，ORB 実装を困
難にさせると主張している [2]．現に，CORBA 2.6
仕様でも未だに型一致の定義に問題を残している．
MiRAGe は，インタフェースの引数にセマンティ
クスを与え，IDL の可読性を増すために typedef を
多様していた．例えば，MConnIface インタフェー
スで，ストリームをスタートさせる startStream メ
ソッドの場合，typedef した ObjectId 型，StreamId
型を引数に使用していた（図 3）．
module IFACE
{
struct StreamInfo {
long SIdOfnStreamId;
long SSIdOfnSubStreamId;
long OIdOfnDestination;
short PrioOfnPrio;
};
interface MConnIface{
void configureStream(long OIdOfnTargetId, StreamInfo info);
void startStream(long OIdOfnTargetId, long SIdOfnStreamId);
void stopStream(long OIdOfnTargetId, long SIdOfnStreamId);
};
};
図 4: MiRAGe Slice 定義の一部
4.1.2
ORB 初期化の隠蔽
MiRAGe は分散オブジェクト生成に必要な煩雑
な初期化処理を隠蔽するライブラリを用意してお
り，アプリケーション開発者は複雑な処理を意識せ
ずに開発できる．従来の MiRAGe では，CORBA
POA（Portable Object Adapter）機能を利用して
おり，POA に与えるポリシ設定の隠蔽に複雑なプ
ログラムが必要であった．
その結果，IDL 記述はシンプルで理解しやすい
ものになったが，ミドルウェア実装を拡張もしくは
変更する際にプログラマの努力を必要とした．ま
Ice では，POA のようなポリシベースのオブジェ
クトアダプタは単純化のため存在しない．MiRAGe
た，MiRAGe の Java 実装を行った際に，CORBA
typedef はプログラマの混乱を引き起こした．
今回の移植では，typedef で型エイリアスを定義
の分散オブジェクト生成のソースコードは CORBA
していた型を全て Slice の標準型へ変更した．その
を用いたものよりもシンプルに移植および実装で
際，typedef で与えていたセマンティクスを失わせ
きた．
ないために，引数の名前にセマンティクスを反映さ
せた（図 4）．
4.1.3
他にも Ice Slice は，inout 引数がない，Any 型
スマートポインタ
がないなど，言語マッピングの複雑さを避ける仕様
分散オブジェクトを C++ で実装する際のメモリ
になっている．それらの要素は今回の移植では特に
管理は非常に複雑である．そこで，CORBA，Ice と
問題を生まなかった．
もにプログラマのメモリ管理の負荷を軽減する機構
–5–
また，IcePack は標準でオブジェクト参照の動的
を標準で提供している．
CORBA では，IDL で定義したインタフェース
な切替機能を提供している．従来の MiRAGe の状
のオブジェクト参照へのスマートリファレンス型と
態動的適合機構は，ORB のオブジェクトリファレ
して var 型を用意している．この型は，型に必要
ンスを直接書き換えるサービスであったため，実
なメモリの所有権を自動的に判断し，var オブジェ
装が複雑化しており，移植性が低かった．IcePack
クトのサーバントが破棄されたり，新しいサーバ
のオブジェクト参照切替は，間接的なオブジェクト
ントが var リファレンスに割り当てられたりした
アダプタを動的に活性化・非活性化できるもので，
ときにメモリを解放する仕組みを持つ．また，リ
MiRAGe の状態動的適合機構を容易かつ単純に移
植可能であることが確認できた．
ファレンスカウンタの機能を実装した，Portable-
Server::RefCountServantBase というクラスを定義
しており，このクラスを継承することにより，サー
バントに対してリファレンスカウンタの機能が追加
される．
4.1.5
当初の MiRAGe は，omniORB が提供するオ
これに対し Ice では，Slice 定義されたインタフ
ブジェクト指向 C++ スレッドライブラリ（om-
ェースを C++ にマッピングする際，リファレンス
niThread）を利用していた．しかし，omniThread
は omniORB 独自のスレッドライブラリであるた
め，omniORB が動作する環境でしか動作せず，MiRAGe のクロスプラットフォーム性を制限していた．
カウンタ機能を備えるスマートポインタに自動的に
マッピングされる．
従来の MiRAGe はメディアコンポーネント型が
PortableServer::RefCountServantBase クラスを継
承する事によってリファレンスカウント型のスマー
トポインタを利用していたが，C++ の多重継承を
誘発し，ソースコードの複雑化を避けることができ
なかった．Ice へ移植する際，C++ オブジェクト
はすべてスマートポインタにより自動的に解決され
る．よって，多重継承を廃し，煩雑さとコード量を
軽減することができた．
4.1.4
スレッド
Ice の提供するスレッドライブラリもオブジェク
ト指向に準じて設計されており，omniThread に良
く似た構造及び API を持つ．そこで，MiRAGe の
スレッド処理部分を Ice が提供するスレッドライブ
ラリへ移植した．しかし，実際に実装してみると，
幾つかの点で異なる構造を持つことが分かった．
ネーミング処理
MiRAGe は分散して配置されているメディアコ
ンポーネントの発見，検索，動的なバインディング
をサポートする．従来は，CORBA の INS（Interoperable Naming Service）を拡張してそれらの機
能を実現していた．しかし，INS は ORB ベンダが
標準でサポートする外部サービスではない．また，
omniThread でクリティカルセクションの排他制
御を行うためには omni mutex と omni condition
の２つのオブジェクトを利用する．omni mutex は
クリティカルセクションのロック機能を提供し，
omni condition がスレッドの wait 及び notify の
メッセージング機能を持つ．対して，Ice において
はメッセージング機能を持つ IceUtil::Monitor クラ
スがロック機構を持つ IceUtil::Mutex クラスを内
包するため，クリティカルセクションのロック，ア
ンロック，スレッドの待ち処理，起動処理を一つの
クラスを継承するのみで行うことができる．
INS 実装における参照永続化などのユーティリティ
また，wait 状態のスレッドを起こすための notify
機能は CORBA で仕様化されておらず，特定 ORB
オペレーションにも違いがある．omni condition で
ベンダに依存した実装にならざるを得なかった．
は，通知オペレーションが呼ばれると待ち状態にあ
Ice へ移植する際，Ice のルックアップ機構であ
る IcePack を利用することにした．基本的な機能
るスレッドがすぐに起動されるが（notify したス
レッドが lock を取得している場合は，lock が解放
は CORBA INS と大差なく，問題なく移植できた．
されるまでブロックする），IceUtil::Monitor の通
加えて，IcePack は名前登録・検索のルックアップ
知では，通知直後には wait 状態にある他スレッド
ユーティリティツールが豊富であり，テスト及びア
が起動されない．wait スレッドを起動させるため
プリケーションの管理を非常に容易に行うことがで
には，通知を呼んだスレッドがロックを開放して初
きた．
めて他スレッドが起動される．
–6–
以上のように Ice が提供するスレッドライブラリ
と omniThread は，排他制御の機構のセマンティク
スが異なった．どちらのセマンティクスが有効であ
omniORB
Ice
MiRAGe コアのコード量（行）
2,274
2,204
自動生成されるコード量（行）
1,510
2,256
合計
3,784
4,460
るか評価することはここでは難しいが，移植の結果，
MiRAGe のスレッド処理部分のプログラムコード
は大幅に単純化され，可読性も増した．
4.2
4.2.1
表 1: コード量
コード量及びパフォーマンスの比較
ソースコード量
CORBA から Ice ヘ移植した際に影響を受けた
MiRAGe のコア部分のソースコード量を比較した
（表 1）．Ice を用いた MiRAGe が CORBA を用い
たものに比べ，70 ライン程少ない結果となった．こ
の差の主な要因は，スレッド処理部分が大幅に単純
化したことにある．これは，Ice が提供するスレッ
ドライブラリがシンプルな API を提供している為
である．
コード量（行）
ファイル数
名前付け
201
27
ORB 初期化
66
3
スマートポインタ
41
6
ネーミング
132
2
スレッド
89
15
合計
554
-
表 2: 変更したコード量とファイル数
コンパイル環境は，Linux kernel 2.4.20, gcc-3.2.2
である．前節で述べた通り，自動生成されたコード
しかし，インタフェース定義言語から自動生成さ
を含めるとソースコード量は CORBA よりも Ice
れるソースコードの量を比較すると，Slice が生成す
を用いた方が 18%程大きい．しかし，バイナリサイ
るソースコードが omniIDL（omniORB が提供する
CORBA 互換 IDL コンパイラ）にくらべ 700 行ほ
ど多いという結果になった．Slice は CORBA IDL
の typedef 部分を削っているのにも関わらず，自動
生成するソースコードが比較的大きい．これは，Ice
が標準で提供するユーティリティクラスやスマート
ポインタの記述が含まれているためと考えられる．
ズは逆に Ice を用いたほうが 22%程小さい結果と
なった．これは，MiRAGe がインクルードする Ice
のヘッダが omniORB が提供するヘッダよりも小
さいためと考えられる．
omniORB
バイナリサイズ（byte） 12,712,228
Ice
9,854,376
表 2 は，今回の移植で変更したコード量の合計と，
表 3: バイナリサイズ
関連する項目別に分類した変更コード量，ファイル
数である．表 1 と併せることにより，全体のコード
量の約 4 分の 1 を変更したことがわかる．名前付け
に関するコードの変更は，単純な作業だが，コード
4.2.3
量，ファイル数ともに多くなる．インタフェース定
通信オーバヘッド
義言語の差異が幅広く影響を与えることがうかがえ
それぞれの実装の通信オーバヘッドを簡単に比較
る．しかし，仕様の差異に関連する，ORB 初期化
した（表 4）．カメラから画像を受け取るソース，
とネーミングに関しては，変更したコード量に対し
画像の RGB 色値の R 値と B 値を交換する簡単
て変更したファイル数が少ない．MiRAGe はこれ
なフィルタ，画像をディスプレイに表示するシンク，
らの処理のラッパークラスを提供しており，他のク
それぞれのマイクロモジュールをメディアコンポー
ラスで使用するインタフェースには影響が及ばない
ネントへ格納し，ストリームを流す startStream メ
ためである．
ソッドの実行に要した時間を測定した．実行環境
4.2.2
は全てのメディアコンポーネントがローカルに存
バイナリサイズ
在するケースと，各コンポーネントが 100Base-T
MiRAGe のコア部分をコンパイルしたバイナリ
Ethernet で接続されたリモートに存在するケース
サイズを比較した（表 3）．Ice，omniORB ともに，
で 5 回ずつ計測し，平均値を取った．3 つのメディ
–7–
アコンポーネントを接続する startStream メソッド
ドに対するラッパークラスを設計し，特定分散オブ
は，リモートメソッドコールを合計 8 回実行する．
ジェクトミドルウェアに対する依存性を低く保つか
実験の結果，ローカル通信の場合は omniORB が
らである．MiRAGe も各機能についてラッパーク
Ice に比べ 35%程早いという結果が出たが，リモー
ト接続の場合は，Ice, omniORB にほとんど差は生
じなかった．omniORB はそのスループット性能の
高さを謳う CORBA 互換 ORB である．この結果
は，Ice のスループット性能が決して遜色無いもの
であることを示している．
ラスを用意していたので，それらの部分については
omniORB
Ice
ローカル時 (msec)
4.846
6.589
リモート時 (msec)
10.508
10.310
比較的移植が用意であった．しかし，インタフェー
ス定義言語の仕様差異は，単純なラッパークラスで
は解決できず，分散オブジェクトミドルウェアに依
存するコードが大きくなる．また，Ice の slice 定義
は，CORBA の IDL 記述でしばしば利用されてい
た機能（typdef によるエイリアス付けや void 型に
よる汎用オブジェクト型）を単純化のために排除し
た．そのため，それらの機能を利用していたシステ
ムを Ice へ移植する際には大幅なコード改変が必要
となる．MiRAGe は 4.1.1 節で述べたとおり，IDL
表 4: startStream メソッドの実行速度
の可読性向上のため typedef を多様していたため，
特に大きく影響を受けた．
5
考察
5.2
3 節で述べたように，Ice は CORBA と類似した
仕様でありながら，いくつかの優位な点を持つ．し
かし，それらの仕様上の差異が移植作業へどの程度
影響するかを仕様書のみから読み取る事は困難であ
る．本節では今回の経験から，どの部分の仕様上の
差異が移植の際に大きな影響をもたらすかを考察す
る．また，今回の経験から理想的な分散ミドルウェ
アの条件について考察する．
理想的な分散ミドルウェアとは
分散ミドルウェアの最も重要な目的の一つは，多
様な言語やプラットフォーム間の接続である．その
ため，分散ミドルウェアは開発者に対して，適切な
抽象度をもった分散プログラミングモデルを提供し
なくてはならない．CORBA は，IP に依存しない
オブジェクトモデルを規定し，多様なネットワーク
レイヤを透過的に扱おうとした．しかし，この透過
性のための抽象化が CORBA をわかりづらくする
大きな要因の一つとなってしまった．MiRAGe の
5.1
実装及び保守・運用に置いても，CORBA の過度な
Ice と CORBA の仕様差異と移植
作業にあたえる影響
透過性はしばしば問題となった．一方，3.3 節でも
述べた通り，現状で Ice で利用できる通信プロトコ
Ice は C++ のスレッド機構を標準で提供する．
比較的新しい言語では標準 API としてスレッド機
構が提供されていることが多いが，ある程度以上の
ルは IP のみであるが，オブジェクトモデルの仕様
大規模システムは C++ で実装されている事が多
も有効とは言えず，プログラマに難解さを与える要
く，ミドルウェアで標準に提供される C++ スレッ
因になると考える．
は直感的になり我々の移植効率を向上させた．我々
は，透過性を確保するための過度の抽象化は必ずし
ド機構は依然として有用である．実際，MiRAGe は
また，分散ミドルウェアは時代の進化と共に生ま
C++ で実装されているために，Ice が提供する標
れ続ける新しい言語やプラットフォームに順次対応
準的な C++ スレッド機構はクロスプラットフォー
していく必要がある．しかし，CORBA は枝葉をつ
ム性を保つために非常に有用であった．
けるように仕様の変化を付け加えつづけ，結果的に
4.2.1 節で述べたように，各仕様差異の中でもイン
タフェース定義言語の仕様差異が最もソースコード
非常に複雑な仕様になってしまった．Ice は新しい
に与える影響が大きい．なぜなら，通常分散オブジェ
純化を目的とし，新しいミドルウェアを設計し，あ
クトミドルウェアを基盤としたシステムは，ORB
る程度の成功をおさめているように思える．しかし，
の初期化やネーミング，スマートポインタ，スレッ
同様に新しいプラットフォームやスタンダードが存
プラットフォームへの対応と CORBA の仕様の単
–8–
在しているであろう 5 年後，10 年後において，Ice
オーバヘッドにおいても，Ice は現状の CORBA 互
が有効なミドルウェアである保証もない．つまり，
換 ORB と比べて遜色無い性能を持つ分散オブジェ
Ice は現在のスタンダードにおいては有効な分散ミ
ドルウェアであると言うことはできるが，それは仕
様の新しさによる部分が大きく，分散ミドルウェア
における根本的なパラダイムシフトとは言うことは
できない．
クトミドルウェアである事が分かった．
また，本論文では移植から得た経験と評価から，
Ice と CORBA の仕様差異の中でも特に移植に大
きな影響を与える部分を考察した．結果，ORB 処
理，スレッド処理，名前解決処理はラッパークラス
を用意する事により影響を小さくすることが可能で
あるが，インタフェース定義言語の仕様差異が与え
る影響は多岐にわたる事が分かった．
また，以上の経験から，将来の分散ミドルウェア
への要求および理想的な分散ミドルウェアの条件に
ついて考察した．理想的な分散ミドルウェアとは，
開発者に対して適切な抽象化を提供し，かつ新しい
プラットフォーム，機能要求に柔軟に対応しうるも
のである．しかし現実的には，適切な抽象化を保ち
つつ新しい要求に対応するのは非常に困難であり，
新規のミドルウェアが開発されつづける．そのため，
プラットフォームやプログラミング言語などの多
様性がよりいっそう激化するユビキタスコンピュー
ティング環境においては，システム構築に採用する
ための分散ミドルウェアの評価，選定がさらに重要
となってくるであろう．
理想的な分散ミドルウェアとは，開発者に対して
適切な抽象化を提供し，かつ新しいプラットフォー
ム，機能要求に柔軟に対応しうるものである．しか
し，それを実現することは非常に困難であり，未だ
解の無い挑戦である．
6
関連研究
Ice の原著論文 [2] でも，CORBA と Ice の定性
的な比較がなされているが，CORBA を利用してい
るソフトウェアを Ice へ移植する際の議論はなされ
ていない．また，具体的なソースコード量，バイナ
リの大きさ，オーバヘッドに関する議論もなされて
いない．
また，Ice は Wish と呼ばれる数万人規模のユー
ザが同時にプレイするゲームのミドルウェアとして
も採用された [3]．Wish が要求するスケーラビリ
ティと安定性は Ice の設計方針に大きな影響を与え
参考文献
ている．
[1] C. Demarey, G. Harbonnier, R. Rouvoy and P.
Merle, “Benchmarking the Round-Trip Latency of
Various Java-Based Middleware Platforms”, in Proceedings of The OOPSLA 2004 Component And
Middleware Performance Workshop, CMP 2004,
October 2004
Demarey ら [1] は Java で実装された分散ミドル
ウェアのスループットをベンチマークしている．Ice
や幾つかの CORBA 互換 ORB についても比較し
ており，Ice はほとんどの CORBA 互換 ORB より
もスループットが優れている結果が出ている．
7
[2] M. Henning, “A New Approach to Object-Oriented
Middleware” in Proceedings of Internet Computing,
IEEE Jan.-Feb. 2004 p66-75, Volume: 8, Issue: 1
[3] M. Henning, “Massively Multiplayer Middleware”
in Proceedings of ACM Queue Volume 1 , Issue 10
(February 2004)
まとめ
本論文では，我々が実装した分散マルチメディア
[4] Christopher J. Lindblad, David L. Tennenhouse,
“The VuSystem: A Programming System for
Compute-Intensive Multimedia”, in Proceedings of
ACM International Conference on Multimedia 1994.
ミドルウェア MiRAGe を CORBA から Ice へ移
植した経験を述べた．評価においては，移植経験に
基づく定性的な評価と，ソースコード量やバイナリ
[5] S Lo, S Pope, “The Implementation of a High Performance ORB over Multiple Network Transports”,
in Proceedings of Middleware 98, 1998.
の大きさ，通信オーバヘッドなどの比較することに
よる定量的な評価を示した．実際の移植を通じて,
Ice が持つ学習容易性や，実装負荷の軽減といった
[6] T.Nakajima, H.Ishikawa, E.Tokunaga, F. Stajano,
“Technology Challenges for Building Internet-Scale
Ubiquitous Computing”, In Proceedings of the
Seventh IEEE International Workshop on Objectoriented Real-time Dependable Systems, 2002.
多くの優位性を認めることが出来た．これらの優位
性は，今後の MiRAGe の拡張においても大きな利
益をもたらすであろう．さらに，コード生成や通信
–9–
[7] E. Tokunaga, A. van der Zee, M. Kurahashi, M.
Nemoto, and T. Nakajima: “A Middleware Infrastracture for Building Mixed Reality Applications in
Ubiquitous Computing Environment”, in Proceedings of The First Annual International Conference
on Mobile and Ubiquitous Systems: Networking and
Services (Mobiquitous2004), August 2004
[8] 徳永英治, A. van der Zee, 倉橋誠, 根本将寛, 中島達
夫: “ユビキタス環境における複合現実感のためのミド
ルウェア”, 日本ソフトウェア科学会コンピュータソフ
トウェア Vol.21, No.1, 2004 pp.27-45
[9] M. Weiser, “The Computer for the 21st Century”,
Scientific American, Vol. 265, No.3, 1991.
–10–

Download Report