Geronimoは、Apache Software FoundationによるオープンソースのJ2EE 1.4サーバーとして、2003年に生まれました。この、2回シリーズの第1回では、システム設計の観点からGeronimoを解説し、アーキテクチャーを検証し、構造上で鍵となる幾つかの概念を探り、そして基本的なユーザー用語を紹介しました。今回はGeronimoを探るツアーを続けながら、サーバーのデプロイメントやコンフィギュレーション、管理機能などについて、少し詳細に調べて行きます。

この記事では、この多用途なコンテナーが、皆さんが日々行うJ2EE開発作業のどんな役に立つのかを学びます。エンタープライズ・アプリケーションの一例を取り上げ、Geronimoのデプロイメント・ツールを使って、数多くの、標準的なデプロイ可能J2EEモジュールをデプロイし、ライフサイクルを制御します。JSP（Java ServerPages）やサーブレット、Webアーカイブ（WAR）のタグ・ライブラリー、エンタープライズ・アーカイブ（EAR）のセッションEJB、リソース・アーカイブ（RAR）のJDBC（Java Database Connectivity）コネクター、EARにパッケージされている、EJB-QL（EJB Query Language）を使用するCMP2（container-managed persistence）エンティティーbeanなどをGeronimoでテストします。また、Geronimoでのクラスローダーの階層構造と、その構造がコンフィギュレーションと密接に関連していることを理解します。そして最後に重要なこととして、Geronimoが管理容易性を実際にどのようにサポートしているかを学びます。JMX（Java Management Extensions）コンソールを利用すると、Geronimoの内部を見ることができ、デプロイされたWebコンポーネントも見ることができるのです。

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

Geronimoの断面を探る

第1回でのアーキテクチャーに関する解説の中で、Geronimoが、コンフィギュレーションや管理、デプロイメント、その他の重要サービスを、他のオープンソース・コンテナー（例えばJettyやTomcat、OpenEJBなど）に提供するためのコンテナーとして動作することを学びました。

図1は、Geronimoの持つ、タマネギのようなコンテナー・ネスティング構造を説明しています。まず、Geronimoそのものが、JettyやTomcatなどのサービスをラップするコンテナーです。次に、デプロイされるWebアプリケーション・コンポーネント（サーブレットやJSP、タグ・ライブラリーなど）をJettyがラップしています。図1から分かる重要なこととして、メタデータ、つまりデプロイメント記述子（XMLファイル）の情報が、コンテナーの境界毎に必要だという点に注意してください。

図1では、j2ee-server-plan. xmlデプロイメント・プランが、Jettyサービスをどのようにデプロイし、コンフィギュレーションすべきかをGeronimoに伝えています。一皮剥いで次の階層に進むと、jetty-web.xmlデプロイメント記述子が、Webアプリケーション・コンポーネントをどのようにデプロイし、コンフィギュレーションすべきかを、Geronimo内に含まれているJettyサービスに伝えています。

当然ですが、J2EE 1.4仕様で規定されている、標準の、コンテナーとは独立のデプロイメント記述子も必要です。これらの記述子としては、Webアプリケーションに対するweb.xml、EJBアーカイブに対するejb-ear.xml、EARファイルに対するapplication.xmlなどがあります。

この記事では、J2EEでデプロイ可能なモジュールのコンフィギュレーションとデプロイメントのみに集中することにします。システム・コンポーネント（JettyやTomcatなど）のコンフィギュレーションとデプロイメントは、機構としては似ていますが、この記事の範囲外です。

上に戻る

デプロイメントとライフサイクル制御

表1は、デプロイ可能な様々なアーカイブと、そのデプロイメント記述子、関連のGeronimoデプロイメント・プランの詳細を示しています。

表1.　デプロイ可能アーカイブと、そのデプロイメント記述子とGeronimoデプロイメント・プラン

