Japan [変更]

目次:
	はじめに
	新しい内容
	カスタム・サーバー・アセンブリー
	デプロイメント・プラン作成ウィザード
	GShell
	エキスパート・モード
	Monitoring コンソール・プラグイン
	WADI クラスタリング
	Community Edition Eclipse プラグイン
	その他の機能強化
	まとめ
	参考文献
	著者について
	記事の評価

関連リンク
	WebSphere 記事一覧
	Open source 記事一覧

developerWorks Japan > WebSphere | Open source >

WebSphere Application Server Community Edition V2.1 の新しい機能

ページオプション

JavaScript を要するドキュメントオプションは表示されません

原文はこちら

レベル: 初級

Ashish Jain, Software Engineer, IBM

2008年 07月 29日

この記事では、WebSphere® Application Server Community Edition V2.1 の新しい機能を紹介します。このリリースには、GShell を使ってGeronimo コマンドを実行する機能や、複数のサーバー・アセンブリーを独自のサーバー・セットから作成する機能、そしてエキスパート・モードと新しい Monitoring ポートレットを使ってサーバーを完全に制御する機能などが新たに加わりました。すでに指折りの強力さを誇るオープンソースのアプリケーション・サーバーがさらに改善されています。

はじめに

Community Edition V2.1 を今すぐダウンロード!
IBM WebSphere Application Server Community Edition V2.1 は使用するのもデプロイするのも無料です。今すぐダウンロードしてください。

使いやすさと有用性の改善を重点に、IBM では WebSphere Application Server Community Edition (以降、Community Edition とします) の新しいリリースを発表しました。この Community Edition V2.1 に満載された新しい機能は、最も強力な Java™ EE5 アプリケーション・サーバーの 1 つとしての Community Edition の地位をさらに確固たるものにします。それでは、Community Edition の最新リリースに盛り込まれた新機能をひととおり見て行きましょう。

Community Edition は、Java EE5 (Java Platform Enterprise Edition 5) 完全準拠のアプリケーション・サーバーで、そのベースとなっているのは Apache Geronimo V2.1.1 です。この記事では、カスタム・サーバー・アセンブリー、デプロイメント・プラン作成ウィザード、GShell、拡張管理コンソール、Global JNDI サポートなど、Community Edition の新しいリリースに新たに追加された多数の機能をひととおり紹介します。新規リリースには新しいユーザー向け開発ガイドも含まれているので、アプリケーションを一層簡単に開発、デプロイ、実行できるようになっています。

上に戻る

新しい内容

Community Edition V2.1 には、以下の新機能が組み込まれています。

カスタム・サーバー・アセンブリー: 各アプリケーションに必要な機能コンポーネントだけが含まれるサーバー・アセンブリーを作成できます。
デプロイメント・プラン作成ウィザード: Web アプリケーションに適切なデプロイメント・プランを作成できるように支援する、管理コンソール (Administrative Console) のメニューです。
GShell: Geronimo コマンドを実行するためのコマンドライン処理環境です。GShell は拡張可能な環境で、編集、コマンド履歴、そしてタブ補完機能のサポートが組み込まれています。
エキスパート・モード: 上級ユーザーが Community Edition サーバー上で実行中のプロセスを完全に制御できるようにします。デフォルトでは重要なプロセスの変更はできないようになっていますが、この新しいモードを使えばデフォルト設定を変更することができます。
Monitoring コンソール・プラグイン: Geronimo 管理コンソールに監視機能のサポートを提供します。このモニター・コンソールでは複数の Geronimo サーバーから統計およびパフォーマンス・データを収集し、収集したデータをユーザーにグラフィカルに表示することができます。
WADI クラスタリング: WADI (Web Application Distribution Infrastructure) を使用して、Tomcat Web コンテナーを用いた Geronimo 構成の Web アプリケーションのクラスタリングをサポートできるようになりました (Jetty の WADI サポートは以前のリリースから含まれています)。さらに、管理用に定義した Geronimo サーバーのグループにアプリケーションをデプロイすることも可能になっています。
Community Edition Eclipse プラグイン: Eclipse プラグインは現在、EMF (Eclipse Modeling Framework) ではなく JAXB (Java Architecture on XML Binding) を使用するようになっています。
その他の機能拡張: Community Edition には、新しいルック・アンド・フィールやその他のユーザビリティーの改善、コンポーネント・ベースの管理コンソール、そしてさらに多くのデータベースとオペレーティング・システムのサポートが追加されています。これらの機能拡張については、記事の終わりで説明します。

Community Edition V2.1 には、表 1 に記載するように新しいコンポーネントおよびモジュールが含まれています。表内では、これらの新規モジュールが太字で示されています。

