レベル: 初級 Hemapani Srinath Perera (hemapani@gmail.com), Developer, Lanka Software Foundation
2005年 8月 09日 Apache Software FoundationのオープンソースJ2EE（Java™ 2 Platform,Enterprise Edition）サーバーであるGeronimoは、何十もの技術や概念を統合しています。それらの大部分は独自のプロジェクトであり、それぞれ独自のコンフィギュレーションやデプロイメント・モデルを持っています。Geronimoでは、こうした異種混合のシステムを1つ傘の下にまとめようとしていることから、コンフィギュレーションやデプロイメントに関する様々な手法を、単一の、均質なモデルに集約しています。この記事では、Geronimo開発者であるSrinathPereraが、Geronimoがこうした目標をどのように実現しているかを解説し、また、Geronimoユーザーから見えるものとGeronimoサーバー・アーキテクチャーの下にある概念とを結びつけます。
2003年8月、何十人かのオープンソース開発者が、Apache Software FoundationによるApacheJ2EE Server Projectの旗印の下に集まり、Apache Geronimoが生まれました。Geronimoは、企業用のOS（オペレーティング・システム）として見ることができます。Geronimoは、何十ものオープンソース・プロジェクトを1つのフレームワークにまとめ上げ、エンタープライズ・スタックを提供するために協調させようとしています。
Geronimoは、オープンソース・コミュニティーによる最も複雑なプロジェクトの1つであり、複雑さに関してはLinuxに匹敵するものです。（一部の人達は、オープンソースという活動形態が継続可能なのかどうか、そして、そうした形態によって、こうした高度に複雑なものを扱えるのかのテストとしてGeronimoを見ています。）また、Geronimoの基本的な目標の一つはJ2EE1.4認証を受けることですが、これは非常に時間を要する作業です。こうした困難にもかかわらず、Geronimoは既に幾つかのマイルストーン・リリースを発行しており、魔法の1.0リリースに向かって着実に前進しています。
Geronimoのアーキテクチャー
他の大部分のエンタープライズOSと同様、Geronimoは『カーネル』の上、つまり、すべての構築の基礎をなすマイクロカーネルの上に構築されています。Geronimoのカーネルは、J2EEについては関知しません。Geronimoの構成ブロック（GeronimoBean、略してGBeanと呼ばれます）を管理することだけが、その唯一の目的なのです。
Geronimoの中のほとんど全て、つまりコンテナーやコネクター、そしてアプリケーションなどは、GBeanです。従ってGBeanの粒度も異なります。例えば、Webコンテナー上で実行する小さなサーブレットはGBeanであり、Webコンテナー自体もGBeanです。GBeanは、特に大きなGBeanは、他のGBeanを集約することができます。
 |
