JBoss and OSGi

Mark NewtonがAles Justinに対して実施したインタビューがJBoss.orgに公開されています。面白い内容なので最初のさわりだけでも紹介したいと思います。

Mark
JBoss研究開発部門ではここのところ新しいOSGi実装に取り組んでいますが、その目的は何ですか？

Ales
最初の目標はOSGiベースのクラスローダを持つことです。これは最初にの実行時サービスのために作成され、後に、OSGiエンタープライズ専門グループ（EGG）の活動に沿って、アプリケーション開発者のために同じものを導入する計画です。第二の目標は完全なOSGiコア仕様v4.1実装を作ることです。JBossマイクロコンテナ（MC）がすでにOSGiのコア機能を実現しているおかげで、この試みは容易に実現されます。さらに、我々は新しいOSGi EGGの「コンポーネントモデル」をサポートします。最後に、JBoss AS 5はすでにプロファイルというコンセプトを持っているので、我々のProfileServiceでOSGi Bundle Repository(OBR)を使うように統合します。

現在、Javaのクラスのインストールや管理は問題が多いです。Red HatのRPMやDebianのaptと比較してみてください。Java言語が提供するのは、クラスパスという概念とクラスローディングの低レベルな制御機能だけです。クラスのバージョン管理、クラス間の依存関係の管理を「パッケージ」単位で行うのは容易ではありません。特にアプリケーションサーバーのように、システムクラスとミドルウェアのクラス、複数のアプリのクラスが混在する環境では、クラス管理のトラブルはさまざまな形で現れます。

OSGiはパッケージ単位でのクラスローディングを制御できる仕組みを提供してくれるのでこのような問題を改善してくれることが期待できます。クラスローダ階層で、下位のクラスローダに対して、特定のクラスを見せないというVisibilityのコントロールや特定のバージョンへの依存性を明記することができます。これより、OSGiのモジュールをJVMにロードしても、ロード済のアプリと安全に共存できるようになります。OSGiは最初は組み込み機器に実行時にサービスをロードするために策定されたものなので、動的にネットワークからJVMにロードする仕組みを備えています。さらに、OSGiではこのようにしてロードしたサービスを手動で停止したり、開始したりすることができます。

JBossに話を戻しましょう。JBoss5ではプロファイルサービスというものが導入されます。これは、JBoss4までminimal/default/allでお馴染みのConfiguration Setを汎用的にしたもので、環境設定やデプロイ設定を「プロファイル」として管理できるようにします。このプロファイルサービスでは、OSGi Bundle Repository(OBR)と同じインタフェースで作られます。プロファイルサービス上では、OSGiバンドルとして提供されたJBossサービスを開始・停止できるようになるのでしょう。デプロイしたものを停止ができるということは、WindowsやLinuxのサービスでは当たり前ですが、これがアプリサーバーレベルのサービスで可能になるのです。

Mark
なぜ、すでにあるOSGi実装を利用しないのですか？

Ales
現在のOSGiサービスレジストリには我々が必要とする機能が足りません。細かな粒度の依存性、AOPとの統合、既存のJMXをサポートすること、スコープ付メタデータ、Open MBeans、Virtual File System (VFS)、汎用デプロイヤなどです。もし、現存する実装にこれらの機能を追加したなら、全部を統合するのは最初から開発するのと同じくらいの努力が必要となるでしょう。それに、我々自身の実装を作り上げることで、我々のアプリケーションサーバのコア部分、すなわちカーネルに対して最大限のコントロールを保証します。

我々はおそらく現存するOSGiフレームワークのクラスローディングを使うことができたでしょうが、それは前に述べたように無理やり動かすように物事を捻じ曲げてしまうことになるのです。我々は頑丈な実装を持ちたかったので、private/protected修飾子の背後に汚い詳細を隠せるように、ポリシーやデリゲーションを介してしっかりと制御できることが重要でした。この観点から、我々自身のクラスローディング層を実装することが道理にかなっていたのです。リソース参照のようなこともVirtual File Systemを使って実装できます。VFSはデプロイの場所や構造（パッケージされているか、展開されているか）にかかわらずアクセスできるようにしてくれるのです。

JBossマイクロコンテナは、このOSGiのクラスローダを作るためのコアとなる機能が組み込まれていますので、マイクロコンテナのFacadeとして、JMXだけでなく、OSGiもサポートすることができます。汎用OSGiフレームワークの上にアプリケーションサーバーを構築するというアプローチではなく、マイクロコンテナ自身がカーネルとそれに組み込まれるプラグインコンポーネントの集合体として構成されています。

JBossマイクロコンテナのソースを眺めるとすぐに気が付くのですが、ソースはSPIとAbstractクラスだらけで、FactoryパターンやVisitorパターンがいたるところで使われています。JBoss Deployment Frameworkは、一枚岩ではなく、多くの種類のコンポーネントが複雑に絡み合ってできています。Virutual File Systemとは、JARや、JARを展開したディレクトリを区別なく扱えるようにする抽象化レイヤです。なんと、VFSを使えば、メモリ上にアーカイブを作ってマイクロコンテナにデプロイすることもできます。これはUTに便利そう。

AssembledDirectory jar = AssembledContextFactory.getInstance().create("ejbTestCase.jar");
jar.addClass(Customer.class);
jar.addClass(CustomerDAOBean.class);
jar.addClass(CustomerDAOLocal.class);
jar.addClass(CustomerDAORemote.class);
jar.mkdir("META-INF").addResource("tutorial-persistence.xml", "persistence.xml");

Bootstrap.getInstance().deploy(jar);

JBossマイクロコンテナ、OSGi、プロファイルサービス。なかなか手ごわいですが、それらが目指す将来のサービス管理は非常に魅力的です。なぜなら、JBossの利点でもあり欠点でもあるUnified Class Loaderを補完し、サービスの動的インストールと安定稼動を可能にするからです。今回のインタービューに登場する2人は（私のお気に入りの）JBoss Microcontainer User Guideの著者でもあります。今後のこの2人の活躍に期待しています。