レベル: 初級 Sing Li (westmakaha@yahoo.com), Author, Wrox Press
2005年 5月 24日 Apache Software FoundationのJ2EE 1.4サーバー・プロジェクトであるGeronimoは、大量にある既存のオープンソース・サービスを統合してJ2EE 1.4準拠を実現しようとしています。この、2回シリーズの第1回では、Geronimoの存在理由や設計ゴール、アーキテクチャー、また中核的な概念や用語などを解説しました。この第2回では、Sing LiがGeronimoの実際を取り上げます。最新のGeronimoディストリビューションを使って、Webアプリケーションやエンタープライズ・アプリケーション、EJB(Enterprise Java™Beans)などをテストし、またデプロイを行います。
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.xml | geronimo-ra.xml | | J2EEクライアント・アプリケーション・アーカイブ(JAR) | application-client.xml | geronimo-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番目のバージョンでも使われます(変更点については注釈を入れています)。
訳註:円マーク(\)は原文ではバックスラッシュです。
表2. Webアプリケーション、『Really Big Pet Store』のコンポーネント
|
ファイル名
|
ソースの位置(ディレクトリー)
|
説明
| | StoreController.java | src | このMVCスタイル・アプリケーションの、フロント・コントローラーとして動作するサーブレット。このコントローラーは着信リクエストを、このアプリケーションの中にある2つのJSPのうちの1つにリダイレクトします。また、2番目3番目のバージョンでは、(ReallyBigStore.javaを介して間接的に)EJBを通して必要なビジネス・データにアクセスし、それをプレゼンテーション・レイヤーJSPが表示するためのセッション属性として付加します。 | | ReallyBigStore.java | src | JSPタグ・ライブラリーに対する静的メソッドを提供するユーティリティー・クラス。カテゴリー情報とアイテム情報を取得するヘルパー機能も持っています。最初のバージョンでは独自のデータを生成しますが、後のバージョンでは、情報を取得するためにEJBをアクセスします。 | | bigpetstore.jsp | jsp | JSP 2.0準拠のストアフロント(storefront)実装として、販売可能な全アイテムを表示します。このコードには埋め込みのJavaコードが全く含まれていません(スクリプト・フリー)。JSTL(JavaServer Pages Standard Tag Library)とカスタム・タグ・ライブラリーがふんだんに使われています。 | | checkoutcart.jsp | jsp | このJSPは、注文を確定してチェックアウトするための、買い物かごの骨組み(skeleton)を実装します。このコードはスクリプトレットを全く含んでおらず、JSTLを使っています。 | | bigpetstore.css | jsp | アプリケーション中の2つのJSPが使用するスタイルシート | | bigpetstore-taglib.jar | WEB-INF/lib | アプリケーションが、バックエンドEJBを使わずにアプリケーションにデータを供給するために使用する、カスタムのJSPタグ・ライブラリー。 | | Product.java, LineItem.java, Category.java | src | ペット店の情報を処理するためにJSPが使用するJavaBeans |
ディストリビューションの中の様々なソースコード・ファイルを調べ、何がどのように動作しているのかを理解する上で、この表2が役立つでしょう。ここでは、このアプリケーションをGeronimoにデプロイして実行する、ということが主題です。図4は、このアプリケーションをデプロイした時に何が起きるかを示しています。
図4. WebモジュールをGeronimoにデプロイする
図4では、ターゲットとするサーバーにモジュールをデプロイするために、Geronimoのデプロイヤー・ツールを使っています(場合によるとGeronimoデプロイメント・プランも使うかも知れません)。サーバーはメタデータをコンフィギュレーション・ストアに、また、実行可能コードをバイナリー・リポジトリーに保存します。これによって、何らかの理由でサーバーが終了させられた場合にも、同じコンフィギュレーションで再起動することができます。
Geronimoのインストール・ディレクトリーに行き、下記のコマンドを入力してGeronimoを起動します。
あるいは、コマンドの後にコンフィギュレーションの名前を追加することによって、特定のコンフィギュレーションを起動することもできます(コンフィギュレーションの定義については、第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 code | j-geron2code.zip | 3.2MB |
FTP |
|---|
参考文献
著者について  | 
|  | Sing LiはWrox Pressから出版されている多数の本の著者で、Professional Apache Tomcat 、Early Adopter JXTA 、Professional Jini などを執筆しています。技術雑誌に頻繁に寄稿しており、P2P発展に関する熱心なエバンジェリスト(伝道者)でもあります。コンサルタント兼ライターであるSingの連絡先はwestmakaha@yahoo.comです。 |
記事の評価
|