J2EEで規定される記述子（表1で2番目の列）はすべて、アーカイブの中に埋め込まれている必要があります。J2EE仕様（参考文献）では、図2に示すように各リソースの位置を規定しています（この図ではサーバーサイドのアーカイブのみを示しています）。一方Geronimoデプロイメント・プランの位置は、少し柔軟です。図2では、Geronimoデプロイメント・プランの取りうる位置を、破線の箱として示しています。

図2と表1とを対照させると、各タイプのアーカイブ・ファイルに対するGeronimoデプロイメント・プランを特定できます。Geronimoでは、下記のように、これらのデプロイメント・プランを置くべき場所を選択することができます。

• 関連のデプロイメント記述子と共にアーカイブの内部に置く（図2では、破線の四角で示してあります）
• 独立のXMLファイルとしてアーカイブの外に置き、デプロイメント・ツールを使ってアーカイブをデプロイする際に、入力として規定する

もしデプロイメント・プランをアーカイブの外に置く場合には、表1の3列目に規定した名前を使う必要はなく、任意のファイル名を使うことができます。デプロイメント・プランをアーカイブの外に置くと、次のような幾つか点で有利です。

• そのアーカイブ・ファイル自体は汎用のJ2EEアーカイブのままなので、J2EE準拠の任意のサーバー上にデプロイできる
• 変更を行いやすい（デプロイメント・プランを抽出して修正、再アーカイブする必要がない）
• ツールを使ってグラフィカルに変更を行うことができる（つまり、グラフィカルにファイルを編集できる）。このツールとしては、JSR-88準拠のデプロイメント・ツールでもよく、さらには自動システム管理エージェントであっても構わない

デプロイメント・プランを外部に持つことによる問題点としては、小さな欠点ですが、自動化されたツールが利用できるようになるまで、アーカイブ・ファイルとその関連デプロイメント・プランとを手動追跡しなければならないことです。

J2EEモジュールをデプロイする時にGeronimo内部で何が起きるのかを覗いてみるには、囲み記事、デプロイメント・プランとコンフィギュレーション、そしてビルダーを見てください。

上に戻る

サンプル・アプリケーション、『Really Big Pet Store』

デプロイメント記述子とGeronimoデプロイメント・プランとの関係は理解できたので、今度はWebアプリケーションをGeronimoにデプロイしてみましょう。この記事では、『Really Big Pet Store』という例を使います。これはeコマース・アプリケーションの一部であり、カタログを表示し、単純な買い物かごを処理します。この店は大きくはありません。いや、非常に小さいのです。しかし、非常に大型のペットを販売しています。この店の在庫の例を図3に示します。

図3. 　Really Big Pet Storeの在庫

ここでは、このサンプル・アプリケーションの3つのバージョンを取り上げます。この3つは次のように順次複雑になっており、それぞれ別々のJ2EEパッケージを使ってデプロイされます。

• 自己完結のWebアプリケーション。サーブレットとJSP、JSPタグ・ライブラリーが含まれていますが、外部リソースは使いません。このバージョンはWARとしてアーカイブされています。
• 最初のバージョンの変更版。製品カテゴリー情報を取得するためにEJBをアクセスします。このEJBはセッションbeanであり、ローカル・ビューを持っています。このアーカイブはEARファイルの中にバンドルされています。
• 2番目のバージョンをさらに進化させたもの。セッションEJBはエンティティーEJBのファサード（facade）になります。エンティティーEJBはEJB2準拠のエンティティーbeanであり、CMPを使ってリレーショナル・データベースにアクセスします。このアプリケーションはEARファイルの中にバンドルされていますが、RARファイルの中にアーカイブされたリソース・アダプター（JDBCコネクター）を利用する必要があります。Really Big Pet Storeのソースコードについては、ダウンロード・セクションを見てください。

WARをデプロイする

