先のGlassFish v3「Prelude」(リンク)（SunによるOSGiベースのJava EE 6サーバ）の発表により、企業全域にわたるOSGiの使用がほとんどすべてのバックエンドサーバをカバーするよう拡大した。OSGiアライアンス(リンク)のプレスリリース(リンク)には、OSGiを利用するベンダーと技術の一覧が載っている。
- IBM(リンク)のWebSphere(リンク)
- Oracle(リンク)のWeblogic(リンク)
- Paramus(リンク)のInfiniflow Service Fabric(リンク)
- ProSyst(リンク)のModuleFusion(リンク)
- レッドハット(リンク)のJBoss(リンク)
- SpringSource(リンク)のSpringSource Application Platform(リンク)
- サン・マイクロシステムズ(リンク)のGlassFish Enterprise Server(リンク)
Peter Kriens氏が指摘しているが(リンク)、OSGiベースとしてはおそらく初のJEEサーバであるJonas(リンク)は、OSGiメンバーではないため、このリストに入っていない。氏はまた、SAP NetWeaver(リンク)も将来はOSGiに向かうだろうと指摘している。
InfoQが以前お伝えしたように(参考記事)、こうしたシステムがOSGiに向かう主な理由は、より優れたモジュール性を可能にするためである。これによりシステムは、より管理しやすい（かつテストしやすい）ように分解され、それと同時に、コンポーネントライブラリの再利用拡大が可能になる。今のところ、大物企業（IBM、Oracle）は内部的にOSGiを使い、アプリケーションのユーザーには直接公開していないが、他の参加者（SpringSource）は、アプリケーションだけではなく、コンテナ自体も拡張できるという事実の上に構築している。
Maven(リンク) を使って構築したプロジェクトも同様にコンポーネント化でき、このモジュール化の特徴の上にOSGiが何を追加するのかと思いめぐらす人もいるだろう。Mavanのモジュール化とOSGiのランタイムの間には重要な相違点が2つある。
- Mavenの依存性では、依存先は特定のアーチファクトである。OSGiはランタイム時に発見した任意のアーチファクトからJavaパッケージをインポートできる
- Mavenがビルドタイム的性質を持っているということは、ランタイム動特性のレベルを必然的に伴わないことを意味する
SpringSourceのDMサーバ(リンク)のようなアプリケーションサーバは、OSGiコンテナ内にSpringのbeanをデプロイする際にOSGiの動特性を利用し、ランタイム時のサービス停止と再開を可能にする。Spring Dynamic Moduleフレームワークは、ワイヤリングとランタイムを透過的にこっそりと処理する。
オープンソースプロジェクトもOSGiへと向かっている。Apache Felix (リンク)OSGiサーバに刺激され、他のApacheプロジェクトがビルド内でOSGiメタデータを生成したり、あるいは最近Apache Tuscany(リンク)に見られた動きのように(リンク)、完全にOSGiへ向かったりしている。ソースでメタデータを作成しないオープンソースプロジェクト向けとして、多数のOSGiバンドルリポジトリ（SpringSource Enterprise Bundle Repository(リンク)、OBR(リンク)、Eclipse Orbit(リンク)、Felixのバンドルリポジトリ(リンク)など）が存在し、OSGiメタデータの注釈を付けたオープンソースのJarを提供する。
OSGiが発展した結果、Webベースのシステムとバックエンドのシステムの両方がOSGi上に直接構築されている。 Linked In(リンク)のOSGi使用については、エンジニアリングブログで論じられており(リンク)、コロラド・ソフトウェアサミット2008におけるプレゼンテーションのコピー(リンク)を閲覧可能である。Amaon EC2やiPhone 上でさえ (リンク)、OSGiのサービスを実行可能である。
直接的、間接的を問わず、企業アプリケーション内でOSGiを使う可能性が高くなっている。Springフレームワークがアプリケーション開発のデファクト標準となりつつあり、Spring DMサーバのメリットである、モジュール式の動的なアプリケーションの構築という方向へ、業界は進んでいる。
原文はこちらです：http://www.infoq.com/news/2008/11/osgi-in-the-enterprise