本文へジャンプ

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。プロフィールで選択した情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

  • 閉じる [x]

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む


送信されたすべての情報は安全です。

  • 閉じる [x]

Geronimo!: 第 2 回 野生の J2EE 1.4 を使いこなす

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

概要: Apache Software Foundation の J2EE 1.4 サーバー・プロジェクトである Geronimo は、大量にある既存のオープンソース・サービスを統合して J2EE 1.4 準拠を実現しようとしています。この、2 回シリーズの第 1 回では、Geronimo の存在理由や設計ゴール、アーキテクチャー、また中核的な概念や用語などを解説しました。この第 2 回では、Sing Li が Geronimo の実際を取り上げます。最新の Geronimo ディストリビューションを使って、Web アプリケーションやエンタープライズ・アプリケーション、EJB(Enterprise Java™Beans)などをテストし、またデプロイを行います。

このシリーズの他の記事を見る

日付:  2005年 5月 24日
レベル: 初級 この記事の原文:  英語
アクティビティー: 2412 ビュー
お気軽にご意見・ご感想をお寄せください: 


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.  Geronimo というタマネギの断面を見ると、コンテナーのネスティング構造と、必要なメタデータが分かる

図 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 仕様での標準デプロイメント記述子Geronimo 特有のデプロイメント・プラン
Web アプリケーション・アーカイブ(WAR)ファイル WEB-INF ディレクトリーの下の web.xml geronimo-jetty.xml
EJB を含む JAR META-INF ディレクトリーの下の ejb-jar.xml openejb-jar.xml
エンタープライズ Web アプリケーション・アーカイブ(EAR)ファイル application.xml と、含まれているすべての WAR の内部にある web.xml、そして含まれているすべての EJB JAR の内部にある ejb-jar.xml geronimo-application.xml
J2EE コネクター・リソース・アーカイブ(RAR) ra.xmlgeronimo-ra.xml
J2EE クライアント・アプリケーション・アーカイブ(JAR) application-client.xmlgeronimo-application-client.xml

疑わしい時は、とにかくデプロイせよ!

Geronimo では、サーバーのユーザーが箱を開いた時に最も楽しい思いができるように、WAR ファイルや EJB JAR ファイル、EAR ファイルなどのデフォルト・デプロイメント・プランが設計されています。多くの場合、これらの組み込みデフォルトだけで充分であり、大部分のアーカイブは Geronimo 専用のデプロイメント・プランを作らなくてもデプロイすることができます。

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


図 2. J2EE デプロイ可能アーカイブ内における Geronimo デプロイメント・プランの位置

デプロイメント・プランとコンフィギュレーション、そしてビルダー

皆さんは、Web モジュールをデプロイする時に Geronimo 内部で何が起きるのか、興味を持っているかも知れません。第 1 回で、カーネルが見るのはコンフィギュレーションのみであることを学びました。デプロイメント時には、ビルダーと呼ばれる専用のソフトウェア・コンポーネントが呼ばれ、XML デプロイメント・プランとデプロイメント記述子を、カーネルが扱えるコンフィギュレーションに変換します。カーネルの実行時には、変換されたコンフィギュレーションのみを相手にすることで、XML を気にせずに済みます。Geronimo には数多くの専用ビルダーがあります。例えば EARConfigBuilder は、Geronimo 専用のデプロイメント・プランと標準の J2EE デプロイメント記述子を処理し、そこから J2EE エンタープライズ・アプリケーションのためのコンフィギュレーションを作る方法を知っています。

図 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 番目のバージョンでも使われます(変更点については注釈を入れています)。

訳註: 円マーク(\)は原文ではバックスラッシュです。


表 1. デプロイ可能アーカイブと、そのデプロイメント記述子と Geronimo デプロイメント・プラン
ファイル名ソースの位置(ディレクトリー)説明
StoreController.javasrcこの MVC スタイル・アプリケーションの、フロント・コントローラーとして動作するサーブレット。このコントローラーは着信リクエストを、このアプリケーションの中にある 2 つの JSP のうちの 1 つにリダイレクトします。また、2 番目 3 番目のバージョンでは、(ReallyBigStore.java を介して間接的に)EJB を通して必要なビジネス・データにアクセスし、それをプレゼンテーション・レイヤーJSP が表示するためのセッション属性として付加します。
ReallyBigStore.javasrcJSP タグ・ライブラリーに対する静的メソッドを提供するユーティリティー・クラス。カテゴリー情報とアイテム情報を取得するヘルパー機能も持っています。最初のバージョンでは独自のデータを生成しますが、後のバージョンでは、情報を取得するために EJB をアクセスします。
bigpetstore.jspjspJSP 2.0 準拠のストアフロント(storefront)実装として、販売可能な全アイテムを表示します。このコードには埋め込みの Java コードが全く含まれていません(スクリプト・フリー)。JSTL(JavaServer Pages Standard Tag Library)とカスタム・タグ・ライブラリーがふんだんに使われています。
checkoutcart.jspjspこの JSP は、注文を確定してチェックアウトするための、買い物かごの骨組み(skeleton)を実装します。このコードはスクリプトレットを全く含んでおらず、JSTL を使っています。
bigpetstore.cssjspアプリケーション中の 2 つの JSP が使用するスタイルシート
bigpetstore-taglib.jarWEB-INF/libアプリケーションが、バックエンド EJB を使わずにアプリケーションにデータを供給するために使用する、カスタムの JSP タグ・ライブラリー。
Product.java, LineItem.java, Category.javasrcペット店の情報を処理するために JSP が使用する JavaBeans

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