このアプリケーションの最初のバージョンは、reallybigpet.warの中にアーカイブされています。これは、コード・ディストリビューションのwar_only\distディレクトリーの中にあります。表2は、このバージョンの中にあるコンポーネントを示しています。これらのコンポーネントはどれも、2番目、3番目のバージョンでも使われます（変更点については注釈を入れています）。

訳註：円マーク（\）は原文ではバックスラッシュです。

ディストリビューションの中の様々なソースコード・ファイルを調べ、何がどのように動作しているのかを理解する上で、この表2が役立つでしょう。ここでは、このアプリケーションをGeronimoにデプロイして実行する、ということが主題です。図4は、このアプリケーションをデプロイした時に何が起きるかを示しています。

図4では、ターゲットとするサーバーにモジュールをデプロイするために、Geronimoのデプロイヤー・ツールを使っています（場合によるとGeronimoデプロイメント・プランも使うかも知れません）。サーバーはメタデータをコンフィギュレーション・ストアに、また、実行可能コードをバイナリー・リポジトリーに保存します。これによって、何らかの理由でサーバーが終了させられた場合にも、同じコンフィギュレーションで再起動することができます。

Geronimoのインストール・ディレクトリーに行き、下記のコマンドを入力してGeronimoを起動します。

java -jar bin\server.jar

あるいは、コマンドの後にコンフィギュレーションの名前を追加することによって、特定のコンフィギュレーションを起動することもできます（コンフィギュレーションの定義については、第1回を見てください）。この例では、デフォルトのシステム・コンフィギュレーションで充分です。このコンフィギュレーションで実行している全モジュールをリストアップするには、下記のコマンドを使います。

java -jar bin\deployer.jar list-modules

ツールがユーザー名とパスワードを要求します。ユーザー名にはsystemを、パスワードにはmanagerを使います。モジュールをリストアップするために、デプロイメント・ツールそのものを使っていることに注意してください。面倒なタイプ打ちを減らすために、ディストリビューションにはlm.batというバッチ・ファイルが含まれています。

reallybigpet.warアーカイブをデプロイするには、まず、このWebアプリケーションをGeronimoのホーム・ディレクトリーにコピーし、次の下記のコマンドを発行します。

java -jar bin\deployer.jar deploy reallybigpet.war

dp.batバッチ・ファイルを使ってもタイプ打ちを少し省略することができます。暫くすると、デプロイメント・ツールが返ってきて、そのデプロイメントが成功したことをレポートします。この場合では、別のgeronimo-jetty.xmlデプロイメント・プランを使う必要がないことに注意してください。ここでは、Geronimoに用意されている、WARファイル用のデフォルト・プランで充分なのです。再度list-moduleコマンドを実行すると、実行しているモジュールが分かります。デフォルトの名前はreallybigpetであり、JARファイルの名前と同じです。

アプリケーションを試すには、URL、http://localhost:8080/reallybigpet/store.cgiを使います。

デプロイされたモジュールのライフサイクルを制御する

第1回を思い出してもらえば分かると思いますが、GBeanには、GeronimoがGBeanのライフサイクルを制御できるようにするオプションがあります。この機能を使うと、Webアプリケーションの振る舞いを制御することができます。アプリケーションを停止するには、次のコマンドを使います。

java -jar bin\deployer.jar stop reallybigpet

アプリケーションが停止した後で店のURLをアクセスしようとすると、Geronimoは応答しません。再度アプリケーションを起動するには、次のコマンドを使います。

java -jar bin\deployer.jar start reallybigpet

このモジュールに対するバイナリーとメタデータをGeronimoから完全に削除するためには、下記のようにundeployコマンドを使います。

java -jar bin\deployer.jar undeploy reallybigpet

いったんモジュールをアンデプロイした後で再度使えるようにするためには、そのモジュールを再度デプロイする必要があります。また、既にデプロイされているモジュールをアップデートするためには、redeployコマンドを使います。このコマンドは、既存のバージョンのアンデプロイと、指定した新しいバージョンのデプロイをワンステップで効果的に行います。

