Geronimo!: 第1回 J2EE 1.4エンジンへの道

ページオプション JavaScript を要するドキュメントオプションは表示されません 原文はこちら

レベル: 初級

Sing Li (westmakaha@yahoo.com), Author, Wrox Press

2005年 05月 17日

Java ™ ベースのオープンソース開発は、開発者がGUIライブラリーを共有し合っていた初期の頃から大きな進歩を遂げました。Geronimoは、既存のオープンソース・コンポーネントを元にJ2EE 1.4認証されたサーバーを構築しようとする、大規模なプロジェクトです。この、迷路のようなGeronimoを、Sing Liが案内します。2回シリーズの第1回目である今回は、Geronimoがいかに優雅に設計されているか、そしてその大胆なアーキテクチャーについて学びます。

2003年の8月、Apache Software Foundation（有名なApache HTTPサーバーに責任を持つグループ）が、オープンソースでJ2EE認証されたサーバーを構築するという計画を発表しました。そしてGeronimoが生まれたのです。GeronimoはJ2EE準拠のサーバーとして、広範な機能を網羅した、非常に大規模なプロジェクトです。ここではプロジェクト全体のスコープを理解できるように、ユーザーの視点からGeronimoを紹介します。次に、Geronimoのドキュメンテーションやソースコードを調べていると必ず突き当たる、幾つかの用語を説明します。そして最後に重要なこととして、システム設計という視点から、鍵となる概念の幾つかに注目しながらGeronimoの概要を理解します。

この記事を読み終われば、皆さんもGeronimoサーバーのユーザーとして、自分一人でGeronimoをさらに詳しく調べられるようになるでしょう。あるいはさらに、このオープンソース・プロジェクトの貢献者にもなれるかも知れません。また、このシリーズ第2回では、Geronimoサーバーを実際に試しながら、アプリケーションのコンフィギュレーションやデプロイメント、管理などを詳細に解説して行きます。

この記事の草稿に対して貴重なコメントを下さった、GeronimoチームのGeir Magnusson, Jr.とJeremy Boynes、David JencksそしてAlan D. Cabreraに心より感謝致します。

J2EE 1.4準拠のサーバーとしてのGeronimo

GeronimoはJ2EEサーバーとして、Webアプリケーションやエンタープライズ・アプリケーションをデプロイし、実行することができます。また、アプリケーションを構成するためにJSP（Java ServerPages）やサーブレット、フィルター、EJB（Enterprise JavaBeans）を使用することができます。アプリケーションは、JDBC（Java Data Access API）を通して外部のRDBMSにアクセスすることができ、JNDI（Java Naming and Directory Interface）を通してディレクトリー・サービスにアクセスすることができ、JMS（Java Message Service）を通してトランザクショナル・メッセージ・キューにアクセスすることができ、JavaMailを通してeメールにアクセスすることができます。

J2EE認証を得るという目標は、Geronimoプロジェクトにとって祝福でもあり呪いでもあります（囲み記事、J2EE認証の代償を見てください）。認証を受けるためには、J2EE 1.4仕様（参考文献）に記述されている必須機能をすべてサポートしなければなりません。この仕様はまた、一連の他の仕様（それぞれが必須事項に関する記述を持っています）も参照しています。図1は、Geronimoが認証を受けるために、どんなものを実装すべきかを概念的に示したものです。

J2EE認証の代償 J2EE 1.4認証は、本格的な、そして非常に労力を要するプロセスであり、プロジェクト・チームの数多くのメンバーが、それだけのために専任で作業する必要があります。この作業は、フルタイムで有償雇用された専門家にとっても気が遠くなるほどです。一面では、本来コードを書くために使えるはずの貴重な時間が、このための作業のために費やされてしまいます。しかし別の一面として、認証された製品の持つ高い互換性レベルと機能性の保証から、特にエンタープライズ開発者にとっては、認証されない製品とは比較にならないほど大きな魅力を持つものとなります。

図1では、箱の中で太字になっているものが、具体的なAPIの名前です。また、それらを現在のGeronimoがどのように実装しているかを、斜字体で示しています。斜字体になったプロジェクト名の幾つかは、皆さんも聞いたことがあるでしょう。

上に戻る

多様なオープンソース・プロジェクトの集まり