図 4. Web モジュールを Geronimo にデプロイする

図 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


Geronimo のマイルストーン・ビルド

正式な 1.0 リリース(そして J2EE 認証)の前に、Geronimo 用のバイナリーがマイルストーン・ビルドとしてリリースされています。マイルストーン・ビルドが新しくなる毎に、より多くの新しい機能が追加されています。マイルストーン・ビルドは、M という文字と、数字で示されます。例えば 3 番目のマイルストーン・ビルドは M3 リリースと呼ばれます。テストや実験用に比較的安定なリリースを入手するためには、マイルストーン・ビルドをダウンロードするのが一番です。どのマイルストーン・ビルドを使う場合でも、どの機能が欠けているか、どの機能が安定でないかを知るために、リリース・ノートを注意深く読んでください。

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 に示します。


リスト 1. ステートレス・セッション bean

<?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 がカテゴリーを表示するために使用します。


リスト 2. 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 にアクセスするコードを示しています。


リスト 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 に示します。


リスト 4. ローカル・セッション bean への参照を持つデプロイメント記述子

<?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>


最新の Geronimo ビルドを入手する

最新の Geronimo ビルドを入手するために一番簡単なのは、Geronimo のサイト(参考文献)から最新の不安定ビルドをダウンロードすることです。あるいは、冒険をいとわず、またバージョン・コントロールに充分な実経験がある人は、リポジトリーからコードをチェックアウトして、本当に最新のバージョンの Geronimo を自分でビルドすることもできます。このプロセスは、科学と言うよりも芸術と言った方が適切かも知れません。このためには、システム上に Subversion や CVS、Maven、Ant などがすべてインストールされ、実行している必要があります(参考文献)。詳細については、Geronimo の正式な wiki にある指示に従って下さい。開発者達は、ほとんど毎日、一日中、コード変更をチェックインしています。もしビルドが失敗したら、後で再度試せば成功するかも知れません。

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


リスト 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 サーバーに対して動作するものです。


リスト 6. CMP2 エンティティーEJB に対してテーブルを作成する SQL スクリプト

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 は、このファイルの一部です。


リスト 7. TranQL JDBC コネクターをデプロイする

<?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. コンフィギュレーションとクラスローダー

図 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)。


リスト 8. CMP2 bean のマッピングと EJB-QL クエリーを示すデプロイメント記述子

<?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 に示します。


リスト 9. デプロイされた TranQL コネクターを参照する Geronimo デプロイメント・プラン

<?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 アプリケーションを示しています。


図 6. JMX を通して公開した、Geronimo がデプロイしたエンタープライズ・アプリケーション

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


図 7. JMX を介して公開されるエンタープライズ・アプリケーション・コンポーネント


まとめ

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



ダウンロード

内容ファイル名サイズダウンロード形式
Source codej-geron2code.zip3.2MBHTTP

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


参考文献

  • このシリーズの第 1 回「J2EE 1.4 エンジンへの道」を読んでください。Geronimo を紹介し、概念的な概要を解説しています。

  • 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 LicenseGeneral 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 プロジェクトは、HOWLJOTMです。

  • 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を見てください。

  • developerWorksblogsに参加して、developerWorks のコミュニティーに加わってください。

  • developerWorks の Java technology ゾーンには、Java プログラミングのあらゆる面に関する記事が豊富に取り揃えられています。

  • Developer Bookstore にはJava 関連の書籍を始め、広範な話題を網羅した技術書が豊富に取り揃えられていますので、ぜひご利用ください。

著者について

Photo of Sing Li

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

不正使用の報告のヘルプ

不正使用の報告

ありがとうございます。 このエントリーは、モデレーターの注目フラグが設定されました。


不正使用の報告のヘルプ

不正使用の報告

不正使用の報告の送信に失敗しました。


developerWorks: サイン・イン


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 利用条件

 


お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。 プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。 お客様の姓名(非表示設定にしていない限り)とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

表示名をお選びください

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

(半角英数字で3文字以上31文字以下にする必要があります)


「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 利用条件

 


この記事を評価する

コメント

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Java technology, Open source
ArticleID=218887
ArticleTitle=Geronimo!: 第 2 回 野生の J2EE 1.4 を使いこなす
publish-date=05242005