アプリケーションのモジュール化のためのOSGi - ある企業の設計選択

OSGi は、Java ベースのサービスプラットフォームの仕様であり、長時間実行、動的更新、および実行環境への配布を最小限に抑えることを必要とするシステムでの使用を目的としている。これまでの説明の多くは、ツールベンダ (Eclipse が最初)、およびアプリケーションサーバーベンダ (IBM、BEA、Oracle) による OSGi の採用に関するものだった。これらのベンダは、OSGi を使用してマイクロカーネルやプラグインのアーキテクチャを作成することで、適切なモジュール化と、実行時の動的な組み立てを可能にしている。しかし、今後OSGi が開発者に最も大きな影響を与えるのは、アプリケーション開発のためのより適切なコンポーネントモデルとしての分野だろう。JSR 291 (OSGi のコア仕様 R4.1) では、次のように説明されている。

 既存の Java SE プラットフォームのコンポーネントライフサイクルを含めた、動的コンポーネントフレームワークを定義します。この動的コンポーネントモデルは、コンポーネントからのアプリケーションの組み立て、コンポーネント間での実装の詳細の隠ぺい、およびこれらのコンポーネントのライフサイクル管理をサポートします。

OSGi は、Java 開発にとって、コンポーネント開発を実現する最適なツールとなるであろうか。InfoQ では、OSGi を基盤としてアプリケーションアーキテクチャの次期バージョンを作成することを決定した企業に、なぜ OSGi を選択したのかを聞いた。BPS は、リスク管理ソフトウェアを販売する ISV であり、内部監査、およびコンプライアンス関連のビジネスプロセス (サーベンスオクスリー法 404 条など) に対応しようとする組織を支援している。BPS の製品は、主に、制約が厳しく IT 環境への要求が高い大手金融機関で使用されている。InfoQ は、BPS の チーフアーキテクトである Gavin Terrill 氏に、OSGi を次期アーキテクチャに採用した理由を質問した。Gavin 氏は次のように説明している。

私達は、これまでに何回も、同じ VM の中で 1 つのサービスの複数のバージョンを並行稼動させるにはどうすればよいかという問題に直面してきました。このシナリオはこうです。A および B という 2 つのアプリケーションがあり、それらは私達のアプリケーション C に統合されています。C の最初のデプロイの後、A の次のリリースをサポートする機能が追加されます。ここから問題が始まります。デプロイしたアプリケーションを新しいコードで更新する必要がありますが、サーバーを再起動することは許されません。また、B との不整合が生じることも許されません。OSGi は、ソフトウェアコンポーネント (バンドル) を動的に提供し、バージョンを管理する機能によって、このような問題を解決します。
 
もう 1 つの目的は、コードベースにサービス指向的なアプローチを採用することです。ここで、サービス指向「的」としていることに注意してください。私達は、疎結合、関心の分離、および局所的テストなどの利点は活用したいと思いますが、これらと一緒に、アウトオブプロセス、ala Jini、または DPWS (nee UPnP) の複雑性まで取り入れるつもりはありません。私達の製品構築は、既にこのような考えに従っています。Java のインターフェイスの長所を余すところなく活用し、その実装は Spring Framework の依存性注入の方法を使用してプラグインすることができます。このような方法も、軽量な手法でサービスをよりモジュール化できる OSGi によって、さらに次の段階へと進むことになるでしょう。

OSGi が、一般的な EAR/WAR ファイルのアプローチよりも優れた選択肢と判断された理由を、Gavin 氏は次のように述べている。

既存のメカニズムが本質的に悪いというわけではありません。ただ、EAR/WAR のデプロイはおおざっぱ過ぎて実用に耐えるものではないと感じています。1 つの jar ファイルしか触っていないのに、アプリケーション全体をリロードする必要がなぜあるのでしょうか。
 
Java アプリケーションのデプロイについては、.jar ファイルの導入から JSR 277/294 に至るまで、Java コミュニティの中でも活発な議論が行われています。Java Module System (JSR 277) は、Java SE 7 と一緒に登場する予定であり、関心が集まってきています。一見すると、これは.Net アセンブリの考えに相当するものとも思えますが、OSGi の Eclipse (およびその他) における実績を考えれば、それ以上のものであることは明らかです。実際の現場で発生する数々のデプロイの問題を解決してきたものに対抗するのは難しいでしょう。

OSGi の設計概念は、私達の要件に合っています。軽量、インプロセス、サービスコンテナフレームワーク、そして完全なライフサイクルサポートです。

BPS は、既に Spring ベースのアプリケーションを作成しているので、アーキテクチャ変更の中で Spring-OSGi を使用する予定である。Spring-OSGi は、最初のマイルストーンが最近リリースされている。

OSGi に関してのアーキテクチャ変更は、BPS にとって大きな賭けとなる。Gavin 氏は次のように考えている。「2004 年にも、BPS は製品のアーキテクチャを変更するという賭けをしています。Spring Framework は、より確立されている EJB のアプローチに比べてリスクが高いと考えられていました。この賭けは、開発者および顧客のフィードバックから判断して、完全な勝利でした。OSGi も、早期導入であるという点では似ています。私は、数年後、IT フレンドリなサービス指向のエンタープライズレベル Java アプリケーションのアーキテクチャとして OSGi がデファクトスタンダードとなることを信じています。」

OSGi は、組織においてコンポーネント指向ソフトウェア開発を促進するアーキテクチャの資産となることもできる。InfoQ では、昨年11 月に、Piero Campanelli の分析から次のようなメリットがレポートされている。

• 真のコンポーネント開発 - 概念は単純ですが、ソフトウェアのコンポーネント化は実用としては困難である場合がある。OSGi の構造は、依存性の追跡、バージョンの追跡、およびサービスの結合といった問題を対応している。
• チーム全体でのセキュアな開発 - OSGi のマイクロカーネルスタイルは、コンポーネントや拡張の分離と制御を維持するための規則を強制する。
• 企業全体のプロジェクトの標準的な管理 - すべてのプロジェクトを OSGi コンポーネントに分割すれば、それらを簡単に再使用することができる。例としては、Eclipse リポジトリが挙げられる。
• バージョンの追跡 - OSGi は、バージョン管理サポートを提供する。このライブラリを統合できるだろうか、これは他のライブラリのバージョンと不整合がないだろうか、といった不安を解消できる。
• アーキテクトデザイナの支援 - OSGi 内の規則によって、アーキテクトは、全体のビルドを実行することなく、簡単に、ビルドの依存性が破壊されていないかを確認できる。

InfoQ では、OSGi を詳細に説明している。InfoQ.com/jp/OSGi を参照してほしい。

（原文は2007年5月1日にリリースされた記事です）