コンポーネント	V2.0	V2.1
表 1. Community Edition V2.0 と V2.1 のモジュールの比較
activeio-core	3.0.0 インキュベーター	3.0.1
activemq-core	4.1.1	4.1.2
activemq-ra	4.1.1	4.1.2
annogen	0.1.0	0.1.0
ant	なし	1.7.0
ant-launcher	なし	1.7.0
asm	2.2.3	2.2.3
asm-commons	2.2.3	2.2.3
aspectjrt	なし	1.5.3
axiom	1.2.5	1.2.5
axiom-api	1.2.5	1.2.5
axiom-dom	1.2.5	1.2.5
axiom-impl	1.2.5	1.2.5
axis	1.4	1.4
axis2	1.3	1.3
axis2-adb	1.3	1.3
axis2-java2wsdl	1.3	1.3
axis2-jaxws	1.3	1.3
axis2-jaxws-api	1.3	1.3
axis2-kernel	1.3	1.3
axis2-metadata	1.3	1.3
axis2-saaj	1.3	1.3
backport-util-concurrent	2.2	2.2
bcel	5.2	5.2
castor	1.0.5	1.0.5
catalina	6.0.13	6.0.16
catalina-ha	6.0.13	6.0.16
cglib- nodep	2.1_3	2.1_3
Commons- beanutils	1.7.0	1.7.0
Commons- cli	1.0	1.0
Commons- codec	1.3	1.3
Commons- collections	3.2	3.2
Commons- digester	1.8	1.8
Commons- discovery	0.4	0.4
Commons- el	1.0	1.0
Commons- fileupload	1.1.1	1.1.1
Commons- httpclient	3.0.1	3.0.1
Commons- io	1.2	1.2
Commons- jexl	1.1	1.1
Commons- lang	2.3	2.3
Commons- logging	1.0.4	1.0.4
Commons- logging- api	なし	1.0.4
coyote	6.0.13	6.0.16
derby	10.2.2.0	10.2.2.0
derbyclient	10.2.2.0	10.2.2.0
derbynet	10.2.2.0	10.2.2.0
derbytools	10.2.2.0	10.2.2.0
dwr	1.1.4	2.0.3
geronimo-activation_1.1_spec	1.0	1.0.2
geronimo-annotation_1.0_spec	1.1	1.1.1
geronimo-connector	2.0.1	2.1.1
geronimo-ejb_3.0_spec	1.0	1.0.1
geronimo-el_1.0_spec	1.0	1.0.1
geronimo-j2ee-connector_1.5_spec	1.1.1	2.0.0
geronimo-j2ee-management_1.1_spec	1.0	1.0.1
geronimo-jacc_1.1_spec	1.0	1.0.1
geronimo-javaee-deployment_1.1MR3_spec	1.0	1.0
geronimo-javamail_1.4_mail	1.2	1.4
geronimo-jaxr_1.0_spec	1.1	2.0.0
geronimo-jaxrpc_1.1_spec	1.1	2.0.0
geronimo-jms_1.1_spec	1.1	1.1.1
geronimo-jpa_3.0_spec	1.1	1.1.1
geronimo-jsp_2.1_spec	1.0	1.0.1
geronimo-jta_1.1_spec	1.1	1.1.1
geronimo-saaj_1.3_spec	なし	1.0.0
geronimo-schema-j2ee_1.4	1.2	1.2
geronimo-schema-jee_5	1.1	1.1
geronimo-servlet_2.5_spec	1.1	1.2
geronimo-stax-api_1.0_spec	1.0	1.0.1
geronimo-transaction	2.0.1	2.1.1
geronimo-ws-metadata_2.0_spec	1.1.1	1.1.2
groovy-all-minimal	なし	1.5.6
gshell-bootstrap	なし	1.0-alpha-1
gshell-builtins	なし	1.0-alpha-1
gshell-cli	なし	1.0-alpha-1
gshell-command-api	なし	1.0-alpha-1
gshell-core	なし	1.0-alpha-1
gshell-embeddable	なし	1.0-alpha-1
gshell-maven-plugin	なし	1.0-alpha-1
gshell-remote-client	なし	1.0-alpha-1
gshell-remote-common	なし	1.0-alpha-1
gshell-remote-server	なし	1.0-alpha-1
gshell-whisper	なし	1.0-alpha-1
gshell-bootstrap	なし	1.0-alpha-1
gshell-builtins	なし	1.0-alpha-1
gshell-cli	なし	1.0-alpha-1
gshell-command-api	なし	1.0-alpha-1
gshell-core	なし	1.0-alpha-1
gshell-embeddable	なし	1.0-alpha-1
gshell-maven-plugin	なし	1.0-alpha-1
howl	1.0.1-1	1.0.1-1
httpcore	4.0-alpha5	4.0-alpha5
geroimo-interceptor_3.0_spec	1.0	1.0.1
jasper	6.0.13	6.0.16
jasper-el	6.0.13	6.0.16
jasper-jdt	6.0.13	6.0.16
jaxb-api	2.0	2.0
jaxb-impl	2.0.5	2.0.5
jaxb-xjc	2.0.5	2.0.5
jaxen	1.1-beta-10	1.1-beta-11
jaxws-rt	2.0	2.0
jaxws-tools	2.0	2.0
jcl104-over-slf4j	なし	1.4.3
jline	なし	0.9.94
jstl	1.2	1.2
juddi	0.9rc4	0.9rc4
juli	6.0.13	6.0.16
juli-adapters	6.0.13	6.0.16
log4j	1.2.14	1.2.14
myfaces-api	1.2.0	1.2.2
myfaces-impl	1.2.0	1.2.2
neethi	2.0	2.0
ognl	2.6.9	2.6.9
openejb	3.0-beta-1	3.0
openejb-axis	3.0	3.0
openejb-client	3.0	3.0
openejb-core	3.0	3.0
openejb-ejbd	3.0	3.0
openejb-javaagent	3.0	3.0
openejb-jee	3.0	3.0
openejb-loader	3.0	3.0
openejb-server	3.0	3.0
openjpa	1.0.0	1.0.2
pluto	1.0.1	1.1.6
pluto-container	なし	1.1.6
pluto-descriptor-api	なし	1.1.6
pluto-descriptor-impl	なし	1.1.6
pluto-portal-driver	なし	1.1.6
pluto-portal-driver-impl	なし	1.1.6
pluto-taglib	なし	1.1.6
tranql-connector-db2-xa	1.3	1.4
scout	1.0rc1	1.0rc1
serp	1.11.0	1.11.0
slf4j-api	なし	1.4.3
slf4j-jcl	なし	1.4.3
slf4j-log4j12	なし	1.4.3
swizzle-stream	1.0.1	1.0.1
tomcat	6.0.13	6.0.16
tranql	1.3	1.4
tranql-connector-derby-client-local	1.3	1.4
tranql-connector-derby-client-xa	1.3	1.4
tranql-connector-derby-embed-local	1.3	1.4