Geronimoのサーバー基盤、つまりカーネルやツール、ライブラリーなどから成る基盤は、熟練した開発者達によって全く初めから設計され、書かれたものです。しかし、構成要素となっているコンポーネントの多くは、Apache自体のプロジェクト・コミュニティーから選択された既存のプロジェクトであるか、あるいは、Apache Licenseと互換のライセンスを持つ、他のオープンソース・プロジェクトから採用したものです（参考文献と、囲み記事、なぜ、別のJ2EEサーバーが必要なのかを見てください）。

表1は、今日のGeronimoを構成している、他のオープンソース・プロジェクトをリストアップしたものです。この、『分割し、奪い取る』という戦略によって、既にテストされ、動作が検証されたオープンソース資産の再利用が図られ、またGeronimoの開発全体に関わる負担が大幅に削減されています。

なぜ、別のJ2EEサーバーが必要なのか 他にも、オープンソースのJ2EEサーバーが既に存在しており、しかもJ2EE 1.4認証されたものさえあります（ 参考文献 ）。しかしGeronimoは、Apacheライセンス（ 参考文献 ）を完全サポートしている、という点でユニークなのです。Apacheライセンスは、GNUのGPL（General Public License）やLGPL（Lesser General Public License）など他の主なライセンスに比較して、最も柔軟なものと見なされています。これらのライセンスの細かな違いに関しては、過去十年間、議論が繰り返されてきました。要約すると、ソースを利用していることを簡単に明示するだけで、商用であれ何であれ、どんな目的にでも自由にコードを使用でき、ユーザーが改善を加える場合にも何ら義務を課されないライセンスは、Apacheライセンスだけなのです。

複雑なシステムを統一する

図1 に示したシステムの複雑さだけでも、多くのシステム・アーキテクトを悩ますには充分です。この上さらに、Geronimoとして作り上げるために必要な他のオープンソース・プロジェクトのことまで考えるとなると、統合のための統一モデルが必要なことは明らかです。

統一モデルの考え方としては、任意のサービスをデプロイ、実行できる汎用のサービス・コンテナーを作ります。例えばOpenEJBは、このコンテナー上でサービスとして実行し、すべてのEJBをホストします。またJettyあるいはTomcatは、この同じコンテナー上の別のサービスとして実行し、すべてのサーブレットとJSPをホストします。このモデルによって、既存のオープンソース・サービスの統合が単純になるだけではなく、互換性のあるサービスを将来ホストできることにもなります（そうしたサービスには、Springアプリケーション・フレームワークなどJ2EEではないサービスも含まれるかも知れません。 参考文献 を見てください）。

このコンテナーは、充分に汎用なものである必要があり、しかもJ2EEサービスも非J2EEサービスサービスもプラグインできるように設計する必要があります。これは非常に困難な設計課題です。このコンテナーは、誰もしたがらないような、面倒で繰り返しの多い作業を全て処理できるだけではなく、プラグインされたサービスの邪魔をするほど万能であっても困ります。Geronimoの設計者達はJ2EE 1.4仕様の助けも借りながら、必要な機能領域として、すべてのサービスの中から次の3つを割り出しました。

• 管理の容易性
• コンフィギュレーション管理
• サービス・ライフサイクル

このリストは、Geronimoのサービス・コンテナーの持つ、3つの基本機能を網羅しています。この先で、こうした要求をGeronimoがどのように実現しているかを説明します。

上に戻る

崇高な目標: スケーラビリティー、管理の容易性、そしてコンフィギュレーション管理

Geronimoの設計者達は、テレコミュニケーション業界から先頭を奪いつつ、大規模な管理容易性やコンフィギュレーション管理の問題に取り組んでいます。OAM & P（Operations, Administrations, Maintenance and Provisioning）という言葉は、テレコミュニケーションのシステム・エンジニアにとっては基本的なものですが、Javaシステムの設計者にとっては比較的新しいものです。何百、あるいは何千というサービス・インスタンスが同時に実行しており、しかもフェールと回復が常時発生しているようなシステムでは、システムのオペレーションや管理、維持に関するビューは、大きく変化します。例えば、各インスタンスのコンフィギュレーション・ファイルを手動で変更することなどは、まったく問題外です。

極端な例として、Geronimoのインスタンス・クラスターに対して、次のような作業命令を出すことができます。

6月15日まで、1時間に50,000人の顧客を相手にするPet StoreというWebアプリケーションのピーク・ローディング時にプロビジョニングを行い、SLA（Service Level Agreement）制限として99%アップタイム、1件の注文処理に5秒を超えないようにする。6月15日にはピーク・ローディングを1時間10,000人、SLA制限を80%アップタイム、1件の注文処理を10秒にまで下げ、これを8月31日まで続ける。9月1日には、このWebアプリケーションを削除する。