GeronimoのGBeanフレームワーク
Geronimoは、『GBean』と呼ばれる構成ブロックから成り立っています。GeronimoカーネルはGBeanに対するコンテナーであり、GBeanのライフサイクルを処理します。GBeanは永続的な状態を持ち、自分たちの間の依存関係を規定することができます。これによる実質的な効果として、Geronimoは、GBeanの上に構築された疎結合システムとなっています。Geronimoにおけるすべてのアクション、つまりサービスの起動、停止、管理、そしてデプロイなどは、GBeanという観点から説明することができます。
|
|
Geronimoのカーネルは、GBeanのライフサイクルと、GBean間の依存関係を管理します。GBeanは状態を保持し、GBean間の依存関係を定義し、ライフサイクル・イベントに反応します。GBeanの状態は、GBeanフレームワークのサポートによって永続的にすることができます。実行中のGeronimoインスタンスは基本的に、実行するGBeanによるメッシュなので、この機能を利用してGeronimoの現在の状態を保存し、後でその状態を回復することができます。この機能は、何らコンフィギュレーション・ファイルを必要としないことから、ユニークなものと言うことができます。ファイルが要らない代わりに、すべての状態はGBeanに保存されます。さらに、管理インターフェースを通してGBeanを管理できるため、オンザフライでGBeanを起動、停止、編集することができます。
GBeanは、ある特定のファイル名パターンに従う他のGBeanが実行していることを知りたい、という関心を登録することができます。そのパターンに一致するGBeanが起動すると、その起動したGBeanへの参照が、関心を登録したGBeanの中に自動的に注入されます。これは依存性注入（dependencyinjection）と言われます。疎結合のシステムを構築する上で、依存性注入はGBeanの強力なツールです。
例えばEJB（Enterprise JavaBeans）コンテナーを表現するGBeanは、EJBを表現するGBeanへの関心を登録することができます。EJBを表現するGBeanが起動すると、カーネルは、それをEJBコンテナーに通知します。GBeanを作る人は、自分たちのGBeanを、関心を持つ他のGBeanに関連付ける必要はありません。関心を登録するだけで充分なのです。あるGBeanが起動すると、それに関心を持つ他のすべてのGBeanには、それが分かるのです。
デプロイメントとコンフィギュレーション
Geronimoのデプロイメント・アーキテクチャーというのは、Geronimo中にデプロイされるJ2EEコンポーネントや非J2EEコンポーネントを表現するGBeanを、どのように作成、起動、停止、保存、取得、削除するのか、を言います。
『コンフィギュレーション』は、鍵となるデプロイメント単位です。コンフィギュレーションというのは、論理的にグループ分けされた、1つ以上のGBeanとクラスローダーの集まりです。コンフィギュレーションは、Geronimoの標準ストレージ機構である、『コンフィギュレーション・ストア』に保存されます。GeronimoはGBeanを、コンフィギュレーション・レベルで管理します。つまりコンフィギュレーションはサーバーで起動し、ユーザーが停止、アンデプロイすることができます。各コンフィギュレーションは、Geronimoディストリビューションの中に物理的な位置を占めており、config-storeと呼ばれるフォルダーの中に置かれています。ディストリビューションに付属してくるコンフィギュレーションは、コア・サービスを表します。新しいアプリケーションがデプロイされると、新しいコンフィギュレーションが作られます。
Geronimoに新しいコンポーネントを追加するには、それがコア・コンポーネントであるかアプリケーションであるかに関わらず、次の4つのステップを踏む必要があります。
- そのコンポーネントの情報と振る舞いをキャプチャーするGBeanを作る
- GBeanに関連付けられたクラスローダーによって、GBeanをコンフィギュレーションへとグループ分けする
- コンフィギュレーションを、コンフィギュレーション・ストアに保存する
- そのコンフィギュレーションを起動する
このプロセスが完了した後は、サーバーが再起動するとコンポーネントの情報は永続的（persist）になります。これは、Geronimoの独特な側面を説明しています。Geronimoディストリビューションには何もデプロイメント記述子がありません。これは、コンフィギュレーションが単純にデプロイメント記述子を置き換えているためです。すべてのデプロイメント情報はGBeanに変換され、コンフィギュレーションとしてグループ分けされ、コンフィギュレーション・ストアに保存されます。図1は、Geronimo内部でGBeanがどのように作られ、実行され、保存されるかを示しています。
図1. Geronimoのデプロイメントとコンフィギュレーションに関するアーキテクチャー
図1から分かるように、GBeanは、次の3つのうちどれか1つの方法で作られます
|
Geronimoの構成ブロック: 開発者の観点とユーザーの観点を比較する
Geronimoの開発者とGeronimoのユーザーは、同じものを、別の観点から見るものです。
開発者は、相互に関連したGBeanが、お互いに通信し合いながら実行しているメッシュ（mesh）を見ています。いったんGeronimoカーネル内部に入ると、それ以外のものは消滅してしまいます。そこにはGBeanとコンフィギュレーションという、2つのものしかありません。（コンフィギュレーションは、GBeanを論理的に集めたものであり、1つの単位として管理され、また1つの単位として保存、取得されます。）非常に抽象的な意味から言うと、GeronimoはGBeanのみから構成されています。コンフィギュレーションでさえ、問題になるのはGBeanが起動するまでのことなのです。
一方、ユーザーが関心を持つのは、J2EEで規定される実体、つまりサーブレットやEJB、データソース、コネクターであり、また下記に挙げるような、コンテナー特有のデプロイメント記述子などです。
- J2EEモジュール: J2EE仕様で定義される、デプロイ可能なソフトウェア単位
- デプロイメント・プラン: Geronimoに対して、モジュールに関する情報をさらに提供するために使用されるXMLファイル
Geronimoデプロイヤーは中間に位置し、J2EEの世界に存在するすべてのものを、Geronimoの世界に変換します（図1）
|
|
-
プランから: 『プラン』は、GBeanのXMLシリアル化です。プランは、Geronimoのコア・コンポーネントをコンフィギュレーションするために使われます。Geronimoの『コンフィギュレーション・ビルダー』は、プランからGBeanを作り、それをコンフィギュレーション・ストアに保存します。これらのプランはGeronimoのソースコードの中に存在していますが、バイナリー・ディストリビューションがビルドされる時にコンフィギュレーションとして読まれ、保存されます。プランはバイナリー・ディストリビューションには含まれません（その時には既に役割を終えているため）。
-
J2EEデプロイメント・モジュールから: Geronimo『デプロイヤー』は、GBeanではないものをGeronimoにデプロイするために、それが表現している情報をキャプチャーするGBeanを作ります。例えば、ejb-jar.xmlファイルと幾つかのクラスを含んだEJBモジュールを考えてみてください。Geronimoデプロイヤーは、このモジュールが表現する情報をキャプチャーするGBeanを作り、そのGBeanをコンフィギュレーション・ストアの中に保存します。
-
プログラム的に: もしプランやデプロイメント・モジュールからGBeanを作れない場合には、プログラム的に作る必要があります。これは一番使われることの少ない選択肢です。
統合の例
Geronimoの中にプロジェクトを統合するための良い例として、EJBコンテナーを統合する場合があります。EJBコンテナーを1つ、あるいは1つ以上のGBeanとしてモデル化し、コンフィギュレーションとしてグループ分けし、コンフィギュレーションをプランとして表現するのです。Geronimoは、そのプランを読み取り、そのコンフィギュレーションを構成、保存し、そして起動します。
EJBコンテナーGBeanは、その中にデプロイされているEJBに関しては分かりませんが、あるEJBのGBean表現に一致するGBeanについての関心を、カーネルに登録します。J2EE開発者がEJBモジュールを作成し、デプロイすると、Geronimoデプロイヤーは、そのEJBモジュールを表現するGBeanを作り、それをコンフィギュレーション・ストアに保存し、そしてそのGBeanを起動します。そのGBeanが起動すると、カーネルはそれをEJBコンテナーGBeanの中に注入します。これは、後者がEJBGBeanに対する関心を登録しているためです。この注入によって、EJBコンテナーにはEJBに関する通知が行われ、そのEJBに向けられたリクエストをEJBコンテナーがサービスできるようになります。
背景で何が行われているのか
このセクションでは、デプロイメント・コマンドが実行される時に、背後で何が行われるかを説明します。ここに示しているコマンドは全て、Geronimoのインストール・ディレクトリーから動作します。次のコマンドでGeronimoサーバーが起動します。
$ java -jar bin/server.jar configuration1 ...
|
このコマンドを発行すると、画面上の出力は、リスト1に示すようなものになります。
リスト1.サーバーの起動
.......
10:56:10,580 INFO [Configuration] Started configuration org/apache/geronimo/System
10:56:10,668 INFO [RMIRegistryService] Started RMI Registry on port 1099
10:56:10,836 INFO [ReadOnlyRepository] Repository root is
file:/home/hemapani/drafts/dev-works/geronimo-1.0-M3/repository/
10:56:10,890 INFO [ConfigurationManagerImpl] Loaded
Configuration geronimo.config:name="org/apache/geronimo/SystemJMS"
...
|
Geronimoは、コンフィギュレーション・ストアからコンフィギュレーションを選択し、それらを1つずつ起動します。それぞれのコンフィギュレーションが、そのコンフィギュレーションに関連付けられたGBeanを起動します。
コンフィフィギュレーションを実行する
コンフィギュレーションを起動するためのコマンドは次のようなものです。
$ java -jar bin/server.jar configuration1 ...
|
これによって、コンフィギュレーションと、それが持つ全ての依存関係が起動します。どんなコンフィギュレーションがあるかは、config-store/index.propertiesを見れば分かりますが、このファイルを変更しないように注意してください。変更すると、インストレーションを破損する可能性があります。このコマンドは、起動中の各コンフィギュレーションの中にある、全てのGBeanを起動します。
モジュールをデプロイする
モジュールをデプロイするためのコマンドは次のようなものです。
$ java -jar bin/deployer.jar deploy YourApplication.ear
|
これによって、EAR（enterprise archive）などのJ2EEモジュールからGBeanが作られます。このコマンドはコンフィギュレーションを作成し、それを、Geronimoディストリビューションのconfig-storeフォルダー内部にGeronimoが作成する新しいフォルダーの中の、コンフィギュレーション・ストアに保存します。新しいコンフィギュレーションが設定されると、このコンフィギュレーションは起動します。
モジュールをアンデプロイする
モジュールをアンデプロイするためのコマンドは次のようなものです。
$ java -jar bin/deployer.jar undeploy module-id |
モジュールに関連付けられたGBeanは停止され、そしてコンフィギュレーション・ストアから削除されます。
サービスをデプロイする
サービスをデプロイするためのコマンドは次のようなものです。
$ java -jar bin/deployer.jar deploy YourService-plan.xml |
このコマンドを使うと、1つ、あるいは1つ以上のカスタムGBeanをデプロイすることができます。このXMLファイルは、GBeanのXMLシリアル化です。このコマンドは、J2EEとは何ら関係が無く、Geronimoにカスタム・サービスをデプロイするために使われます。次のセクションで説明するサンプル・アプリケーションを見ると、この機能が分かるでしょう。
サンプル・アプリケーション
ここまでに説明した概念を実際に示すために、GeronimoのGBeanアーキテクチャーを使って書かれた単純なエコー・サーバーを用意しました。ここではGeronimoのコマンドライン・デプロイメントを使ってサーバーをデプロイします。このアプリケーションは、（J2EEとは何の関係もない）カスタム・コンポーネントを、どのようにGeronimoにデプロイするかを説明するものです。各J2EEアプリケーション・デプロイヤーは、これと同じ機構を使ってJ2EEコンポーネントをGBeanに変換し、コンフィギュレーションとして保存し、そしてそれらを起動するのです。
はじめに
このアプリケーションの実行準備として、次のステップが必要です。
- Geronimoディストリビューションをダウンロードし、自分の好きなディレクトリーの中に解凍します（ApacheのWebサイトのダウンロード・ページへのリンクが参考文献にあります）。ここから先では、このディレクトリーを、Geronimoホーム・ディレクトリー、$GERONIMO_HOMEと呼ぶことにします。
- サンプル・コード（ダウンロードの項を見てください）をダウンロードして解凍します。build.xmlファイルを含んだサンプル・フォルダーが作られます。このサンプル・フォルダーを、Geronimoホーム・ディレクトリーにコピーします。
- Apache Ant（このWebサイトへのリンクが参考文献にあります）をインストールします。
- ディレクトリーをサンプル・ディレクトリーに変更し、$antをタイプして、サンプル・アプリケーションをビルドします。これによってsample.jarファイルがコンパイル、ビルドされ、GERONIMO_HOME/repository/sample/jarsにコピーされます。
サンプルを理解する
GERONIMO_HOME/sample/src/EchoServer.javaには、このエコー・サーバーGBeanの実装があります。このGBeanのコードをリスト2に示します。
リスト2.エコー・サーバーのGBeanコード
public class EchoServer implements GBeanLifecycle {
private static final GBeanInfo GBEAN_INFO;
private final String objectName;
private int port;
private ServerSocket serversocket;
private boolean started = false;
static {
GBeanInfoBuilder infoFactory =
new GBeanInfoBuilder(EchoServer.class.getName(), EchoServer.class);
// attributes
infoFactory.addAttribute("objectName", String.class, false);
infoFactory.addAttribute("port", int.class, true);
// operations
infoFactory.setConstructor(new String[] { "objectName", "port" });
GBEAN_INFO = infoFactory.getBeanInfo();
}
public EchoServer(String objectName, int port) {
this.objectName = objectName;
this.port = port;
}
public void doStart() throws WaitingException, Exception {
//code to start the echo server
}
public void doStop() throws WaitingException, Exception {
//code to stop the echo server
}
.....
}
|
リスト3は、$GERONIMO_HOME/sample/echo-server. xmlファイルを示しています。このファイルは、Geronimoにエコー・サーバーをデプロイするためのプランです。
リスト3.エコー・サーバーのデプロイメント・プラン
<?xml version="1.0" encoding="UTF-8"?>
<configuration
xmlns="http://geronimo.apache.org/xml/ns/deployment"
configId="deployment/echoserver"
>
<gbean name="geronimo.test:name=echoserver"
class="EchoServer" >
<attribute name="port" type="int">2345</attribute>
</gbean>
<dependency>
<uri>sample/jars/samples.jar</uri>
</dependency>
</configuration>
|
ここで、エコー・サーバーに対するクラスがどこにあるかを説明するport属性と依存関係に特に注意してください。パスは、Geronimoホーム・ディレクトリーのリポジトリー・ディレクトリーに対する相対パスとして与えられています。コンフィギュレーションIDは、コンフィギュレーションを識別するための固有IDです。
Geronimoサーバーを起動する
ディレクトリーを$GERONIMO_HOMEに変更し、Geronimoサーバーを起動します。
$ java -jar bin/server.jar |
エコー・サーバーをデプロイする
別のシェルで、ディレクトリーを$GERONIMO_HOMEに変更し、エコー・サーバーをデプロイします。
$java -jar bin/deployer.jar deploy samples/echo-server.xml |
サービスをデプロイする
デプロイヤーが指示したら、ユーザー名としてsystemを、パスワードとしてmanagerを入力します。
Username: system
Password: manager
Deployed deployment/echoserver
|
サーバー・ウィンドウに表示される出力から、GBeanが起動したことが分かります。要は、エコー・サーバーGBeanでのSystem.out.println()ステートメントを見ればよいのです。これで、エコー・サーバーは立ち上がって実行しています。それをテストするには、Telnetクライアントを使うか、あるいはダウンロードに提供されているテストケースを使います。
その他のコマンド
エコー・サーバーの起動、停止、アンデプロイには、次のコマンドを使うこともできます。
java -jar bin/deployer.jar stop deployment/echoserver
java -jar bin/deployer.jar start deployment/echoserver
java -jar bin/deployer.jar undeploy deployment/echoserver
|
どの場合でも、サーバー・ウィンドウを見れば、どのコンフィギュレーションが起動停止しているのかを含めて、何が起きているかが分かります。
まとめ
ここではGeronimoのデプロイメント・モデルを学びました。このデプロイメント・モデルは、幾つもの異なるオープンソース・プロジェクトを1つにまとめています。Geronimoユーザーは、この記事で説明したような詳細を全て理解している必要はありません。しかし、背後で行われていることまで知ろうという冒険をおかせば、Geronimoのデプロイメント・アーキテクチャーの基礎となっている概念を、より深く理解することができるでしょう。
ダウンロード | 内容 | ファイル名 | サイズ | ダウンロード形式 |
|---|
| Echo server application | sample.zip | 10KB |
FTP |
|---|
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について | 
| | Srinath Pereraは、WebサービスやJ2EE、XML処理技術などに熟練したGeronimoコミッターです。Srinathは、WS-FXやEWS（Enterprise
Web Services）、Axis、Axis 2などのプロジェクトに関するコミッターとして、Apache Web Servicesプロジェクトの中で積極的に活動しています。また、Apache Web
Services Project Management CommitteeでのAxis2代表です。彼の連絡先はhemapani@gmail.comです。
|
記事の評価
| 
