OSGiのビジネス上の利点

作者 Alex Blewitt , 翻訳者 能仁 信亮 投稿日 2010年12月19日

セクション

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ,

デベロップメント

トピック

Java ,

言語 ,

Architecture ,

プログラミング ,

OSGi

共有 |

原文(投稿日：2010/11/30)へのリンク

先日、Paremusは、OSGiのビジネス上の利点に関してブログを投稿した。その中では、モジュール化を巨大なコードベースを管理、メンテナンスしていく方法として論じている。また、このレポートでは、OSGiへの移行を達成する方法を示している。自動ビルドによって、OSGiのメタデータを最初に生成し、OSGiフレームワーク上で動作するように個別のアプリケーションを移行していくのだ。

多くの人は、OSGiへの移行には多額の費用がかかると考えている。しかし、これはモジュール化のコストと一緒くたにして考えられていることが多い。OSGiやJigsaw、もしくは他のモジュール化の方法を使おうとも、巨大かつ複雑で、密に結合したライブラリをモジュール化するには、保守担当者にとって即座には何の利益をもたらさない費用が必要となる。しかし、それをそのまま放置しておくと、時間がたつにつれ、システムはより複雑かつ密結合になり、大きくなってくる。そしてメンテナンス費用が増大するのだ。車はよい状態にたもてるように定期的にメンテナンスをおこなう必要があり、長年ほったらかしにしておくと、エンジンのオーバーホールの費用が、メンテナンスの総コストを超えることもあり、車の寿命を縮めることもあるのとちょうど同じことだ。

Paremusは次のような移行プランを提示している。

1. クリーンナップ
   1. モジュール化の専門家からなる小規模のチームを編成し、マネージメントの支援を保証する
   2. 既存のプロジェクト間の依存関係を分析し、過度で適切でない依存関係を取り除く
2. ツールとメタデータ
   1. OSGiメタデータをサポートするツールとレポジトリをレビューし、利用する
   2. ビルドプロセスの一部として、(OSGiに切り替えないものも含めて)全てのプロジェクトでOSGiメタデータを生成する
3. ランタイム
   1. 俊敏性と再利用性の観点から、移行候補を選定する
   2. 既存のライブラリを粒度のレベルとして、実際に動作するランタイム・バンドルとして作成する
   3. OGSiおよびOSGi以外の実行環境で並行してテストを実行する
4. 繰り返し
   1. OSGiへの移行がいったん完了したら、既存のライブラリにさらなるモジュール化の候補が存在するかもしれない
   2. 共用モジュールに関してレポートする
   3. 後続のアプリケーションの移行を個別におこなう

成功談

OSGiへの移行でのMuleSoftの失敗に関するブログポストに対して、OSGiはアプリケーションサーバとミドルウェア双方にとってすばらしい選択肢だということを何人かのコメント記入者が述べている。

• すべての主要なJavaEEアプリケーションサーバは、OSGiの上で動いている(GlassFish、WebSphere、JBoss)
• SAPはOSGi実行環境としてVirgoを採用している
• WSO2 CarbonはOSGi上でうまく動作している
• Apache Camelは(Muleと同様に)ESBであるが、OSGiの内部、外部どちらでも動作する
• JBossは独自のOSGi実行環境を開発中だ

他の多くのフレームワークと同様に、OSGiを利用したからといって成功が保証されるわけではなく、移行のために、乗り換えやコードの変更などが必要となることも多い。実際のところ、OSGiは万人に適したものではない。しかし、ひとつのプロジェクトに適していなかったことからといって、他のプロジェクトへの適合性には関係がない。CSVを読み取ってデータベースにロードする単体で利用するアプリケーションにOSGiを利用することはないだろうが、そのためにSpringやその他のフレームワークを利用することもないだろう(実際のところ、JavaではなくPythonやPerlをつかった方がよいという人もいるだろう)。

OSGiは、モジュール化を支援し、モジュール間の境界を強制するためのツールとして存在し続ける。プロジェクトが大きくなるにつれ、強力にモジュール化されたシステムを利用することによる価値は、モジュール化のコストを上回る。