5.6.1 J2EEアプリケーションの入れ替えとは
システムの運用を開始したあとで,J2EEアプリケーションのバージョンアップやメンテナンスを実施するために,J2EEアプリケーションを入れ替えることがあります。
通常,J2EEアプリケーションを入れ替える場合には,J2EEサーバ上で動作しているJ2EEアプリケーションを停止したあと削除し,新しいJ2EEアプリケーションをインポート,デプロイする必要があります。通常のJ2EEアプリケーションの入れ替えの手順を次の図に示します。
通常のJ2EEアプリケーションの入れ替えでは,J2EEアプリケーションを入れ替える間,サービスを停止する必要がありますが,サービスの部分閉塞を使用すると,サービスを停止することなくJ2EEアプリケーションを入れ替えることができます。また,リデプロイ機能やリロード機能を使用すると,通常のJ2EEアプリケーションの入れ替えに比べて,少ない手順で入れ替えができるようになります。
J2EEアプリケーションの入れ替え方法を次の表に示します。
入れ替え方法 |
対象のJ2EEアプリケーション |
|
---|---|---|
アーカイブ形式 |
展開ディレクトリ形式 |
|
サービスの部分閉塞による入れ替え |
○ |
○ |
リデプロイ機能による入れ替え |
○ |
− |
リロード機能による入れ替え |
− |
○ |
それぞれの入れ替え方法について説明します。なお,入れ替え方法の詳細については,「5.6.3 J2EEアプリケーションの入れ替えと保守」を参照してください。
また,J2EEアプリケーションを入れ替えるときに,既存のJ2EEアプリケーションの名前を変更することによって,J2EEアプリケーションの世代も管理できます。
24時間サービス提供が必要なJ2EEアプリケーションを入れ替える場合には,Webアプリケーションのサービスの部分閉塞やCTMの使用によって,サービスを停止しないでJ2EEアプリケーションを入れ替えることもできます。
(1) サービスの部分閉塞による入れ替え
部分的なサービスの閉塞です。サービスを停止することなく,システムをメンテナンスしたいときに使用します。24時間サービス提供が必要なJ2EEアプリケーションを入れ替える場合などには,サービスの部分閉塞によって,サービスを停止することなく,システムをメンテナンスできるようになります。
サービス部分閉塞の実行方法は,J2EEアプリケーションの形態によって異なります。例えば,Webアプリケーションの場合には,入れ替え対象のJ2EEアプリケーションが動作するJ2EEサーバに対して負荷分散機からのリクエストの振り分けを停止し,J2EEアプリケーションを入れ替えます。入れ替えている間は,ほかのJ2EEサーバでリクエストを処理することで,サービスを停止することなくJ2EEアプリケーションを入れ替えられます。
J2EEアプリケーションがWebアプリケーションの場合に,サービス部分閉塞を使用してJ2EEアプリケーションを入れ替える方法については,「5.6.2 Webアプリケーションのサービスの部分閉塞による入れ替え」を参照してください。
- 参考
-
サービス部分閉塞は,CTMを利用して実行することもできます。CTMのスケジュールキューの閉塞を利用してJ2EEアプリケーションを入れ替える方法については,マニュアル「アプリケーションサーバ 機能解説 拡張編」の「3.7 リクエストの閉塞制御」を参照してください。
(2) リデプロイ機能による入れ替え
アプリケーション開発でのテストやシステムの運用中に,修正したJ2EEアプリケーションと動作中のJ2EEアプリケーションを入れ替えたい場合,リデプロイ機能を使用した入れ替えができます。リデプロイとは,少ない手順で高速にJ2EEアプリケーションを入れ替えられるデプロイ方法です。ロジックだけを変更したJ2EEアプリケーションを入れ替えたい場合などに利用できます。ただし,リデプロイ機能を実行できる条件に合わない場合は,通常の手順で入れ替える必要があります。リデプロイ機能を実行できる条件については,マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「18.7 J2EEアプリケーションのリデプロイ」を参照してください。
リデプロイ機能は,アーカイブ形式のJ2EEアプリケーションを入れ替える場合に使用できます。リデプロイ機能による入れ替え手順を次に示します。
リデプロイ機能を使用する場合には,通常のアーカイブ形式のJ2EEアプリケーションの入れ替えと比べて,少ない手順で入れ替えができます。
- 参考
-
リデプロイを実行する前に,JSP事前コンパイル機能を実行しておくことをお勧めします。JSP事前コンパイル機能は,Webアプリケーションに含まれるJSPファイルをデプロイ前にコンパイルし,クラスファイルを生成する機能です。あらかじめ,クラスファイルの生成までを実施しておくので,JSPに最初にリクエストが到着したときのレスポンスタイムおよびWebアプリケーションの開始時間を短縮できます。JSP事前コンパイル機能については,マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.5 JSP事前コンパイル機能とコンパイル結果の保持」を参照してください。
リデプロイ機能については,マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「18.7 J2EEアプリケーションのリデプロイ」を参照してください。
(3) リロード機能による入れ替え
アプリケーション開発でのテストやシステムの運用中に,修正したJ2EEアプリケーションと動作中のJ2EEアプリケーションを入れ替えたい場合,リロード機能を使用した入れ替えができます。展開ディレクトリ形式のJ2EEアプリケーションを構成するファイルを更新した場合に,更新検知やコマンド実行によって,更新したJ2EEアプリケーションをリロードできます。リロード機能を使用することで,少ない手順でJ2EEアプリケーションを動的に入れ替えられるようになります。
リロード機能による入れ替えは,展開ディレクトリ形式のJ2EEアプリケーションを入れ替える場合に使用できます。リロード機能による入れ替え手順を次に示します。
リロード機能を使用する場合には,通常の展開ディレクトリ形式のJ2EEアプリケーションの入れ替えと比べて,少ない手順で入れ替えができます。
リロード機能については,マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「18.8 J2EEアプリケーションの更新検知とリロード」を参照してください。
J2EEアプリケーションの入れ替えと保守については,「5.6.3 J2EEアプリケーションの入れ替えと保守」を参照してください。サーバ管理コマンドの操作については,マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3. サーバ管理コマンドの基本操作」を参照してください。