上に戻る

カスタム・サーバー・アセンブリー

Community Edition をダウンロードしたデフォルトの状態は、完全準拠の Java EE5 認証サーバー・アセンブリーです。ビジネス要件によっては、サーバー全体ではなく、その一部だけが必要なこともあります。例えば Web 層だけで構成されるアプリケーションに必要なのは Tomcat のみなので、OpenEJB、Active MQ などの他のモジュールは除外したいという場合があります。今まで、カスタム・サーバーの抽出はビルド時の操作でしたが、Community Edition V2.1 では実行時に、既存のサーバーのスナップショットをカスタマイズできるようになっています。カスタム・サーバーを抽出するには、以下の 2 つの方法があります。

アプリケーション中心: アプリケーションを正常に実行するために必要な 1 つ以上のプラグインを選択します。
機能中心: 開発環境に必要な一連の機能を選択します。

カスタム・サーバーを作成する方法については次のセクションで詳しく説明しますが、その前に、Community Edition の基本的なアーキテクチャーを理解する必要があります。Community Edition が提供するアーキテクチャーは、サーバーを完全にプラグインだけからアセンブルするプラグイン・アーキテクチャーです。Community Edition に含まれるすべてのモジュールはプラグインであり、それぞれのプラグインには関連する依存関係があります。そのため、アセンブルされたサーバーでは、そのサーバーが動作するのに必要なすべてのプラグインがあることを確認しなければなりません。

この記事のサンプルでは、アプリケーション中心の方法を用いてカスタム・サーバーのコンテンツを定義します。ここで使用しているのは、既存の Community Edition サンプル (Community Edition ダウンロードに付属) に含まれる jsp-examples-war です。カスタム・サーバー・アセンブリーを作成するには、以下のステップに従います。

アプリケーションのデプロイメント・プランを変更します。このステップが必要となるのは、このサンプルのデプロイメントのデフォルト設定では、アプリケーションを WAR としてインストールしますが、Community Edition はプラグインを CAR として認識するためです。そこで、デプロイメント・プランに <dep:type>car</dep:type> タグを追加します。
サンプル jsp-examples-war を Community Edition V2.1 にデプロイします。
ブラウザーで http://localhost:8080/jsp-examples/ を指定してアプリケーションを立ち上げ、機能を確認します。
次に、このアプリケーションに必要な機能コンポーネントと依存関係を特定します。このステップは、管理コンソールで Dependency Viewer ポートレットを使用すると簡単です。ブラウザーで http://localhost:8080/console/ を指定して管理コンソールを起動してください。
デフォルトのユーザー名として system を、パスワードには manager を使用してログインします。
Debug Views 配下の Dependency Viewer ポートレット (図 1 に記載) を起動します。

図 1. 管理コンソール内の Dependency Viewer ポートレット
Web アプリケーションはすでにデプロイされているので、WebModule を選択します。WebModule 配下で org.apache.geronimo.applications.examples/geronimo-jsp- examples/2.1.0.0/car -> dependencies を選択すると、Web アプリケーションに必要なさまざまな依存関係が表示されます (図 2 を参照)。

図 2. jsp-examples-war アプリケーションの依存関係
最小限のサーバーを稼動するには、起動と停止、その他の機能のための geronimo-boilerplate-minimal プラグインを組み込む必要もあります。

これで、カスタム・サーバーに必要な依存関係を特定できたので、このすべての依存関係からカスタム・サーバーをアセンブルします。

管理コンソールで、Applications 配下にある Plugins を選択します (図 3 を参照)。

図 3. 管理コンソール内の Plugins ポートレット
表示された画面で Assemble a server をクリックします。次に表示された画面では、groupId フィールドに org.apache.geronimo.customserver と入力し、artifactId フィールドに TestServer と入力します (図 4 を参照)。

図 4. アセンブルされるサーバーの成果物
Plugins in local server の下に表示されたリストから以下のプラグインを選択し、Assemble をクリックします。
- com.ibm.wasce.assemblies/wasce-boilerplate-minimal/2.1.0.0/jar
- org.apache.geronimo.applications.examples/geronimo-jsp-examples/2.1.0.0/car
- org.apache.geronimo.configs/axis/2.1.1/car
- org.apache.geronimo.configs/axis2/2.1.1/car
- org.apache.geronimo.configs/j2ee-corba-yoko/2.1.1/car
- org.apache.geronimo.configs/jasper/2.1.1/car
- org.apache.geronimo.configs/openjpa/2.1.1/car
- org.apache.geronimo.configs/tomcat6/2.1.1/car
図 5. プラグインの選択
次に表示される画面 (図 6) に、カスタム・サーバーに組み込むすべてのプラグインがリストアップされるので、Install をクリックします。

図 6. カスタム・サーバーに組み込む全プラグインのリスト
次の画面 (図 7) に、サーバーのアセンブルが成功したことを示すメッセージが表示されるはずです。このメッセージには、カスタム・サーバーの場所も示されています (このサンプルの場合は、<WASCE_HOME>/var/temp/assembly です)。Done をクリックしてください。

