test

Sun Java System Application Server Enterprise Edition 8.2 管理ガイド

第 2 章 アプリケーションの配備

この章では、Application Server に J2EE アプリケーションを配備 (インストール) する方法について説明します。この章には次の節が含まれています。

配備のライフサイクル

Application Server をインストールしてドメインを起動したら、J2EE アプリケーションとモジュールを配備 (インストール) できます。配備中およびアプリケーションの変更の際、アプリケーションとモジュールには次のような作業を行います。

  1. 初期の配備

    アプリケーションまたはモジュールを配備する前に、ドメインを起動します。

    アプリケーションまたはモジュールを、特定のスタンドアロンサーバーインスタンスまたはクラスタに配備 (インストール) します。アプリケーションとモジュールはアーカイブファイルにパッケージ化されているので、配備中はアーカイブファイル名を指定します。デフォルトでは、デフォルトのサーバーインスタンス server に配備されます。

    サーバーインスタンスまたはクラスタに配備する場合、アプリケーションやモジュールはドメインの中央リポジトリ内に存在し、ターゲットとして配備したクラスタまたはサーバーインスタンスによって参照されます。

    管理コンソール ではなく asadmin deploy コマンドを使用して、ドメインに配備することもできます。アプリケーションやモジュールをドメインだけに配備する場合、アプリケーションやモジュールはドメインの中央リポジトリ内に存在しますが、参照を追加するまでは、サーバーインスタンスまたはクラスタによって参照されません。

    配備は動的です。アプリケーションを使用可能にするために、アプリケーションまたはモジュールの配備後にサーバーインスタンスを再起動する必要はありません。再起動しても、すべての配備アプリケーションとモジュールはそのまま配備され、使用することができます。

  2. 有効化または無効化

    デフォルトでは、配備されているアプリケーションやモジュールは有効になっています。つまり、アクセス可能なサーバーインスタンスやクラスタに配備されている場合、実行可能で、クライアントがアクセスできる状態になっています。アクセスを抑制するには、アプリケーションやモジュールを無効化します。無効化されたアプリケーションやモジュールはドメインからアンインストールされてはいないので、配備後は簡単に有効化できます。

  3. 配備されているアプリケーションやモジュールのターゲットの追加または削除

    配備の完了したアプリケーションやモジュールは、中央リポジトリ内に存在し、複数のサーバーインスタンスやクラスタによる参照が可能になります。最初は、ターゲットとして配備したサーバーインスタンスやクラスタがアプリケーションやモジュールを参照します。

    アプリケーションやモジュールの配備後、それを参照するサーバーインスタンスやクラスタを変更するには、管理コンソールを使用してアプリケーションやモジュールのターゲットを変更するか、または asadmin ツールを使用してアプリケーションの参照を変更します。アプリケーション自体は中央リポジトリに格納されるため、ターゲットを追加または削除すると、さまざまなターゲット上にある同じバージョンのアプリケーションが追加または削除されます。ただし、複数のターゲットに配備されているアプリケーションを、1 つのターゲット上で有効にして、ほかのターゲット上で無効にすることができます。したがって、アプリケーションがあるターゲットによって参照されていても、そのターゲット上で有効にされないかぎり、ユーザーはアプリケーションを使用できません。

  4. 再配備

    配備されているアプリケーションやモジュールを置換するには、これらを再配備します。再配備すると、以前に配備されたアプリケーションやモジュールは配備が自動的に取り消され、新しいアプリケーションやモジュールと置き換えられます。

    管理コンソールから再配備した場合、再配備されたアプリケーションやモジュールはドメインに配備されます。動的再設定が有効になっている場合、アプリケーションやモジュールを参照するスタンドアロンまたはクラスタ化されたすべてのサーバーインスタンスは、自動的に新しいバージョンを受信します。asadmin deploy コマンドを使用して再配備する場合、ターゲットとして domain を指定します。

    本稼動環境では、段階的アップグレードを使用して、処理が中断されない状態でアプリケーションをアップグレードします。

  5. 配備取消し

    アプリケーションまたはモジュールをアンインストールするには、これらの配備を取り消します。

自動配備

自動配備機能を使うと、事前にパッケージ化されたアプリケーションやモジュールを domain-dir/autodeploy ディレクトリにコピーすることで配備できます。

たとえば、hello.war という名前のファイルを domain-dir/autodeploy ディレクトリにコピーします。アプリケーションの配備を取り消すには、autodeploy ディレクトリから hello.war ファイルを削除します。

管理コンソールまたは asadmin ツールを使用して、アプリケーションの配備を取り消すこともできます。この場合、アーカイブファイルはそのままになります。

注 –

自動配備は、デフォルトのサーバーインスタンスにのみ利用可能です。

自動配備機能は、開発環境を対象としています。この機能は、本稼働環境の機能であるセッションの持続性とは互換性がありません。自動配備が有効になっている場合は、セッションの持続性を有効にしないでください。

パッケージ化されていないアプリケーションの配備

この機能は高度な開発者を対象としています。

ディレクトリ配備は、デフォルトのサーバーインスタンス (server) への配備にだけ使用します。クラスタまたはスタンドアロンサーバーインスタンスへの配備には使用できません。

パッケージ化されていないアプリケーションやモジュールを含むディレクトリを、分割ディレクトリと呼ぶことがあります。ディレクトリのコンテンツは、対応する J2EE アーカイブファイルのコンテンツと一致する必要があります。たとえば、ディレクトリから Web アプリケーションを配備する場合、ディレクトリのコンテンツは対応する WAR ファイルと同じになる必要があります。必要なディレクトリコンテンツの詳細については、適切な仕様を参照してください。