ネットワーク管理システムは、この作業命令を受け取るとプロビジョニングを行い、クラスター全体に渡ってコンフィギュレーションとデプロイメントに関するすべての変更をスケジュールし、進行状況を監視し、また目的が達成できるように、時間と共にシステムが適応して行くように調整を行います。

このビジョンは、（少なくとも非テレコムのシステムとしては）まだ今日の現実から大きくかけ離れていますが、Geronimoのアーキテクチャーは、最初からこれを念頭に設計されています。

上に戻る

管理を容易にする

Geronimoの目指すビジョンと一致し、しかも使いやすいコンテナー設計を実現するための最初の基本ステップは、コンテナーを管理しやすいものにすることです。Geronimoチームは、この目標を実現するために、時間と共に手法を進化させてきました。

JMXによる寄り道

管理の容易性を実現するという目標にとって、コンテナーのコアをJMX（Java Management Extensions）にすることは自然な道筋です。コンテナー内部にある関連オブジェクト・インスタンスが、すべて適切に実装され、管理が容易であれば、実行システムを外部ツールによって管理し、監視し、制御することができ、またスケーラビリティー機能を実装することができます。Geronimoのカーネル設計の第1案（図2）は、この考え方を元にしています。

JMXについて JMXが初めての人は、この重要な話題に関して私が書いた、 3回シリーズの記事 を読むようにお勧めします。

図2を見ると、JMXは正にコンテナーのコア、カーネルにあります。そしてコンテナー内部の関連オブジェクトは、すべてMBeanです。MBeanは、完全に実装され、管理容易でなければなりません。Geronimoチームでは、このためにMX4J（ 参考文献 ）を選択しました。

しかしGeronimoチームは、実際には自分たちがMX4J本来の設計目標を超えた使い方をしていることに気が付いていました。つまりGeronimoはMX4Jを単なるJMXとして使用しているのではなく、オブジェクト・ロケーションやオブジェクト間コミュニケーション、メソッド捕捉などのための、汎用で、しかもハイ・ボリュームのシステムとして使用しているのです。Geronimoチームがこの道をたどるにつれ、コンテナーの複雑さがエスカレートし、パフォーマンスが大幅に低下し始めました。

もう一つ、Geronimoチームが気が付いたことは、管理重視のコアを使うと、既存のサービス・コードをシステムに適応させることが困難だという点です。図2で、JMXコアの上の箱はサービスを表し、破線による垂直の「フォーク」は、管理容易性コンサーンを処理するコードを表しています。管理容易性コンサーンのコードは、JMXを中心とするサービス設計と一致していますが、サービス・ロジックのコードは直交（そしてクロスカット）しています。このために、サービス・コードが書きにくく、維持管理もしにくくなります。どうやら計画の変更が必要なようです。

IoCスタイルで、より良いカーネルを作る

改訂されたカーネルの設計を図3に示します。

IoCについて Inversion of Controlは、依存性注入（dependency injection）とも呼ばれ、IoCコンテナーやフレームワークがサポートするパターンであり、コンサーンの分離を実現することができます。コンテナー内部のコンポーネントは依存関係を分離することができ、実行/デプロイメント中に、これらの依存関係をコンポーネント内に注入することができます。これによってコンテナーは実装を選択できることになり、制御を、実質的にコンポーネントからコンテナーへと逆転することができます。詳しくは 参考文献 に挙げた資料を見てください。

図3から分かるように、JMX実装はもはやカーネルのコアではありません。カーネル・アーキテクチャーは、今度はIoC（Inversion of Control、囲み記事、IoCについてを見てください）に基づいています。管理の容易性が極めて重要なことは同じなので、JMXは相変わらずカーネルの大きな部分を占めていますが、格下げされ、デプロイメント時にサービスの中に注入される数多くの依存関係の一つになっています。これによって、コードがサービス・ロジックを中心にできる（正にそうあるべきです）ため、新しいサービスの作成が非常に容易になります。JMXの管理容易性を利用するためには、IoC依存関係注入のための、あるコーディング規則に従うだけです。この設計によって、既存のサービスをGeronimoに移行しやすくなります。Geronimoに移行するには、既存サービスの周りに薄いラッパーを作り、それをIoCカーネルに適応させればよいのです。ここで、サービスはもはやJMX MBeanで表現されていないことに注意してください。サービスはGeronimo専用のGBeanで表現されます。次のセクションでは、この専用GBeanについて説明します。