図 7. サーバーのアセンブリーに成功したことを示す画面
次に必要なのは、アセンブルされたサーバーをテストすることです。既存のサーバーをシャットダウンして、<WASCE_HOME>\var\temp\assembly\bin\startup.bat から新しいサーバーを起動します。
最後に、ブラウザーで http://localhost:8080/jsp-examples/ を指定してアプリケーションを起動します。

アセンブルしたサーバーは最小構成のサーバーなので、管理コンソールにはグラフィカル・ユーザー・インターフェースが表示されないことに注意してください。

参考のために、このカスタム・サーバーに組み込めるプラグインを以下にリストアップします。

org.apache.geronimo.plugins/console-tomcat/2.1.1/car: GUI ベースの管理コンソール
org.apache.geronimo.plugins/sysdb-console-tomcat/2.1.1/car: 管理コンソールに組み込まれる GUI ベースの Database ポートレット
org.apache.geronimo.plugins/debugviews-console-tomcat/2.1.1/car: 管理コンソールに組み込まれる GUI ベースの Debug Views ポートレット
org.apache.geronimo.plugins/activemq-console-tomcat/2.1.1/car: 管理コンソールに組み込まれる GUI ベースの JMS コンソール
org.apache.geronimo.plugins/plancreator-console-tomcat/2.1.1/car: 管理コンソールに組み込まれる GUI ベースの Deployment Plan Creator ポートレット

この例からわかるように、カスタム・サーバーは、モジュール式の拡張可能な Geronimo プラグイン・アーキテクチャーの利点をさらに生かした強力な機能です。この機能によって、実行中の既存サーバーからありとあらゆるタイプのサーバーを簡単にアセンブルすることができます。

上に戻る

デプロイメント・プラン作成ウィザード

サーバー特有のデプロイメント・プラン (geronimo-web.xml など) を簡単に作成できるようにするため、Community Edition の管理コンソールには Plan Creator という新しいポートレットが組み込まれるようになりました。Plan Creator は Web アプリケーション・アーカイブ (WAR) を使用して、ユーザーに geronimo-web.xml ファイルの自動生成手順をガイドします。ただし、EAR と EJB-JAR からの geronimo-application.xml および openejb-jar.xml の作成はまだサポートしていません。

以下に、デプロイメント・プラン作成機能に含まれる卓越した機能の一部を紹介します。

Web アプリケーションで宣言されている EJB、ローカル EJB、JDBC 接続プール、JMS 接続ファクトリー、JMS 宛先、JavaMail セッションおよび Web サービスの参照は自動検出されます。サーバー環境内で使用可能なリソースをリストアップすることによって、これらの参照を解決してリソースとリンクさせることができます。
上記の参照のうち、アノテーションによって Java クラス内で宣言されている参照も同じく自動検出されます。
セキュリティーを簡単に構成することができます。

上記について、これから Community Edition のサンプルとして用意された jsp-examples-war アプリケーションを使って説明します。

jsp-examples-war-2.1.0.0.warで、WEB-INF の下のアプリケーション・アーカイブに含まれる Web アプリケーション・デプロイメント・プラン (geronimo-web.xml) を見つけます。
現在のデプロイメント・プランは、リスト 1 のようになっています。

リスト 1. デプロイメント・プラン geronimo-web.xml

  <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-2.0"
         xmlns:sec="http://geronimo.apache.org/xml/ns/security-1.2"
         xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2">

  <dep:environment>
    <dep:moduleId>
      <dep:groupId>org.apache.geronimo.applications.examples</dep:groupId>
      <dep:artifactId>geronimo-jsp-examples</dep:artifactId>
      <dep:version>2.1.0.0</dep:version>
    </dep:moduleId>
    <dep:dependencies/>
    <dep:hidden-classes/>
    <dep:non-overridable-classes/>
  </dep:environment>
  
  <context-root>/jsp-examples</context-root>
  <!--<context-priority-classloader>false</context-priority-classloader>-->
  <security-realm-name>geronimo-admin</security-realm-name>
  <sec:security>
      <sec:default-principal>
          <sec:principal class="org.apache.geronimo.security.realm.providers.
                         GeronimoUserPrincipal" name="anonymous"/>
      </sec:default-principal>
      <sec:role-mappings>
          <sec:role role-name="tomcat">
              <sec:principal class="org.apache.geronimo.security.realm.providers.
                          GeronimoGroupPrincipal"name="admin"/>
          </sec:role>
      </sec:role-mappings>
  </sec:security>
</web-app>

jsp-examples-war-2.1.0.0.war アーカイブから、上記のデプロイメント・プランを削除します。
Community Edition 管理コンソールを起動して、デフォルトのユーザー名とパスワードを使ってログインします。
Applications 配下の Plan Creator を選択します (図 8 を参照)。

図 8. 管理コンソール内の Plan Creator ポートレット
表示された画面で Browse をクリックし、jsp-examples-war-2.1.0.0.war を選択したら、Configure をクリックします (図 9 を参照)。

図 9. デプロイメント・プランを作成する際の Web アーカイブの選択
次に表示される画面には、使用している環境に合った Web アプリケーション ID とクラス・パス構成が提示されます。Web Context Root は PlanCreatorTest に設定してください。残りの値はデフォルトのままにして (図 10 を参照)、Next をクリックします。

図 10. Web アプリケーション ID およびクラス・パスの構成
次に表示される画面には、セキュリティー・レルムとセキュリティー・ロールをマッピングするための構成が表示されます。role1 フィールドは Principal を選択します。すると、Name フィールドと Class フィールドが現れるので、TestUser という名前を指定し、クラスには User Principal を選択し (図 11 を参照)、Add をクリックします。