EARをデプロイする

サンプル・アプリケーションの2番目のバージョンでは、ステートレス・セッションEJBを追加します。コントローラー・サーブレットは、このEJBにアクセスし、表示すべき製品カテゴリーのリストを入手します。ソースコードを調べたい人は、ejbディレクトリーの下にある下記を見てください。

• CategoriesHomeLocal.javaはホーム・インターフェースです。
• CategoriesLocal.javaはオブジェクト・インターフェースです。
• CategoriesBean.javaはEJBの実装です。

新しいセッションbeanの記述は、ejb-jar.xmlデプロイメント記述子の中にあります。これをリスト1に示します。

                
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' 
'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
<ejb-jar>
  <enterprise-beans>
      <session>
          <display-name>Categories Stateless Session Bean Local Interfaces</display-name>
          <ejb-name>CategoriesEJB</ejb-name>
          <local-home>com.ibm.dw.reallybigpet.ejb.CategoriesHomeLocal</local-home>
          <local>com.ibm.dw.reallybigpet.ejb.CategoriesLocal</local>
          <ejb-class>com.ibm.dw.reallybigpet.ejb.CategoriesBean</ejb-class>
          <session-type>Stateless</session-type>
          <transaction-type>Container</transaction-type>
      </session>
  </enterprise-beans>

</ejb-jar>

StoreControllerは、ReallyBigPetStore クラスのgetCats() メソッドを呼んでカテゴリーを取得し、cats属性を設定します。これをリスト2に示します。この属性は、bigpetstore.jspがカテゴリーを表示するために使用します。

                
package com.ibm.dw.reallybigpet;
...

public class StoreController extends HttpServlet {
    
   ....
    protected void doGet(HttpServletRequest request, HttpServletResponse response) 
          throws ServletException, IOException {
        ...       
        ArrayList cats = ReallyBigPetStore.getCats();
        session.setAttribute("cats", cats);
        ...
        }   
        ...    
    }

ReallyBigPetStoreは、今度は独自のデータを生成する代わりに、セッションbeanにアクセスしてカテゴリー情報を取得します。リスト3は、このEJBにアクセスするコードを示しています。

                
package com.ibm.dw.reallybigpet;
import java.util.*;

import com.ibm.dw.reallybigpet.ejb.CategoriesHomeLocal;
import com.ibm.dw.reallybigpet.ejb.CategoriesLocal;
import  javax.naming.InitialContext;
import javax.naming.Context;

public class ReallyBigPetStore {
    public ReallyBigPetStore() {
    }
    public static ArrayList getCats() {
    CategoriesLocal cl = null;
    try {
      Context ic = new InitialContext();
      Object o = ic.lookup("java:comp/env/CatEJB");  
      CategoriesHomeLocal ejbhome = (CategoriesHomeLocal) o;
        cl = ejbhome.create();
    } catch (Exception ex) {
      ex.printStackTrace();
      }
    
   return cl.getCats(); 
    }
  }

WARアーカイブに対するデプロイメント記述子は、今度はセッションEJBを参照する必要があります。<ejb-local-ref>要素を追加した、新しいweb.xmlをリスト4に示します。

                
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee 
      http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">
    ...   
    <ejb-local-ref>
        <ejb-ref-name>CatEJB</ejb-ref-name>
        <ejb-ref-type>Session</ejb-ref-type>
        <local-home>
        com.ibm.dw.reallybigpet.ejb.CategoriesHomeLocal
        </local-home>
        <local>com.ibm.dw.reallybigpet.ejb.CategoriesLocal</local>
   </ejb-local-ref>
</web-app>