この設計によって、JMXとは全く関係のない、非管理のオペレーションがサポートされ、コンポーネントは純粋にカーネルを通して対話動作が行えるようになります。そのため、GeronimoがIDEやコマンドライン・ツール、その他のカスタム・アプリケーションに埋め込まれたコンポーネントとして実行する、軽量のソリューションが可能となります。

上に戻る

Geronimoの用語

ここまで私が使ってきた用語は、（GBean以外は）汎用の用語です。先に進む前に、Geronimoや、その定義の中で突き当たる用語の幾つかを紹介しておくべきでしょう。

モジュール

デプロイ可能な単位をJ2EEでモジュールと呼ぶのと同じように、デプロイ可能なソフトウェア単位は、よく『モジュール』と呼ばれます（囲み記事、モジュールとコンフィギュレーションを見てください）。モジュールは多くのJavaクラスやGBeanを含み、通常は1つ以上のGeronimoデプロイメント・プランと関連付けられています（GBeanとGeronimoデプロイメント・プランについては、次のサブセクションで説明します）。例えばモジュールは、Webアーカイブ（WAR）ファイル内のWebアプリケーションである場合もあれば、エンタープライズ・アーカイブ（EAR）ファイル内のエンタープライズ・アプリケーションの場合もあります。モジュールは、ユーザーにとっての概念です。内部的に言うと、Geronimoカーネルからはモジュールは見えず、Geronimoカーネルはコンフィギュレーションに対してのみ動作します（コンフィギュレーションについては後で定義します）。

Geronimoデプロイメント・プラン

Geronimoデプロイメント・プランは、モジュール（コンフィギュレーション）を適切にデプロイするために必要な、Geronimo専用のメタデータであり、物理的にはXMLファイルです。これはモジュールのアーカイブ内部にある場合もあり、外部に保存される場合もあります（そこで、デプロイメント/管理ツールによって管理、編集されます）。Geronimoデプロイメント・プランXMLファイルは、モジュールのタイプや位置によって、様々な名前を持つことができます。例えば、JARに埋め込まれたEJB JARモジュールに対するGeronimoデプロイメント・プランは、openejb-jar.xmlと呼ばれます。一方、エンタープライズ・アプリケーションのEARモジュールに対するGeronimoデプロイメント・プランは、アーカイブの中に埋め込まれるとgeronimo-application.xmlと呼ばれます。デプロイメント・プランがアーカイブ外で維持管理される場合には、任意の名前を持つことができます。Geronimoは、WARやEAR、JARなどの単純なモジュール・タイプに対して、デフォルトのデプロイメント・プランを持っています。

GBean

モジュールがデプロイ可能な単位であるのに対して、GBeanはGeronimoの管理可能単位です。1つのデプロイ可能単位には、ゼロ以上の管理可能単位を含むことができます。従ってGeronimoでは、デプロイされた1つのモジュールは、多くのGBeanをデプロイすることができます。モジュール/コンフィギュレーション中の全クラスがGBeanである必要はありません。ライフサイクル・コールバックを受信しようとする実体、あるいは管理可能なJMX属性やオペレーションを公開しようとする実体だけをGBeanにすればよいのです。GBeanは、複数の実行インスタンスを持つことができます。GeronimoはGBeanが起動すると、各インスタンスに対して、固有の名前を割り当てます。内部的に言うと、Geronimoに見えるのはGBeanとコンフィギュレーションのみであり、モジュールは見えません。モジュールはユーザーにとっての概念であり、GBeanはシステムに関する概念です。

モジュールとコンフィギュレーション モジュールは、実はGeronimo専用の用語ではなく、単にJ2EEの用語にすぎません。デプロイメントの期間中には、1つ以上のモジュールが、コンフィギュレーションの中に一緒にパッケージされます。Geronimoカーネルはコンフィギュレーションしか理解しません。コンフィギュレーションというのは、実行すべき何か（例えばアプリケーションや様々なサービス、あるいは単なるJARファイルの集まり）です。これは、個々のコンポーネントを常時監視せずに済ますために必要なものです。システムには通常、密接に結合されたコンポーネントの集まりがあります（こうしたコンポーネントは後で疎結合となります）。コンフィギュレーションは通常、密に結合されたグループそれぞれに対して存在します。

