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 が認証を受けるために、どんなものを実装すべきかを概念的に示したものです。

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

上に戻る

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

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

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

上に戻る

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

図 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）は、この考え方を元にしています。

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

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

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

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

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

図 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 はシステムに関する概念です。

コンフィギュレーション

コンフィギュレーションというのは、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 を再起動することはできません。

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を見てください。
  
  
• developerWorksblogs に参加して、developerWorks のコミュニティーに加わってください。
  
  
• developerWorks の Java technology ゾーンには、Java プログラミングのあらゆる面に関する記事が豊富に取り揃えられています。
  
  
• Developer Bookstore には Java 関連の書籍を始め、広範な話題を網羅した技術書が豊富に取り揃えられていますので、ぜひご利用ください。
  
  

著者について

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

この記事を評価する

コメント

上に戻る

目次

• J2EE 1.4 準拠のサーバーとしての Geronimo
• 多様なオープンソース・プロジェクトの集まり
• 複雑なシステムを統一する
• 崇高な目標: スケーラビリティー、管理の容易性、そしてコンフィギュレーション管理
• 管理を容易にする
• Geronimo の用語
• Geronimo の基本概念
• まとめ
• 参考文献
• 著者について
• コメント