EARに対するapplication.xmlデプロイメント記述子（リスト5）は、EAR内にあるアーカイブを指定しており、またアプリケーションに対するコンテキスト・ルートを提供しています。

                
<application 
       xmlns="http://java.sun.com/xml/ns/j2ee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
       http://java.sun.com/xml/ns/j2ee/application_1_4.xsd"
       version="1.4">
    <module>
        <ejb>bigpetstore-ejbs.jar</ejb>
    </module>
    <module>
        <web>
            <web-uri>reallybigpet.war</web-uri>
            <context-root>/ReallyBigPetStore</context-root>
        </web>
    </module>
</application>

これで、reallybigpet.earを（distディレクトリーから）デプロイすることができます（ただしその前に、この前のサンプル・アプリケーションをアンデプロイすることを忘れないでください）。

皆さんは驚くかも知れませんが、このアーカイブはWARの外にあるEJBを含んでいるにもかかわらず、モジュールを動作させるために追加のgeronimo-application.xmlデプロイメント・プランを作成する必要はありません。その理由は、デプロイを実現するためにGeronimoが最善の努力をするからです。実際Geronimoは、参照を解決する際にホーム・インターフェースとオブジェクト・インターフェースを調べ、合致するEJBを探してくるのです。

RARにTranQLコネクターをデプロイする

このアプリケーションの最後のバージョンには、もう1つのEJBが登場します。この場合のEJBは、CMP2とEJB-QLを使ってリレーショナル・データベースにアクセスする、エンティティーEJBです。依存関係が外部にあることによって、セットアップが大幅に複雑になります。

まず、適当なデータでリレーショナル・データベースを設定する必要があります。そのために、RDBMSに合うようにaddtab.sqlスクリプトを修正します。リスト6に示すスクリプトは、MySQLサーバーに対して動作するものです。

                
drop table petcats;
create table petcats (
  id varchar(20) NOT NULL,
  name varchar(50) NOT NULL,
  PRIMARY KEY (id)

  )               ;
INSERT INTO petcats VALUES( '1', 'New');
INSERT INTO petcats VALUES( '2', 'Clearance');

次に、RDBMS に対するJDBCドライバーを見つけ、それをGeronimoのリポジトリー・ディレクトリーの下にあるサブディレクトリーにコピーする必要があります。例えば、この例でのMySQLドライバーを、repository\mysql\jarsディレクトリーにコピーします。

JDBCコネクターをデプロイするには、Geronimoの一部である、TranQLのコネクターを使います。このコネクターはコネクション・プーリングを持っており、指定されたJDBCドライバーをロードします。このコネクターをコンフィギュレーションするには、Geronimo専用のデプロイメント・プランが必要です（Geronimoには、どのJDBCドライバーを使うべきか分がからないため）。ddcmpディレクトリーの下にあるgeronimo-ra.xmlファイルを見てみましょう。リスト7は、このファイルの一部です。

                
<?xml version="1.0"?>
<connector xmlns="http://geronimo.apache.org/xml/ns/j2ee/connector"
   version="1.5" configId="PetsDB" parentId="org/apache/geronimo/Server">

  <dependency>
    <uri>mysql/jars/mysqldriver.jar</uri>
  </dependency>
  <resourceadapter>
    <outbound-resourceadapter>
      <connection-definition>
        <connectionfactory-interface>
          javax.sql.DataSource
        </connectionfactory-interface>
        <connectiondefinition-instance>
          <name>PetsDataSource</name>
     ...
  </resourceadapter>

</connector>

geronimo-ra.xmlの中のエントリーを編集し、JDBCドライバーの要求に合わせてコネクターをコンフィギュレーションする必要があります。この場合では、コンフィギュレーションIDとしてPetsDBが使われていることに注意してください。

これで、リソース・アダプターをデプロイすることができます。そのために下記のコマンドを使います。

java -jar bin\deployer deploy repository\tranql\rars\tranql-connector-1.0-M4.rar  
  geronimo-ra.xml

最新のマイルストーンと最新のビルドとでは名前が異なるので、使用すべき具体的な名前を見るには、repository\tranql\rarsディレクトリーを調べる必要があります（Geronimoのマイルストーン・ビルドと、最新のGeronimoビルドを入手するを見てください）。デプロイメントが成功すると、list-moduleコマンドが実行でき、PetsDBコンフィギュレーション（モジュール）が実行していることを確認することができます。