コンフィギュレーション

コンフィギュレーションというのは、1つ以上のモジュールをまとめてデプロイしたものです。内部的に見ると、Geronimoは、1つ以上のGBeanをパッケージ・デプロイしたものとしてコンフィギュレーションを捉えます。Geronimoカーネルは、コンフィギュレーションを理解し、管理します。コンフィギュレーションは、実行すべき何か、と考えることができます。J2EEの中では、コンフィギュレーションはエンタープライズ・アプリケーションかも知れません。J2EEの外では、皆さんが作成したカスタム・サービスの集まりであるかも知れません。

コンフィギュレーションという考え方の鍵は、コンフィギュレーションがシリアル化できるという点、しかもそれを、Geronimoを実行している他の任意のシステム上にデシリアライズして戻し、同じコンフィギュレーションを別のGeronimoインスタンス上で実行できる、という点です。コンフィギュレーションを移行できるということは、スケーラビリティーのために非常に重要です。例えばPet Storeのアプリケーションで、500のGeronimoインスタンスを起動することを考えてみてください。既にできあがっているPet Storeコンフィギュレーションがあれば、その作業は、シリアル化したコンフィギュレーションを持つインスタンス群を単純に起動するだけのことになります。

コンフィギュレーションは、外部依存関係を持つこともできます。これらの依存関係を管理すること、そして要求があった時には即座に利用できるようにしておくことは、コンテナーの役目です。

実行中のGeronimoシステムは、数多くのコンフィギュレーションが実行することによって構成されています。コンフィギュレーションは階層関係を持つこともできます。またコンフィギュレーションはそれぞれ、ユーザーが規定する固有のコンフィギュレーションIDを持ちます。あるコンフィギュレーションは、別のコンフィギュレーションを、親コンフィギュレーションとして規定することができます。子コンフィギュレーションは親のクラスローダーを継承するため、親コンフィギュレーションの全クラスにアクセスすることができます。これは例えば、別々にデプロイされた2つのコンフィギュレーションの間でライブラリーを共有するような場合に便利です。

上に戻る

Geronimoの基本概念

このセクションで説明するGeronimoの重要概念を理解しておけば、皆さんが自分自身でGeronimoやソースコードを調べる上で大いに役立つでしょう。

GBeanのライフサイクル

GBeanは、単なるJMX MBeanではなく、JMX MBeanをはるかに超えたものです。GBeanは、管理可能サービスに関する偉大なファサード（facade）。GBeanの利点の1つは、コンテナーが、そのサービスのライフサイクルを管理できることです。コンテナーは、（もしGBeanが、オプションのGBeanLifecycleインターフェースを実装していれば）、状態が変化するとGBeanを呼びます。これをリスト1に示します。

                
public interface GBeanLifecycle {
    void doStart() throws Exception;
    void doStop() throws Exception;
    void doFail();
}

図4は、GBeanが通過する状態変化を示しています。

図4を見ると、GBeanを含むモジュールを、ターゲットにデプロイ、あるいは配布できることが分かります。ターゲットは、単一のマシンである場合もあれば、マシンのクラスターである場合もあります。ターゲットに配布すると、GBeanコンフィギュレーションが検証され、保存されますが、ターゲット上で起動はしません。ターゲットにデプロイすると、GBeanが起動します。

サーバーが停止されると、GBeanの持続状態(persistent states)は、コンフィギュレーション・ストアにそのまま保存されます。これはつまり、次にサーバーが再起動する時には、同じGBeanコンフィギュレーションが起動することを意味します。GBeanをアンデプロイすると、関連したコンフィギュレーションはターゲットから削除されます。実行しているインスタンスは全て停止され、そのGBeanを再度デプロイしない限り、そのGBeanを再起動することはできません。

鍵となる2つの仕様、JSR 77と78 J2EEの管理仕様であるJSR 77は、様々なプロトコルを使用する様々な管理ツールによってアプリケーション・サーバーを管理するための、管理モデルを記述しています。J2EEアプリケーション・デプロイメントに関する仕様であるJSR 88は、デプロイメント記述子の断片を表現するDDBeanの概念を記述しています。 表1 から分かるように、これら2つの仕様は認証を受けるためにJ2EEサーバーが実、J2EE装しなければならない項目の一部です。

