2月9日および10日の2日間、目黒雅叙園においてDeveloper Summit 2006(通称デブサミ2006)が開催されている。本稿ではその初日のセッションの1つである「Apache Geronimo ハッキング」の様子を紹介する。講師は日本IBMの夷藤勇人氏で、Apache Geronimoの開発プロジェクトやアーキテクチャについての解説が行われた。

なぜApache Geronimoか

「Apache Geronimo」はApache Software Foudationによってオープンソースで開発が進められているJavaアプリケーションサーバで、2005年6月にJ2EE 1.4の認定を取得、今年1月に正式版であるVersion 1.0がリリースされたばかりの比較的新しいプロダクトである。Apache Geronimoの開発プロジェクトは2003年8月に開始されているが、この時点ですでに「JBoss」というオープンソースのJavaアプリケーションサーバが公開されていた。なぜこのとき新しいアプリケーションサーバが必要だったのか、Apache Geronimoのどこが他のオープンソースのアプリケーションサーバと異なるのか。セッションの話題はまずその部分から始まった。

これまでのGeronimoのリリース

夷藤氏によると、Apache Geronimoが他のオープンソースアプリケーションサーバと異なる最大の点は、そのライセンス形態がApache Software Licenseであることだという。オープンソースライセンスとして実績のあるライセンスはいくつかあるが、Apache Software Licenseはその代表格の1つと言えるだろう。対するJBossはLGPL(Lesser GNU Public License)を採用しており、こちらも実績としては申し分ないライセンスと言えるが、ソースコード改変後の開示に関する部分などでApache Software Licenseに比べると自由度が低い。些細なことのように思えるかもしれないが、業務としてオープンソースプロダクトを採用する場合などには重要な問題である。

Apache Geronimoのもう1つの大きな利点は、他のオープンソースプロジェクトによる成果物を積極的に取り込んでいる点だという。「車輪の再発明はしない」というのがApache Geronimoプロジェクトのコンセプトだそうで、アプリケーションサーバの構成に必要なAPIがすでにオープンソースプロダクトとして公開されているならば、それを積極的に採用することで新たに開発するコストを削減する。これによって各分野で実績のあるプロダクトを活用することができる上、各々は独立したプロジェクトによって開発が進められるというメリットがある。

実際、Apache GeronimoではWebコンテナの実装としてApache TomcatやJetty、EJBコンテナの実装としてOpenEJB、メッセージングの実装としてActiveMQ、Webサービスの実装としてApache AXISなどが採用されている。Apache Geronimoに取り込まれたプロダクトを見ると、Apache Software Foundationによるものの占める割合が高いが、Geronimoプロジェクトとしては特にどのグループによるものかにこだわらず、広くコラボレーションしていく考えとのことである。

Geronimoに採用されたプロダクトの例

Apache Geronimoのアーキテクチャ

さて、Apache Geronimoが様々なオープンソースプロダクトから成るアプリケーションならば、全く異なるプロダクトをどのような仕組みで統合しているのだろうか。夷藤氏は続いて具体的なGeronimoのアーキテクチャの解説を行った。

当初のアイデアでは、JMXを中心としたアーキテクチャによって様々なコンポーネントを統合する仕組みになっていたという。しかし、この方法ではコンポーネント同士の依存関係が強くなってしまい、ロジックの統合を柔軟に行うことが困難であるという問題が生じた。

そこで、現在のGeronimoではDI(Dependency Injection)を利用することでコンポーネント間の依存性をできるだけ無くし、柔軟なアーキテクチャを実現している。具体的には、Geronimoカーネル自身がDIコンテナとなって様々なコンポーネントを統合することで、ライフサイクルの管理や依存性の解決を行っている。特徴的なのはGeronimoの中のサービスやアプリケーションの全てを「GBean」として管理する点である。GBeanはJMXにおけるMBeanのような存在で、Geronimoによって統合されるサービスやアプリケーションはGBeanをGeronimoカーネルに登録する。DIコンテナであるところのGeronimoカーネルは、GBeanを通じてコンポーネントに依存性をInjectionできる。この仕組みによってGeronimoカーネルは統一的な方法で様々なコンポーネントを管理できるようになっている。

GBeanによる管理に加えて特徴的なのが各コンポーネントの配備を「モジュール」という単位で行う点で、Geronimoの設定はモジュール単位で用意することができるようになっている。例えばWebコンテナやEJBコンテナ、JMSサーバなどがそれぞれ別々のモジュールとして配備される。設定は「Deployment Plan」と呼ばれ、XML形式のプランファイルに記述される。したがってDeployment Plan次第でオーダーメイドのアプリケーションサーバを構築できるようになっている。

Apache Geronimoの目指すもの

夷藤氏がApache Geroimoについて強調したのは、「Apache Geronimoは単なるJ2EEサーバではなく、様々なオープンソースプロジェクトを統合できるフレームワークである」という点だった。

Geronimoのアーキテクチャを利用すれば様々なプロダクトを柔軟に結び付けることが可能である。Apache GerominoプロジェクトとしてはJ2EEのフルスタックとして配布しているが、実際にはJ2EEの仕様にとどまらず、もっと広い範囲でのアプリケーション統合のインフラになる力を持っているという。

これについて夷藤氏は、Geronimoの貢献者の1人でありGluecode SoftwareのCTOでもあるJeremy Boynes氏の次のような台詞を紹介した。

"Don't think of Geronimo as just another J2EE server but as the start of a system framework that can be used to build a whole variety of tailored infrastructure services."

Apache Geronimoを使う

セッションでは実際にApache Geronimoを実行してみるデモも紹介された。Apache Geronimoにはコンソールベースの管理プログラムが多数用意されており、アプリケーションサーバの起動だけでなくモジュールの配備やデータソースの定義などといったこともコンソールから行うことができる。また、Geronimo Server ConsoleというWebベースの管理コンソールも付属するという。

Apache Geronimoを使用したアプリケーションを開発する場合には、プロジェクトとしては統合開発環境としてEclipse WTP(Web Tools Platform)を推奨しているらしい。オフィシャルからEclipse WTP用のプラグインも公開されていて、Eclipseに慣れたユーザならばすぐにでも開発に着手できるだろう。

今後の展望

最後に、Apache Geronimoの今後について気になる点を2つほど質問してみた。

1つは開発環境についてのこと。Eclipse WTP用のプラグインはオフィシャルで公開されているという話だったが、それに対してその他の統合開発環境、例えばNetBeans用のプラグインなどが提供される予定はあるかということだ、しかし、そのような話は今のところ出ていないという。NetBeansも5.0でプラグインが作成し易くなっているので有志による開発が行われないとも言いきれないが、当面はGeronimoを使用するならばEclipseを選択するのが賢明なようだ。

もう1つはJava EE 5への対応について。これについてはプロジェクト内でも話が持ち上がっており、実際にEJB 3.0対応の開発はスタートしていて、いずれはJava EE 5の認定を取得したいという意向のようである。ただし、現段階ではEJBコンテナとして採用しているOpenEJBがJ2SE 1.4までしか対応しておらず、当面はJ2SE 5.0への対応およびその他の機能面の充実が目標になるだろうという話だった。

Apache Geronimoプロジェクトでは、これまでバージョン1.0のリリースを第一の目標として開発を進めていた。1月にそれが達成されたので、今年はGeronimoにとって大きな飛躍の年になるだろうと夷藤氏は言う。たしかに、それを予感させるだけの魅力がGeronimoにはあると感じられる。同氏は最後に、「Ride on Geronimo!」という言葉で講演を締めくくった。