Geronimoシステムは、システム・デフォルトのデータソースとして、Derby RDBMS（参考文献）のインスタンスを起動します。この例では、このデータベース・インスタンスを使用します。詳しい情報については、ソースコード・ディストリビューションの中にあるREADME.TXTを読んでください。

Geronimoのコンフィギュレーションとクラスローダー

resource-adapterの例のようにGeronimoデプロイメント・プランを含める場合には、コンフィギュレーションID（configId属性）と親コンフィギュレーションID（parentId属性）を規定します。これによってクラスローダーの階層構造が確立され、別々にデプロイされたモジュール間でコードを共有できるようになります。図5はコンフィギュレーションの階層構造を示しています。

図5では、コンフィギュレーションAはコンフィギュレーションBの親であり、コンフィギュレーションBはWARファイルを含むEARモジュールです。白い丸はGeronimoクラスローダー（実際にはURLClassloader）を表します。この場合、コンフィギュレーションBのクラスローダーは、コンフィギュレーションAのクラスローダーの子であり、コンフィギュレーションBでコンフィギュレーションAのコードにアクセスすることができます。WARファイルには必ず独自のクラスローダーがあり、同じEARの中にある他のコードがWAR内のクラスにアクセスできないようになっています。

EARにCMP2 EJBをデプロイする

Really Big Pet Storeの最後のバージョンでは、エンティティーEJBを使ってカテゴリー情報を取得します。セッションbeanはカテゴリー情報を得るために、今度は新しいエンティティーEJBをアクセスします。このエンティティーEJBのソースコードはejbcmpディレクトリーにあります。

• CategoryHomeはホーム・インターフェースです。
• CategoryRemoteはリモート・インターフェースです。
• CategoryBeanはEJBの実装です。

CMP2 EJBをマッピングするための鍵は、ejb-jar.xmlデプロイメント記述子の中にあります（リスト8）。

                
<?xml version="1.0" encoding="US-ASCII"?>
<ejb-jar xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
    http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd"
    version="2.1">
    ...
    <enterprise-beans>
 
        <entity>
       ....
            <ejb-name>CategoryBean</ejb-name>
            <home>com.ibm.dw.reallybigpet.ejb.cmp.CategoryHome</home>
            <remote>com.ibm.dw.reallybigpet.ejb.cmp.CategoryRemote</remote>
            <ejb-class>com.ibm.dw.reallybigpet.ejb.cmp.CategoryBean</ejb-class>
            <persistence-type>Container</persistence-type>
            <prim-key-class>java.lang.String</prim-key-class>
            <reentrant>false</reentrant>
            <cmp-version>2.x</cmp-version>
            <abstract-schema-name>CategoryBean</abstract-schema-name>
            <cmp-field><field-name>id</field-name></cmp-field>
            <cmp-field><field-name>name</field-name></cmp-field>
            <primkey-field>id</primkey-field>
            <resource-ref>
                <description>
                    This is a reference to a JDBC database.
                </description>
                <res-ref-name>jdbc/basic/entityDatabase</res-ref-name>
                <res-type>javax.sql.DataSource</res-type>
                <res-auth>Container</res-auth>
            </resource-ref>
            ...
            <query>
                <query-method>
                    <method-name>findAll</method-name>
                    <method-params/>
                </query-method>
                <ejb-ql>
                <![CDATA[SELECT OBJECT(a) FROM CategoryBean AS a]]>
                </ejb-ql>
            </query>

        </entity>

     </enterprise-beans>
</ejb-jar>

リスト8を見ると、エンティティーbeanの永続フィールドの仕様が分かります。また、作成されたRDBMSからEJB-QLを使って全カテゴリーをフェッチするために、findAll() メソッドが規定されています。