starting (0) とstopped (3) という状態の間に、GBeanLifecycleインターフェースに対するコールバックをトリガーする状態遷移があります。これらも、JSR 77管理対象の状態に対応します（囲み記事、 鍵となる2つの仕様、JSR 77と78 を見てください）

コンフィギュレーション管理

コンフィギュレーションは、シリアル化されたフォーマットで、『コンフィギュレーション・ストア』の中に保存されます。Geronimoでは、コンフィギュレーション・ストアのためのプラグイン・プロバイダーをサポートしています。例えば、コンフィギュレーションをローカル・ディスクに保存する代わりに、JNDIプロバイダーを通してエンタープライズ・ディレクトリー・サービスに保存することができます。潜在的には、これによって、地理的に分離しているGeronimoインスタンスのクラスターが、コンフィギュレーションを共有できる可能性があります。

Geronimoは、デプロイメント・ツールのインターオペラビリティーのためにJSR 88をサポートしているため、コンフィギュレーション・ストアの中にある値（デプロイされているモジュールの現在をパラメーター化したもの）を、JSR-88準拠のサードパーティー・ツールを使って編集することができます（潜在的には、GUIベースのIDE内で、あるいはネットワーク管理システムを通して編集できるかも知れません）。

依存関係の管理

『依存関係マネージャー』は、Geronimoの重要コンポーネントです。特定なコンフィギュレーションを開始しようとすると、まずその依存関係を起動しなければならない場合がよくあります。例えば、JDBCを通してJMSやRDBMSにアクセスするWebアプリケーションでは、ActiveMQが起動していること、そしてJDBCコネクター・モジュールが起動して利用可能であることを確認する必要があります。依存関係マネージャーは依存関係を判定するために、モジュールのデプロイメント記述子とデプロイメント・プランを全てスキャンします。モジュールを起動する前に、そのモジュールの依存関係が満足されていることを確認するのは依存関係マネージャーの役割です。モジュールの依存関係は、Geronimoのデプロイメント・プランの中で明示的に規定します。

GBeanをつなぎ合わせる: 参照と対話動作

ちょっと見ると、GBeanが適切にデプロイでき、実行できれば、コンテナーの役割はほとんど終わったと思えるかも知れません。しかし、そんなことはありません。コンテナーに対する大きな機能要求として、もう一つ、GBean間の参照を「つなぎ合わせ」、GBean同士が対話動作できるようにすることがあるのです。

コンフィギュレーションが起動する時に、別のGBeanへの参照を取得するGBeanに実際に渡されるのは、コンテナーが生成したプロキシーです。このプロキシーは、参照対象であるGBeanと全く同じインターフェースを持っています。これによって2つのGBeanが分離され、参照対象のGBeanのライフサイクルをコンテナーが管理できるようになるのです。

他のGBeanに対する、解決可能な参照にアクセスするには、動的に生成される呼び出し側プロキシー（invoker proxy）を介します。これによって、実質的にカーネルの介在なしに、GBean同士がお互いを呼び合えることになります。図5は、この振る舞いを説明したものです。

図5では、GBean 1がGBean 2上のメソッドを呼び出しています。GBean 2は解決可能参照であり、Geronimoは動的に呼び出し側プロキシーを生成します。この呼び出し側プロキシーによって、2つのGBeanが直接に対話動作できるようになります。Geronimoは現在、この呼び出し側コードを動的生成するために、バイトコード生成ツールであるcglib（ 参考文献 ）を使っています。

上に戻る

まとめ

Geronimoはサーバーサイド製品開発のためのコンテナーとして、最も魅力的なものになる可能性を秘めています。その豊富な機能セット、何ら義務を伴わないApache License、そして「すぐにデプロイできる」J2EE 1.4コンテナーという利点には、多くの開発者が魅力を感じるはずです。この記事を読んだ皆さんは、Geronimoサーバーとはどんなものか、なぜオープンソース・ソフトウェア開発にとって重要なマイルストーンなのかを理解できたと思います。今回はGeronimoのアーキテクチャーを調べ、幾つかの重要な用語と概念に慣れました。第2回では、実際のサーバーを使いながら、実際的な作業の例を順を追って説明することにします。

参考文献