図 11. クラスの選択

すると、Principals の下にデプロイメント・プランに追加した内容で Name と Class が表示されます (図 12 を参照)。

図 12. role1 のロールのマッピングの構成
次に、tomcat フィールドで Principal を選択します。Name フィールドに TestGroup と入力し、Class フィールドには Group Principal を選択してから、Add をクリックします (図 13 を参照)。

図 13. tomcat のロールのマッピングの構成

すると、Principals の下にデプロイメント・プランに追加した内容で Name と Class が表示されます。そのまま Next をクリックしてください。
すると、アプリケーションに対して指定する必要のある依存関係を選択する画面が表示されます。このアプリケーションには依存関係がないため、デフォルトの選択をそのまま使うことにします。ejb、データベース・プール、jms リソースなどの依存関係を選択することもできますが、これらの依存関係は必須ではありません。そのまま Next をクリックしてください。
次に表示される画面には、生成されたデプロイメント・プランが表示されます。このデプロイメント・プランはリスト 2 のとおりです。

リスト 2. 生成されたデプロイメント・プラン

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1">
    <dep:environment xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2">
        <dep:moduleId>
            <dep:groupId>default</dep:groupId>
            <dep:artifactId>jsp-examples-war-2.1.0.0</dep:artifactId>
            <dep:version>1.0</dep:version>
            <dep:type>war</dep:type>
        </dep:moduleId>
    </dep:environment>
    <context-root>PlanCreatorTest</context-root>
    <security-realm-name>geronimo-admin</security-realm-name>
    <app:security xsi:type="sec:securityType" 
                    xmlns:sec="http://geronimo.apache.org/xml/ns/security-2.0" 
                    xmlns:app="http://geronimo.apache.org/xml/ns/j2ee/application-2.0" 
                    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <sec:role-mappings>
            <sec:role role-name="role1">
                <sec:principal name="TestUser " class=
                   "org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal"/>
            </sec:role>
            <sec:role role-name="tomcat">
                <sec:principal name="TestGroup " class=
                   "org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"/>
            </sec:role>
        </sec:role-mappings>
    </app:security>
</web-app>

Deploy WAR を選択します (図 14 を参照)。

図 14. デプロイメント・プランによる WAR のデプロイメント
Web アプリケーションが正常にデプロイされたことを示すメッセージが表示されます。Launch Web App を選択して Web アプリケーションを起動します (図 15 に参照)。

図 15. Web アプリケーションの起動
図 16 を見るとわかるように、このアプリケーションのコンテキスト・ルートは PlanCreatorTest に設定されていますが、オリジナルのデプロイメント・プラン (Web アプリケーションにパッケージ化されていたもの) のコンテキスト・ルートは jsp-examples でした。

図 16. コンテキスト・ルート PlanCreatorTest で起動したアプリケーション

上に戻る

GShell

GShell は、リッチなコマンドライン・アプリケーションを作成するためのフレームワークです。コマンドライン処理環境である GShell では、ほとんどの Community Edition コマンドを実行することができます。表 2 に記載するとおり、GShell にはさまざまなコマンドがあります。

コマンド	内容
表 2. Gshell コマンド
help または ?	ヘルプ情報を表示
echo または print	引数を STDOUT に出力
source または .	ファイルまたは URL を現行のシェルにロード
clear	端末画面をクリア
set	変数を設定
unset	変数を設定解除
exit または quit	GShell を終了
geronimo/start-server	サーバーを起動
geronimo/stop-server	サーバーを停止
geronimo/wait-for-server	サーバーの起動を待機
geronimo/start-client	アプリケーション・クライアントを起動
deploy/connect	WASCE サーバーに接続
deploy/disconnect	WASCE サーバーを切断
deploy/deploy	モジュールをデプロイ
deploy/redeploy	モジュールを再デプロイ
deploy/undeploy	モジュールをアンデプロイ
deploy/distribute	モジュールを配布
deploy/start	モジュールを起動
deploy/restart	モジュールを再起動
deploy/stop	モジュールを停止
deploy/list-modules	モジュールをリストアップ
deploy/list-targets	ターゲットをリストアップ
deploy/list-plugins	プラグインをサーバーにインストール
deploy/install-library	ライブラリーをインストール
deploy/install-plugin	プラグインをインストール
deploy/assemble	WASCE サーバーを現行のサーバーから抽出

それでは GShell の使用例を見てみましょう。Community Edition には、GShell を起動するためのバッチ・ファイル、gsh.bat が <WASCE_HOME>/bin に用意されています。この gsh.bat ファイルをコマンド・プロンプトから実行して GShell を起動してください (図 17 を参照)。

図 17. GShell の起動

GShell を使用してサーバーを起動するには、geronimo/start-server コマンドを入力します (図 18 を参照)。

図 18. GShell によるサーバーの起動

サーバーにデプロイされたモジュールをリストアップするには、deploy/list-modules コマンドを入力します。デフォルトのユーザー名とパスワードを入力してください (図 19 を参照)。

図 19. サーバーにデプロイされたモジュールのリスト

上に戻る

エキスパート・モード

Community Edition 管理コンソールでは、Applications 配下に表示されている各ポートレット (WebAppWARs、System Modules、Application EARs、EJB JARs、J2EE Connectors、App Clients) に、さまざまなモジュール (Web アプリケーション・モジュール、システム・モジュール、エンタープライズ・アプリケーション・モジュール、EJB モジュール、コネクター・モジュール、アプリケーション・クライアント) が表示されます。モジュールの起動、停止、再起動、アンインストールはポートレットから実行するわけですが、デフォルトのコンソールでは、一部のモジュールに対する起動、停止、再起動、アンインストール操作はグレー・アウトされていて使用できません。