エンティティーbeanを適切にデプロイするためには、Geronimoデプロイメント・プラン（openejb-jar.xmlファイル）を作成する必要があります。これをリスト9に示します。

                
<?xml version="1.0"?>
<openejb-jar
    xmlns="http://www.openejb.org/xml/ns/openejb-jar"
    configId="com/ibm/dw/ReallyBigPet"
    parentId="PetsDB">
    <cmp-connection-factory>
        <application>null</application>
        <module>PetsDB</module>
        <name>PetsDataSource</name>
    </cmp-connection-factory>
    <enterprise-beans>
        <entity>
            <ejb-name>CategoryBean</ejb-name>
            <jndi-name>CategoryBean</jndi-name>
            <table-name>petcats</table-name>
            <cmp-field-mapping>
                <cmp-field-name>id</cmp-field-name>
                <table-column>id</table-column>
            </cmp-field-mapping>
            <cmp-field-mapping>
                <cmp-field-name>name</cmp-field-name>
                <table-column>name</table-column>
            </cmp-field-mapping>
            <resource-ref>
                <ref-name>jdbc/basic/entityDatabase</ref-name>
                <application>null</application>
                <module>PetsDB</module>
                <name>PetsDBPool</name>
            </resource-ref>
        </entity>
    </enterprise-beans>
</openejb-jar>

リスト9は、デプロイされたPetsDB connectorを参照しており、具体的なテーブルとフィールド・マッピングを規定しています。このファイルが、EARファイルの中のEJB JARの一部であることに注意してください。このファイルは、便利なようにJARと一緒にアーカイブされています。

これで、reallybigpet.earアプリケーションの最後のバージョンをデプロイすることができます。適切にデプロイされると、アプリケーションを試すことができ（URL、http://localhost:8080/ReallyBigPetStore/store.cgiを使います）、RDBMSからフェッチされたカテゴリーを見ることができます。

CategoryBeanエンティティーEJBの基礎となっているデータベース・テーブルをアップデートした場合の効果を見るためには、データベースのコマンドライン・インターフェースにサインオンし、次のSQLステートメントを入力します。

INSERT INTO petcats VALUES( '3', 'Promotional');

この状態でブラウザーの再読込を行い、再度アプリケーションを試してみます。JSPが提示する選択を選ぶと、新しいカテゴリー、Promotional（特売）が即座に出てくることが分かるでしょう。

上に戻る

MC4Jを使ってGeronimoのJMX構造の内部を覗く

最後に、MC4J JMXコンソール（参考文献）をダウンロードしてインストールし、デプロイされたWebアプリケーションが公開する属性とオペレーションを見てみましょう。

MC4Jは、RMIレジストリーを介してGeronimoと接続できるようになっています。Managementメニューから、Create Server Connection...を選択します。Server Connection TypeとしてGeronimoを選択し、Principleの値としてsystemを、Credentialsとしてmanagerを入力します。図6は、JMX管理コンソールを通して見たReally Big Pet Storeアプリケーションを示しています。

Geronimoは、デプロイされたコンポーネントを、コンテナー内のGBeanとして管理します（第1回を読んでください）。GBeanのライフサイクルはGeronimoによって管理され、またGBeanは、管理可能な属性やオペレーションを、JMXを介して公開します。これらの属性とオペレーションは、JMX MBeanを介して公開されます。図7は、このJMXコネクションを通してアプリケーション属性が公開される様子を表しています。

上に戻る

まとめ

Geronimoは、オープンソースのJ2EE 1.4コンテナーとして最初のものではありません。そして恐らく、最後のものということもないでしょう。しかし、誰でも自由に使えるというユニークな特徴、また優雅な設計や産業レベルの高いグレード、フィールド・テストされたApacheコードベースを自由に引き出せること、世界的な開発者コミュニティーに熱狂的に受け入れられていることなどは、Geronimoが他のものとは大きく異なる点です。有名なApache Webサーバー・プロジェクトと同様、Geronimoはその目標を達成するまで成長を続けるでしょう。Geronimoプロジェクトは、オープンソースのJava開発がいよいよ成熟したことを示す、重要な証と言えるでしょう。