• Gluecode SoftwareのCTO（最高技術責任者）であり、Geronimoの主席貢献者であるJeremy Boynesが、Geronimoに関する彼の考え方やJavaプログラミングの方向性、オープンソース・ソフトウェアの現状などについて、 最近developerWorksに掲載されたインタビュー記事 の中で語っています。
  
  
• Apache Geronimoに基づくオープンソースのアプリケーション・サーバー、 Gluecode Standard Edition をダウンロードしてください。
  
  
• Geronimo project の正式サイトには、最新のソースコードやバイナリーがあり、また、メーリング・リストやwikiによる活発なコミュニティーがあります。
  
  
• Geronimoの本拠である Apache Software Foundation では、最新の Apache License の詳細なテキストを読むことができます。
  
  
• その他のオープンソース・ソフトウェア・ライセンスのテキストとして、GNUプロジェクトの Lesser General Public License と General Public License を見てください。
  
  
• Geronimoに統合されているデフォルトのサーブレット/JSPコンテナー、Jettyに関して、 Jetty プロジェクトのサイトで学んでください。
  
  
• Geronimo用の代替サーブレット/JSPコンテナーである Tomcat について調べてください。
  
  
• GeronimoのEJBコンテナーである OpenEJB の機能について調べてください。
  
  
• Derbyは、Geronimoでデフォルトのリレーショナル・データベース・サービスであり、JDBCプロバイダーです。 Derby project のWebサイトには、マニュアルやソースコードがあり、またメーリング・リストによる活発なコミュニティーがあります。
  
  
• GeronimoはWS-I Basic Profile準拠を実現するために、多用途なWebサービス・スタックである Axis を統合しています。
  
  
• Geronimoの目標の一つは、EJBと、より軽量なPOJOパーシスタンスの両方を実装するために、同じサブストレート（substrate）を使うことです。そのためのソリューションが TranQL project です。
  
  
• Geronimoチームは、トランザクションをサポートするために ObjectWeb のメンバーと密接に協力しています。Geronimoとの関係で鍵となるObjectWebプロジェクトは、 HOWL と JOTM です。
  
  
• Geronimoチームは、近い将来、 Apache Directory Server （開発コード名Apache Eve）を統合したいと思っています。
  
  
• Geronimoでは、管理容易性に関する要求を処理するために、JMX実装に MX4J ライブラリーを使っています。
  
  
• GeronimoはWebサービスに関する互換性を実現するために、 Apache Scout を使ってJAXR を実装しています。
  
  
• Geronimoは、GBean間の参照を捕捉するためのパイプラインを構成するために、素晴らしいコード生成ライブラリー、 cglib を使っています。
  
  
• Geronimoのビルド・プロセスやコンソール・モジュールでは、多用途な Velocityテンプレート・エンジン が至る所に使われています。
  
  
• Geronimoは、マルチプロジェクト・コードのビルドの管理に Apache Maven を、また個々のプロジェクト・ビルドには Apache Ant を使っています。大部分のプロジェクトに関するバージョン・コントロールは Subversion を使って行われ、幾つかのプロジェクトでは相変わらず CVS が使われています。
  
  
• JMX（Java Management Extensions）について学ぶために、Sing Li著による「 ブラック・ボックスからエンタープライズへ 」のシリーズ記事を読んでください（developerWorks, 2002年秋）。
  
  
• LGPLライセンスの下で使用可能な、もう一つのJ2EE 1.4認証済みオープンソース・サーバーについて、 Java Open Application Server (JOnAS) のWebサイトで学ぶことができます。
  
  
• 一連のJ2EE 1.4仕様の詳細については、 J2EE specifications page を見てください。
  
  
• 「 Javaの解放: Jason Hunter氏へのインタビュー 」（developerWorks, 2002年4月）を読んでください。オープンソース・プロジェクトがJava Community Processに参加してきた歴史を学ぶことができます。
  
  
• developerWorksblogs に参加して、developerWorksのコミュニティーに加わってください。
  
  
• developerWorksの Java technologyゾーン には、Javaプログラミングのあらゆる面に関する記事が豊富に取り揃えられています。
  
  
• Developer Bookstoreには Java関連の書籍 を始め、広範な話題を網羅した技術書が豊富に取り揃えられていますので、ぜひご利用ください。
  

著者について

		Sing LiはWrox Pressから出版されている多数の本の著者で、Professional Apache Tomcat 、Early Adopter JXTA 、Professional Jini などを執筆しています。技術雑誌に頻繁に寄稿しており、P2P発展に関する熱心なエバンジェリスト（伝道者）でもあります。コンサルタント兼ライターであるSingの連絡先はwestmakaha@yahoo.comです。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る