エキスパート・モードでは、上級ユーザーが Community Edition サーバーで実行中のプロセスをより自由に制御することができます。デフォルトでは重要なプロセスを変更することはできませんが、エキスパート・モードを選択すると、同じプロセスでも完全に制御することが可能になります。このモードは上述のすべてのポートレットに組み込まれています。以下の例で、Community Edition のエキスパート・モードを使用する方法を説明します。

管理コンソールを起動し、デフォルトのユーザー名とパスワードを使ってログインします。
Applications 配下の WebAppWARs を選択します。図 20 に示されているように、一部のモジュールについては停止、再起動、アンインストールといったコマンドはグレー・アウトされています。

図 20. WebAppWARs ポートレットのデフォルト表示
Installed Web Applications 画面の左上にある Expert User のチェック・ボックスにチェック・マークを付けます。すると、グレー・アウトされていたコマンドが使用できるようになります (図 21 を参照)。これで、サーバーにインストールされたすべてのモジュールを完全に制御できるようになります。

図 21. Expert User を有効にした後の WebAppWARs ポートレット

上に戻る

Monitoring コンソール・プラグイン

サーバーの正常性は重要です。そのため、実行中のあらゆるアプリケーションではサーバーのクラッシュを前もって予測することが欠かせません。通常、サーバーがクラッシュすると、多くのトラブルシューティング作業と重要なデータの損失という結果に終わります。このような最悪の事態を避けるには、サーバーの正常性を常に監視して、そのパフォーマンスが最適レベルになるようにサーバーを再構成する必要があります。また監視することによって、本番環境の生産性向上にもつながります。この点に対処するために Community Edition V2.1 管理コンソールに新しく統合されたのが Monitoring プラグインです。このプラグインは、以下の統計をはじめ、さまざまな統計を継続的に監視します。

※訳注: 上記段落の最後の文に、Monitoring plug-that という記述がありますが、おそらく Monitoring plug-in that の誤りかと思われます。そのように解釈して訳してあります。

トランザクション・マネージャー
JVM
AJP/Web/WebSSL コネクター
スレッド・プール
Web アプリケーション

ただし、すべてのコンポーネントを監視対象にするのではなく、必要なコンポーネントだけに絞って監視する必要があります。この場合の経験則は十分に確立されています。それは、監視するコンポーネントが多くなればなるほど、サーバーのパフォーマンスに大きな影響が出てくるということです。

Community Edition のデフォルト・インストールには、Monitoring プラグインがすでにデプロイされています。このポートレットは、View、Servers、Graphs の 3 つのペインからなります。以下のサンプルのコンテキストで、それぞれのペインについて説明します。

管理コンソールを起動し、デフォルトのユーザー名とパスワードを使ってログインします。
コンソール・ナビゲーションの Server 配下の Monitoring を選択して、このポートレットを起動します。View、Servers、Graphs ペインが表示されます。右側には +Create View、+Add Server、+Add Graph (図 22 を参照) と表示されており、このそれぞれを使って新しいビュー、サーバー、グラフを追加します。

図 22. Monitoring ポートレットのデフォルト表示

Servers

Monitoring プラグインで作業するには、まずその前にサーバーを追加する必要があります。Servers ペインを使って Community Edition の複数のインスタンスを追加すると、複数のマシンを一箇所で監視することができます。Monitoring プラグインでサーバーを追加するには、以下のステップに従います。

Add Server をクリックします (図 23 を参照)。

図 23. Monitoring ポートレットでのサーバーの追加
次に表示される画面では、フィールドを以下のように設定してから (図 24 を参照)、Add をクリックします。
- Name: MyServer
- IP/Hostname: localhost
- Protocol: EJB
- Port: 4201
- Username: system
- Password: manager
図 24. Monitoring ポートレットでのサーバーの構成
Monitoring ポートレットのデフォルト・ビューが再び表示されますが、今度はサーバーが正常に追加されたことをレポートするメッセージが表示されています (図 25 を参照)。また、Servers ペインには MyServer という新しいエントリーも追加されています。現在、クエリーのステータスは stopped となっているので、+Enable Query をクリックしてデータのスナップショット収集を開始します。

図 25. データのスナップショット収集の有効化
クエリーのステータスは現在 Online で、5 分間隔でスナップショットが収集されることになっています。この収集間隔を変更するには、Actions の下にある Edit をクリックします。
こうして表示された画面で Snapshot Duration を 1 分に変更し、Save をクリックします。「Server has been updated (サーバーが更新されました)」というメッセージが表示されるので、Monitoring を選択してポートレットのデフォルト・ビューに戻ります。

図 26. 既存のサーバー構成の編集
Servers ペインで MyServer を選択して、このサーバーがモニターしている各種の統計を表示します。図 27 に、統計を示します。

図 27. MyServer 構成でサーバーが監視中の各種統計

