先進DIコンテナ「Apache Geronimo」、「HiveMind」を試す

Apache GeronimoとHiveMind

　筆者らは、月刊JavaWorld 2005年10月号の特集1として『DIコンテナ完全ガイド』という記事を寄稿した。この記事では、DI（Dependency Injection）コンテナの基本的な仕組みや使いこなすうえでの留意点、現在主に使われているSpring Framework、Seasar2の使い方、またDIコンテナをベースにして開発したアプリケーションにおける単体テストの方法、さらにDIコンテナの先進的な活用法などを紹介している。本記事では、この『DIコンテナ完全ガイド』の“姉妹記事”として、『DIコンテナ完全ガイド』の87ページでも紹介しているApache Geronimo（以下、Geronimo）とHiveMindについて、少し掘り下げて解説する。

　GeronimoとHiveMindは、いずれもアパッチ・ソフトウェア・ファウンデーション（ASF）で開発されているプロダクトであり、昨今のソフトウェア業界におけるASFの影響力の大きさを考慮すると、注目に値する存在だ。まだ実用段階に達しているとは言い難いが、どちらも先進的なアーキテクチャを採用しており、今後のDIコンテナの動向を占ううえで極めて重要なプロダクトだと言える。

　なお、本稿では、DIコンテナの基本事項などには触れないが、それについて知りたい方は、『DIコンテナ完全ガイド』をご覧いただきたい。

Apache Geronimo

　Geronimoは、オープンソースで開発されているJava EE（J2EE）対応アプリケーション・サーバである。

　Geronimoの特徴は、それ自身はアプリケーション・サーバとしての最低限の機能しか備えず、他の機能を各Java EE仕様（EJB、JMS［Java Message Service］など）のオープンソース実装をコンポーネントとして組み合わせて利用することでカバーし、Java EEのすべての機能を満たそうとしている点だ。例えば、EJBコンテナとして「OpenEJB」、JMSサーバとして「ActiveMQ」を採用している。

　Geronimoの開発作業は精力的に行われており、今年6月30日にはJ2EE 1.4のTCK（Technology Compatibility Kit：技術互換キット）によるテストに無事パスし、仕様上は完全なJ2EE 1.4対応アプリケーション・サーバとなった。現在は、実用に堪えるよう、完成度を高める作業が行われている。

GBeanとKernel

　上述したように、Geronimoのコンセプトは、OpenEJBなどのサーバ・プロダクトを組み合わせてアプリケーション・サーバを実現することにある。このため、Geronimoでは「マイクロカーネル」という概念を取り入れている。

　マイクロカーネルとは、OSで使われている技術で、OSとしての必要最低限の機能だけをコアとして用意し、それ以外の機能はサブシステムとして分離するというものである。これにより、新たなサブシステムの追加による機能拡張などにも柔軟に対応できるのだ。

　Geronimoのコアを成すのは、Kernel（org.apache.geronimo.kernel.Kernel）と呼ばれるオブジェクトである。このオブジェクトに、各コンポーネントが登録されるわけだ。ここで重要なのは、コンポーネントをGeronimoに統合する際、クラスKernelの側でも、またコンポーネントの側でも、コードの修正は一切必要ないということである。これにより、個別に開発されている各プロダクト（コンポーネント）のバージョンアップに追随するのが容易となる。では、Geronimoでは、こうした柔軟性をどのようにして実現しているのだろうか。以下、それについて説明しよう。

JMX／DIコンテナによるコンポーネント管理

　Geronimoが柔軟な機構を実現するために利用しているのが、JMX（Java Management Extensions）とDIコンテナの技術である。

　JMXとは、ネットワーク上のハードウェアやソフトウェアを監視するための仕組みで、いわば“Java版SNMP”とでも呼べるようなものだ。図1に示すのは、JMXのアーキテクチャである。

図1：JMXのアーキテクチャ

　JMXでは、監視対象（サーバ・コンポーネント）ごとに「MBean（Managed Bean）」と呼ばれる管理コンポーネントを用意し、MBeanの管理を行うMBeanサーバにそれを登録する。一方、監視者のほうは、リモート・クライアント（管理クライアント）から、各種プロトコルを実装したアダプタを通じてMBeanにアクセスする。MBeanはリモート・クライアントのエージェントとして動作し、監視対象の情報を得たり、情報を設定したりするわけだ。

　また、MBeanサーバは、監視対象の状態をMBeanに通知する機構を備えており、この仕組みを利用して監視者にイベント通知が行える。なお、JMXをJava EEに適用するための基本モデルは、2002年に策定されたJSR 77（J2EE Management API）で規定されている。

　Geronimoでは、JMXのMBeanを拡張した「GBean」という機構を採用している。図2に示すのは、GBeanを使用するGeronimoのアーキテクチャである。

図2：Geronimoのアーキテクチャ

　この場合、各コンポーネントがKernelに登録するのは、MBeanに当たるGBeanとなる。GBeanには、特定のインタフェースを実装する必要はなく、POJOとして作成してもよいが、Geronimoが提供するインタフェースorg.apache.geronimo.gbean.GBeanLifecycleを実装することで、Geronimoサーバのライフ・サイクル（起動、停止など）を制御することが可能となる。これをトリガーとして、各コンポーネントの起動、停止を行うわけだ。

　Geronimoのカーネルは、GBeanを対象とするDIコンテナの機構も備えている。そのため、あるGBeanに対し、他のコンポーネントへの依存性（参照）を設定（注入：Injection）することが可能だ。つまり、各コンポーネント（プロダクト）は、GBeanを通じて依存する他のコンポーネントと連携できるのだ。このように、Geronimoとの統合に必要な部分をGBeanとして外部化することで、元のコンポーネントの変更を行わずに済ませているのである。

　また、GBean自体はMBeanを拡張したものであるため、JMXの機能をすべて利用することができる。配備されたコンポーネントをJMXの管理コンソールを使って管理することも可能だ。

　なお、今後GBeanの機構を独立させていこうとする動きがある。GBeanの機構そのものはアプリケーション・サーバだけを対象とするわけでなく、サーバ・プロダクト全般で利用できる。そこで、CodehausのGBeanプロジェクトでは、Springとの統合を目指した作業が行われる予定となっている。将来的には、SpringがGeronimoのDIコンテナとして採用される可能性もある。

　ちなみに、GeronimoのDIコンテナには、AOP（Aspect Oriented Programming：アスペクト指向プログラミング）機能は搭載されていない。AOP機能もコンポーネントの1つととらえ、この部分は外部プロダクトを導入すればよいと考えているためだ。Geronimoの最新版であるバージョン1.0 M4（Milestone 4）には、AOPフレームワークとして「AspectWerkz」が搭載されている。