サーバサイドにおけるOSGiの概要

Daniel Rubio著
2008年1月23日（翻訳記事2008年2月29日）

要約

1999年に設立されたOSGiアライアンスは、組み込みデバイス分野で初めてJava市場に参入しました。数年でJavaデスクトップ プロジェクトの事業範囲を拡大し、EclipseオープンソースIDEプロジェクトのモジュール化と拡張性をサポートする重要な基盤を築き上げました。現 在OSGiは、サービス時代の到来に合わせて「サーバサイド」という最新のJavaフロンティアに取り組んでいます。

技術業界の他の多くのアライアンスと同様に、OSGiのベストプラクティスと開発ポリシーは多くのメンバー企業のコンセンサスによって決まります。 OSGiのサーバサイドへの参入に伴い、大手Javaベンダの多くがOSGiの青写真に合わせたSOA製品ラインのシフトを既に開始しています。BEA も、microService Architecture（mSA）のバックプレーンコンポーネントをOSGiに依存しています。

この記事では、OSGiがJava／SOAサーバサイドイニシアチブを開始した理由について説明し、JavaベンダがSOAソリューションを OSGiベースにシフトした場合の主な利点と制約について触れ、開発者やアーキテクトの視点からOSGiと連携した場合に得られる具体的なメリットについ て詳しく紹介します。また、プラットフォームという大きな枠組みで見た場合のOSGiのJavaに対する将来的な役割についても考察します。

OSGiの主なコンセプト

OSGiの方針のほとんどがスマートフォンからIDE（統合開発環境）まであらゆるシステムに適用されるに至っているため、OSGiのすべての側面 を簡潔にまとめることは困難です。しかし、以下に挙げる主なコンセプトから、JavaエコシステムにおけるOSGiの全体的な位置付けを把握することがで きます。

  • 環境とフレームワーク：多くの場合、OSGiはJavaフレームワークとして分類されますが、Javaの世界で多用されるこの 言葉だけでOSGiを判断するのはやめてください。OSGiは、Java Web開発からJavaテストまでのあらゆる作業の簡素化をサポートする多くのフレームワークの1つというわけではありません。OSGiはこうした境界を 越え、モジュール化を促進してコンパクトで管理性の高いアプリケーションを構築するための一時的な 環境を効果的に提供します。
  • JVMコンパニオン：OSGiのルーツは埋め込み市場です。このため、OSGiがJavaにおける最も基本的なシス テムであるJava仮想マシン（JVM）の機能強化を第一の目的としているのは自然なことです。JVMに関しては、システムサービスや動的ローディングな ど特定のタスクに対して10年以上エンジニアリング作業が積み重ねられてきましたが、一部の垂直市場では期待したほどの成果を得られず、OSGiなどのイ ニシアチブがその機能的なギャップを埋める役割を担っています。
  • Javaパッケージバンドル：環境やフレームワークには独自のパッケージモデルが欠かせません。このため、 Java EEアプリケーションを操作するときにWAR（Webアーカイブ）やEAR（エンタープライズアーカイブ）を使用するように、またはJavaプロジェクト でより汎用的なJAR（Javaアーカイブ）を使用するように、OSGiでも「バンドル」という名前の独自のパッケージモデルを使用します。バンドルの構 成要素については後述するのでここでは詳しく述べませんが、OSGiが「バンドル」という用語と密接に関係していることを覚えておいてください。

この用語は、OSGiをより大きな視野で理解するためのヒントとなりますが、これも氷山の一角にすぎません。ここからは、OSGiがサーバサイドの世界に何をもたらすかについて説明します。

サーバサイドにおけるOSGi：SOAと複雑性

