その比較はEclipse拡張機能レジストリとOSGiサービスレイヤーとの共存によって生じる一般的な混乱における解説から始まる。
Eclipseはバージョン3.0においてOSGiランタイムを採用したので、最初からEclipseの機能であったエクステンションレジストリと、 Eclipseの関与が以前からあったOSGiから来るサービスレイヤーの間に摩擦が存在していました。その摩擦の原因はこの二つのモデルが重複する点が あるからで、また同じような問題を解消するために作られたからです。しかしながら”悪魔はディテールに潜む”のでこれらの二つのモデルは合併するには不便すぎる相違点があったのです。だからEclipseプラグインとRCPアプリケーションのデベロッパはそのどちらかを選択する必要があるのです。Eclipseエクステンションレジストリは各Eclipseプラグイン用のXMLファイル内のエントリ一連に基づいている。Bartlett氏はXMLマークアップが実行可能なJavaを使用したうえで、提供するたくさんの利点を説明した。Eclipse拡張機能に比べて基礎的なOSGiサービスはビヘイビアにいくつか含意のある通常のJavaコードで定義、登録されている。OSGiサービスを解説している間Bartlett氏はEclipse拡張機能と 比較した際に見受けられる実装上の違いと、それに関連したメリットとデメリットに関して説明した。
だから私達が本当に欲しいのは両方の拡張機能とサービスの利点を合体させた何かなのです。サービスのように暗に動的で、でも拡張機能みたいにオンデマンドで作られた何かなのです。理想的にはアプリケーションデベロッパが書かなくてはいけないコードを簡易化してくれるものですね。これは宣言的サービスが埋めるべき空間なのです。Eclipse拡張機能とOSGiサービスは両方とも異なる分野で利点と欠点があるけれど宣言型OSGiサービスは両方のテクノロジからの利点を提供する事を試みるために作成された。宣言型サービスは未だ比較的新しいテクノロジだが、Eclipse3.3のリリース(最近で一番安定したリリースである)において宣言型サービスはEquinoxダウンロードサイトから別途ダウンロードするものとして(source)インキュベータステータス内で有効である。
前述されたOSGiサービスの多様性(サービス、宣言型サービスとSpring-OSGi)と同様に下記のEclipse Extensionsに関する疑問の答えとなる比較基準を用いてその記事の重点が要約されている。
- 何が登録されているのか?
- どのように登録されているのか?
- どのように消費されるのか?
- 濃度はどれくらいなのか?
- 何が搭載されているのか?
- 動的インストール・アンインストールはどのように処理されているのか?
- エクステンション・サービスへのキャッシングリファレンスは問題を引き起こすか?
この記事において私はEclipseスタイルの拡張機能とOSGiスタイルのサービスの強みと弱点を包括的に説明しました。しかしながら私はリーダー達に忘れて欲しくないメッセージは”拡張機能は動的でない”かもしくは”サービスはRCPアプリケーション内で使用できない”というシンプルな事です。その課題はそれには微妙すぎて恐縮ですが、またあなた自身の条件という文脈においては自分自身の評価を作り上げる他ないのです。Eclipse EquinoxとOSGiの関係性における更なる情報はEclipse Equinoxサイトを訪れて欲しい(サイト・英語)。
原文はこちらです:http://www.infoq.com/news/2008/01/eclipse-osgi-comparison