以下に、このページの各種フィールドと機能の詳細を説明します。
- My Server は、現在の構成に関するステータス、サーバーが追加されたタイムスタンプ、サーバーが変更されたタイムスタンプ、IP アドレスまたはホスト名、スナップショット間隔を示します。
- Live Statistics は、現在監視しているさまざまなコンポーネントを示します (上記の例では、JVM、Tomcat AJP Connector、Tomcat Web Connector、Tomcat Web SSL Connector、activemq-console-tomcat などです)。ここには、監視中の 2 つの Web アプリケーション、SimpleJSF と jsp-examples-war-2.1.0.0 も示されています。この表示項目のそれぞれが、各種フィールドに関連付けられています。
- 右側にある Statistics Collected パネルには、各コンポーネントについて現在収集中の統計が示されます。それぞれのフィールドにある × は、コンポーネントの監視を停止するために使用します。
- Statistics Available パネルには、現在監視している構成に含めることのできる各種コンポーネントが示されます。+ を選択するとコンポーネントが Statistics Collected パネルに追加され、これによってサーバーが新しく追加されたコンポーネントに対する監視を開始します。
- Actions パネルには、現在のサーバー監視構成を設定するためのさまざまなオプションが示されています。
同じ画面上で、Live Statistics の下に表示されたリンクのいずれかを選択してみてください。一例として、ここでは TomcatAJPConnector の下にある Busy Threads Max リンクを選択します (図 28 を参照)。

図 28. TomcatAJPConnector の下にある Busy Thread Max の選択
このリンクは、選択したプロパティーのグラフを追加するためのポートレットを起動します (図 29 を参照)。このポートレットでは、デフォルトでいくつかのフィールドが事前に入力されているため、より簡単にグラフを作成することができます。しかし次のセクションでは一からグラフを作成する方法を説明します。

図 29. MyServer 構成を使用したグラフの追加

Graph

このペインでは、カスタマイズしたグラフを作成することができます。また、2 つの統計値の加算、減算、除算、乗算といった数学演算を実行することも可能です。現在の MyServer 構成にグラフを追加するには、以下のステップに従ってください。

Monitoring ポートレットで +Add Graph を選択します (図 30 を参照)。

図 30. グラフの追加
次に表示される画面で以下のようにフィールドを設定してから (図 31 を参照)、Add をクリックします。
- Server: MyServer-localhost
- Name: TomcatAJP_BusyThread
- Description: This is to monitor the Busy thread Max for Tomcat AJP Connector
- X Axis label: Busy Threads
- Y Axis label: Time
- Timeframe: 5
- Mbean: TomcatAJPConnector
- Data series: As-is; Busy Threads Max
- Math operation: none
図 31. グラフを追加するためのフォームの入力
Monitoring ポートレットのデフォルト・ビューに戻ると、グラフが正常に追加されたことをレポートするメッセージが表示されているはずです。追加されたグラフを選択して、グラフを表示します (図 32 を参照)。

F図 32. グラフの表示

View

多種多様なグラフがあることから、Community Edition ではグラフを操作しやすくするために、「ビュー」という概念を使って、関連するグラフをバンドルできるようになっています。例えば、特定のサーバーに関連するすべてのグラフ、あるいは各サーバーのスループットを示すすべてのグラフを 1 つにバンドルすることができます。ビューを作成する方法は以下のとおりです。

Monitoring ポートレットで +Create View を選択します。
次に表示される画面で、新しいビューの名前と説明を入力します。この画面の Graphs フィールドには、現在の構成で使用できるグラフのリストが表示されます。今のところ、グラフは 1 つしか追加していないので、このリストから選択できる項目はこれ以外にありません。この項目のチェック・ボックスにチェック・マークを付けて、構成を保存してください (図 33 を参照)。

図 33. ビューの構成
Monitoring ポートレットのデフォルト・ビューが再表示されるので、MyView を選択して現在の構成を表示すると、追加したグラフが表示されます。

図 34. MyView 構成の表示

上に戻る

WADI クラスタリング

アプリケーション・サーバー・クラスターとは、サーブレットや JSP (JavaServer Pages) サポートなどのエンタープライズ・サービスを、まるで単一のサーバーのごとく透過的に提供するサーバーの集合のことです。通常、これらのサーバーは異なるシステムで稼動するため、メッセージを交換してデータを同期します。このデータ同期により、個々のノードのどれもが、分散アプリケーションに対するリクエストを処理し、アプリケーションのノードに障害が発生した場合にユーザーのセッションを引き継ぐことが可能になります。一般に、複数のサーバーを 1 つのクラスターに構成することをクラスタリングと呼びます。

現在、Community Edition では Apache Tomcat または WADI (Web Application Distributed Infrastructure) によるセッション複製サポートを利用してクラスターを実装します。

Tomcat クラスターにはいくつかの制約事項があります。

ステートフル・セッション EJB (Enterprise JavaBean) を複製しません。そのため、分散アプリケーションではステートフル・セッション EJB を使用しないようにする必要があります。
JNDI (Java Naming and Directory Interface) に対する動的更新を複製しません。クラスターの各ノードで、分散アプリケーションが使用するすべての JNDI 名を構成する必要があります。
クラスター内の他のノードには、分散可能 Web アプリケーションを複製しません。すべてのノードに、分散可能な Web アプリケーションをデプロイする必要があります。

Community Edition V2.1 では、Tomcat クラスターが以下のように改良されています。

複数の Community Edition サーバー間で HTTP セッション状態を複製できるようにするため、Community Edition の Tomcat 構成と併せて WADI を使用できるようになりました。
管理用に定義した Community Edition サーバーのグループにアプリケーションをデプロイできるようになったため、多数の Community Edition サーバー間で単一アプリケーションを管理するのが容易になっています。

Tomcat Web コンテナーを用いた構成に対して、WADI を使用して Web アプリケーションをクラスタリングできるようになりました。これらのコンポーネントをクラスター化する場合、コンポーネントのデプロイメント記述子にはコンポーネント特有の XML 要素が追加されます。この XML 要素が、アプリケーションをデプロイする際にベースとなる WADI のコンポーネントをどのように接続し、セットアップするかを制御する各種のクラスタリング・パラメーターを定義します。