上に戻る

ダウンロード

ダウンロード形式について

参考文献

• このシリーズの第1回「J2EE 1.4エンジンへの道」を読んでください。Geronimoを紹介し、概念的な概要を解説しています。
  
  
• Apache Geronimoに基づくオープンソースのアプリケーション・サーバー、Gluecode Standard Editionをダウンロードしてください。
  
  
• Gluecode SoftwareのCTO（最高技術責任者）であり、Geronimoの主席貢献者であるJeremy Boynesが、Geronimoに関する彼の考え方やJavaプログラミングの方向性、オープンソース・ソフトウェアの現状などについて、最近developerWorksに掲載されたインタビュー記事の中で語っています。
  
  
• Geronimo projectの正式サイトには、最新のソースコードやバイナリーがあり、また、メーリング・リストやwikiによる活発なコミュニティーがあります。
  
  
• GeronimoサーバーへのJMXコネクションを試すには、最新バージョンのMC4Jをダウンロードしてください。MC4Jは、様々なサーバーで動作する、オープンソースのJMX管理コンソールです。
  
  
• 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はWebサービスに関する互換性を実現するために、Apache Scoutを使ってJAXR を実装しています。
  
  
• GeronimoはWS-I Basic Profile準拠を実現するために、多用途なWebサービス・スタックであるAxisを統合しています。
  
  
• Geronimoの目標の一つは、EJBと、より軽量なPOJOパーシスタンスの両方を実装するために、同じサブストレート（substrate）を使うことです。そのためのソリューションがTranQL projectです。
  
  
• Geronimoチームは、トランザクションをサポートするためにObjectWebのメンバーと密接に協力しています。Geronimoとの関係で鍵となるObjectWebプロジェクトは、HOWLとJOTMです。
  
  
• Geronimoでは、管理容易性に関する要求を処理するために、JMX実装にMX4Jライブラリーを使っています。
  
  
• Geronimoの捕捉スタック（interception stack）では全体に渡って、またGBean間の参照のために、素晴らしいコード生成ライブラリー、cglibが使われています。
  
  
• Geronimoは、マルチプロジェクト・コードのビルドの管理にApache Mavenを、また個々のプロジェクト・ビルドにはApache Antを使っています。大部分のプロジェクトに関するバージョン・コントロールはSubversionを使って行われ、幾つかのプロジェクトでは相変わらず CVSが使われています。
  
  
• JMX（Java Management Extensions）について学ぶために、Sing Li著による「ブラック・ボックスからエンタープライズへ」のシリーズ記事を読んでください（developerWorks, 2002年秋）。
  
  
• Inversion of Controlパターンや、依存性注入一般（dependency injection）に関する情報については、 Apache Jakarta Hivemind framework や Pico Container 、などを見てください。
  Spring application framework
  
  
  
• LGPLライセンスの下で使用可能な、もう一つのJ2EE 1.4認証済みオープンソース・サーバーについて、Java Open Application Server (JOnAS) のWebサイトで学ぶことができます。
  
  
• 一連のJ2EE 1.4仕様の詳細については、J2EE specifications pageを見てください。
  
  
• Java技術に関するマネージャーやアーキテクト、開発者などがJ2EE技術について学ぶには、Kyle Gabhart著によるJ2EE pathfinder series が好適です。
  
  
• 「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です。

この記事を評価する

コメント

上に戻る

目次

• Geronimoの断面を探る
• デプロイメントとライフサイクル制御
• サンプル・アプリケーション、『Really Big Pet Store』
• MC4Jを使ってGeronimoのJMX構造の内部を覗く
• まとめ
• ダウンロード
• 参考文献
• 著者について
• コメント