分割ディレクトリ内で配備記述子ファイルを直接変更できます。

環境が動的再読み込みを使用するように設定されている場合は、配備されたアプリケーションをディレクトリから動的に再読み込みすることもできます。詳細については、「詳細設定」を参照してください。

配備計画の使用

この機能は高度な開発者を対象としています。

配備計画は、Application Server に固有の配備記述子だけを含む JAR ファイルです。このような配備記述子、たとえば sun-application.xml などについては、『Application Server Developer’s Guide』で説明されています。配備計画は、JSR 88: J2EE Application Deploymentの実装の一部です。配備計画を使用して、Application Server に固有の配備記述子を含まないアプリケーションやモジュールを配備します。

配備計画を使用して配備を行うには、asadmin deploy コマンドの --deploymentplan オプションを指定します。たとえば、次のコマンドは、mydeployplan.jar ファイルによって指定される計画に従って、myrosterapp.ear ファイルのエンタープライズアプリケーションを配備します。


$ asadmin deploy --user admin ---deploymentplan mydeployplan.jar myrosterapp.ear

エンタープライズアプリケーション (EAR) の配備計画ファイルでは、sun-application.xml ファイルがルートとして配置されています。各モジュールの配備記述子は、構文 module-name.sun-dd-name に従って格納されています。sun-dd-name は、モジュールタイプによって異なります。モジュールに CMP マッピングファイルが含まれる場合、ファイルは module-name.sun-cmp-mappings.xml という名前になります。.dbschema ファイルはルートレベルに格納されていて、スラッシュ (/) はシャープ記号 (#) に置き換えられます。次のリストは、エンタープライズアプリケーション (EAR) の配備計画ファイルの構造を示しています。

$ jar -tvf mydeployplan.jar
420 Thu Mar 13 15:37:48 PST 2003 sun-application.xml
370 Thu Mar 13 15:37:48 PST 2003 RosterClient.war.sun-web.xml
418 Thu Mar 13 15:37:48 PST 2003 roster-ac.jar.sun-application-client.xml
1281 Thu Mar 13 15:37:48 PST 2003 roster-ejb.jar.sun-ejb-jar.xml
2317 Thu Mar 13 15:37:48 PST 2003 team-ejb.jar.sun-ejb-jar.xml
3432 Thu Mar 13 15:37:48 PST 2003 team-ejb.jar.sun-cmp-mappings.xml
84805 Thu Mar 13 15:37:48 PST 2003 team-ejb.jar.RosterSchema.dbschema

Web アプリケーションまたはモジュールファイルの配備計画では、Application Server に固有の配備記述子がルートレベルにあります。スタンドアロンの EJB モジュールに CMP Bean が含まれる場合、配備計画には、sun-cmp-mappings.xml ファイルと .dbschema ファイルがルートレベルに含まれます。次のリストでは、配備計画が CMP bean を示しています。

$ jar r -tvf myotherplan.jar
3603 Thu Mar 13 15:24:20 PST 2003 sun-ejb-jar.xml
3432 Thu Mar 13 15:24:20 PST 2003 sun-cmp-mappings.xml
84805 Thu Mar 13 15:24:20 PST 2003 RosterSchema.dbschema

deploytool ユーティリティーの使用

ソフトウェア開発者を対象として設計された deploytool ユーティリティーは、J2EE アプリケーションおよびモジュールをパッケージ化し、配備します。deploytool の使用手順については、『 The J2EE 1.4 Tutorial』を参照してください。

J2EE アーカイブファイルのタイプ

ソフトウェアプロバイダは、アプリケーションやモジュールをアーカイブファイルにパッケージ化します。アプリケーションやモジュールを配備するには、アーカイブファイルの名前を指定します。アーカイブファイルのコンテンツと構造は J2EE プラットフォームの仕様で定義されています。J2EE アーカイブファイルの種類は次のとおりです。

ソフトウェアプロバイダは、アプリケーションを 1 つの EAR ファイルまたは個別の WAR、EJB JAR、およびアプリケーションクライアント JAR ファイルにアセンブルすることが可能です。管理ツールでは、配備ページとコマンドはすべての種類のファイルで同じです。

命名規約

1 つのドメイン内では、配備されているアプリケーションやモジュールの名前が一意である必要があります。

異なるタイプのモジュールが、アプリケーション内で同じ名前を使用できます。アプリケーションが配備されると、個々のモジュールを保持するディレクトリの名前には _jar、_war、および _rar サフィックスが使用されます。アプリケーション内の同じタイプのモジュールは、一意の名前にする必要があります。また、データスキーマのファイル名は、アプリケーション内で一意の名前にする必要があります。

モジュールのファイル名、EAR ファイル名、ejb-jar.xml ファイルの <module-name> 部分に見られるモジュール名、および ejb-jar.xml ファイルの <ejb-name> 部分に見られる EJB 名には、Java パッケージと同様のネーミングスキームを使用することをお勧めします。このパッケージと同様のネーミングスキームの使用により、名前の競合を防げます。このネーミング方法の利点は、Application Server だけでなく、ほかの J2EE Application Server にも当てはまります。

EJB コンポーネントの JNDI 検索名も一意である必要があります。一貫性のあるネーミング規則の確立が役立つ場合があります。たとえば、アプリケーション名とモジュール名を EJB 名に追加するのは、名前を一意にする 1 つの方法です。この場合、mycompany.pkging.pkgingEJB.MyEJB は、アプリケーション pkging.ear にパッケージ化されたモジュール pkgingEJB.jar 内にある EJB の JNDI 名を表します。

パッケージとファイル名に、オペレーティングシステムでは不正なスペースや文字を含めないようにする必要があります。