WADI には、ファーミング (farming) という概念もあります。

ファーミングとは、クラスター規模で Web アプリケーションのホット・デプロイメントを行うことです。サーバー・ファームに Web アプリケーションをデプロイするには、アプリケーションの WAR ファイルをクラスター内の 1 つのノードにコピーするだけで済みます。するとファーミングにより、クラスター全体で Web アプリケーションがデプロイされます。同様に、WAR ファイルをクラスター・ノードの 1 つから削除すれば、クラスター内のすべてのノードから Web アプリケーションが削除されます。Community Edition サーバーのクラスターには、単一の論理デプロイメント・ステップによって構成をデプロイすることができます。クラスターにデプロイされた構成は、すべてのクラスター・メンバーに共通して透過的に起動、停止、削除することができます。
ファーム・デプロイメントとは、アプリケーションをクラスターの構成済みメンバーにデプロイすることです。

詳細については、Community Edition のドキュメントのクラスタリングについてのセクションを参照してください。

上に戻る

Community Edition Eclipse プラグイン

Community Edition Eclipse プラグイン (以降、WEP とします) v2.1 では、そのモデル・フレームワークのアーキテクチャーが大々的に変更され、EMF (Eclipse Modelling Framework) ではなく JAXB (Java Architecture on XML Binding) になっています。このような変更が行われた理由は、WEP のデプロイメント・プラン･エディターを大幅に改善できるようにするためです。今後のリリースでは、インテリジェントなエディターが期待できそうです。

また、v2.1 の WEP は軽量化されました。現在、WEP のフットプリントはわずか 5MB で、前のリリースと比べて 13MB も少なくなっています。さらに WEP ではバグがいくつも修正されているため、WEP の使ったエクスペリエンスは一層快適になっています。

上に戻る

その他の機能強化

管理コンソールがコンポーネント・ベースでサーバー機能をミラーリングするようになりました。カスタム・サーバーをアセンブルするときには、選択した機能またはモジュールが使用するポートレットのみが組み込まれます。
Community Edition V2.1 では、IBM DB2 8.2, 9.1 および 9.5 の JDBC ドライバー、ならびに Oracle RAC (Real Application Cluster) がサポートされています。
Red Hat Fedora 9、Ubuntu 8.04 LTS (Long Term Support) に対応するようになった Community Edition V2.1 では、AIX Version 6 Update 1 オペレーティング・システムを推奨しています。Java サポートでは IBM Java 32bit/64 bit SE 5 SR6b が推奨され、Sun Java 32bit SE 5 Update 15 以降にも対応しています。
以下をはじめとする新しいサンプルが追加されました。
- Bank - EJB 3.0 Session Bean、JPA、および OpenEJB のクライアント技術のデモ用
- jms-mdb-sample - EJB 3.0 の Message-Driven Bean のデモ用
- sendmail - Comunity Editionでの Mail Session のデモ用
Community Edition コンソールは新しいルック・アンド・フィールで一新されています。管理コンソールにはユーザー・エクスペリエンスを改善するための機能強化もいくつか適用されています。その 1 つとして、コンソール・ナビゲーションの左ペインにある各種リンクの名前が変更されています。例えば、Server 配下の JVM ポートレットは Java System Info という名前に、Common Libs は Repository という名前に変更され、より使いやすくなっています。
Community Edition V2.1 では多くのコンポーネント・モジュールが更新されています。更新されたモジュールの一覧については、表 1 を参照してください。
Community Edition V2.1 の config.xml には、Tomcat Web、AJP および SSL 属性として使用できる属性がすべて含まれるようになりました。
新しい gbean TomcatClusteringBuilder によって、クラスタリング・サポートが支援されています。Config-substitution.properties も変更され、新しい各種の構成パラメーター (MaxThreadPoolSize、ResourceBindingsQuery、clusterName、ResourceBindingsFormat、TmId) が組み込まれました。

上に戻る

まとめ

よく言われるように、「あらゆる可能性を追求しなければ、真の意味で完成したことにはなりません」。このリリースで追求された新しいオプションは、Community Edition をその完成に一段と近づけています。Community Edition チームの 3 年間にわたる入念な開発、テスト、そしてフィードバック収集がこのリリースに成果として現れていることから、今後の開発でもさらに改善が重ねられるはずです。記事で説明したように、このリリースでは、ユーザーが GShell を使ってすべての Geronimo コマンドを実行することも、独自のサーバー・セットから複数のサーバー・アセンブリーを作成することも、そしてエキスパート・モードと Monitoring ポートレットによってサーバーを完全に制御することもできます。その他にも、Community Edition V2.1 にはアプリケーションを簡単に構成、開発、デプロイ、実行できるようにする数多くの機能が統合されています。この記事では、今回のリリースの要点をかいつまんで説明したにすぎません。「参考文献」セクションに記載したサイトにアクセスして、新機能の詳細を調べてください。この記事は Community Edition V2.1 の調査の始まりにすぎないのです。

参考文献

学ぶために

議論するために

著者について


		Ashish Jain は、IBM WebSphere Application Server Community Edition の Level 3 Technical Support に取り組むソフトウェア・エンジニアです。NITK Surathkal でコンピューター・サイエンスの工学士号を取得した彼は、2005年に ELTP として IBM に入社しました。

記事の評価

この記事を共有する


del.icio.us	newsing	FC2ブックマーク

Choix！	ニフティクリップ	Yahoo!ブックマーク

MM/memo	CZブックマーク	livedoorクリップ

はてなブックマーク	Buzzurl（バザール）

上に戻る

日本IBMについて

プライバシー

お問い合わせ