サーバサイドのJava市場における現在の状況を見ると、企業においてサービス指向アーキテクチャ（SOA）の有効化へのシフトが進んでいることが 分かります。このシフトを劇的な変化と捉えるか、自然発生的な進化の段階と捉えるかは賛否両論ありますが、SOAがアプリケーションの開発および展開に新 たな考え方を持ち込んだことは否定できないでしょう。この結果、こうしたアーキテクチャを支えるためのインフラストラクチャも同様に再検討されることにな りました。

SOAを有効にするために企業で使用されているインフラストラクチャを見ると、Java EEコンテナと軽量なフレームワーク、さらにこの目的で開発されたその他のミドルウェアが混在していることが分かります。このインフラストラクチャ自体は 悪くありませんが、こうしたソフトウェアの展開方法がモノシリック（一枚岩的）でオール オア ナッシング（100％できるかまったくできないか）式のアプローチを生み出しています。そして、こうしたアプローチがSOAの俊敏性と再利用性という特性 を部分的に妨げています。

ほとんどのJavaアプリケーションは容易に個別管理が可能です。実質的な問題は、単純に見えるこうしたピースを他のJavaパーツとともに実運用 環境や企業内のサービス指向「クラウド」に配置したときに初めて発生します。このようなシナリオでエンタープライズJavaミドルウェアとJVMが稼動す るのは、前述のオール オア ナッシング式のアプローチに則っているからであり、結果としていくつかの問題が発生します。

  • 肥大化するメモリフットプリント：一部のJavaアプリケーションを企業向けの設定で展開して稼動させるには、1GB～2GBまたはそれ以上の膨 大なメモリが必要になります。このため、サーバサイドでは、単一のサーバインスタンスで展開しなければならないアプリケーション数の増加に伴い、リソース のブラックホールが発生します。
  • クラス／バージョン管理の競合：ソフトウェアピースが進化すると、このようなシナリオでは別の問題が発生します。すべてのピースが 同じ傘（JVMおよびクラスパス）の下にロードされるため、単一のサーバインスタンスで展開するアプリケーション数が増えると、アプリケーションが異なる ステープルライブラリ（JARファイル）を使用する可能性が高まります。結果的に、クラスローディングとバージョン管理の競合が発生します。
  • 重複するパーツまたは不要なパーツ：すべてのアプリケーション所有者は、アプリケーションを正常に実行するために必要な依存関係を 準備します。しかし、アプリケーションを実運用環境に展開すると、特定の依存関係が他のアプリケーションによってすでに満たされていないかどうかの判断 や、作成者が意図した依存関係をアプリケーションが実際に100パーセント使用しているかどうかの判断を行うことが非常に困難になります。

こうした問題の共通の解決策と考えられるのが 動的ローディングです。これによりアプリケーションの構成要素をすばやく判断できる ので、リソース消費を正常な動作に最低限必要なピースにのみ制限できます。OSGiは慢性的なリソース不足に悩まされている埋め込み市場で実績を積んでき たことからも分かるように、必要に応じてモジュールのインストール、開始、停止、更新、およびアンインストールを行える非常に効率的な方法を確実に提供す ることができます。

OSGiはこの手法により、こうした動的ローディングやバージョン管理機能に欠けているJVMと、依存関係が複雑なために処理が困難な重量級の Javaエンタープライズアプリケーションの間で優れた共生関係を構築します。BEAのmicroService Architectureは、バックプレーンコンポーネントをOSGiに依存しています。つまり、BEAの製品ラインはさまざまなOSGiバンドルを同種 環境で使用しています。このため、各種パーツ間のインタフェースが効果的に機能し、BEA製品の全ラインナップを展開したときに発生する可能性のあるバー ジョン管理とクラスローディングの競合を防ぐことができます。

ここまでの説明で、OSGiを使用するメリットが少しお分かりになったと思いますが、OSGiが解決しようとしていることを把握するにはさらに鳥瞰 的な見方が必要です。次のセクションでは、OSGiを支える稼動部分の構成要素、すなわち環境とそれに対応するバンドルについて見ていきましょう。

Pages: 1, 2, 3

Next Page »