5.6.1 J2EEアプリケーションの入れ替えとは
システムの運用を開始したあとで，J2EEアプリケーションのバージョンアップやメンテナンスを実施するために，J2EEアプリケーションを入れ替えることがあります。
通常，J2EEアプリケーションを入れ替える場合には，J2EEサーバ上で動作しているJ2EEアプリケーションを停止したあと削除し，新しいJ2EEアプリケーションをインポート，デプロイする必要があります。通常のJ2EEアプリケーションの入れ替えの手順を次の図に示します。
|
|
![[図データ]](GRAPHICS/ZU051100.GIF)
通常の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アプリケーションを入れ替える場合に使用できます。リデプロイ機能による入れ替え手順を次に示します。
|
|
![[図データ]](GRAPHICS/ZU051200.GIF)
リデプロイ機能を使用する場合には，通常のアーカイブ形式のJ2EEアプリケーションの入れ替えと比べて，少ない手順で入れ替えができます。
- 参考
-
リデプロイを実行する前に，JSP事前コンパイル機能を実行しておくことをお勧めします。JSP事前コンパイル機能は，Webアプリケーションに含まれるJSPファイルをデプロイ前にコンパイルし，クラスファイルを生成する機能です。あらかじめ，クラスファイルの生成までを実施しておくので，JSPに最初にリクエストが到着したときのレスポンスタイムおよびWebアプリケーションの開始時間を短縮できます。JSP事前コンパイル機能については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.5 JSP事前コンパイル機能とコンパイル結果の保持」を参照してください。
リデプロイ機能については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「18.7 J2EEアプリケーションのリデプロイ」を参照してください。
(3) リロード機能による入れ替え
アプリケーション開発でのテストやシステムの運用中に，修正したJ2EEアプリケーションと動作中のJ2EEアプリケーションを入れ替えたい場合，リロード機能を使用した入れ替えができます。展開ディレクトリ形式のJ2EEアプリケーションを構成するファイルを更新した場合に，更新検知やコマンド実行によって，更新したJ2EEアプリケーションをリロードできます。リロード機能を使用することで，少ない手順でJ2EEアプリケーションを動的に入れ替えられるようになります。
リロード機能による入れ替えは，展開ディレクトリ形式のJ2EEアプリケーションを入れ替える場合に使用できます。リロード機能による入れ替え手順を次に示します。
|
|
![[図データ]](GRAPHICS/ZU051300.GIF)
リロード機能を使用する場合には，通常の展開ディレクトリ形式のJ2EEアプリケーションの入れ替えと比べて，少ない手順で入れ替えができます。
リロード機能については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「18.8 J2EEアプリケーションの更新検知とリロード」を参照してください。
J2EEアプリケーションの入れ替えと保守については，「5.6.3 J2EEアプリケーションの入れ替えと保守」を参照してください。サーバ管理コマンドの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3. サーバ管理コマンドの基本操作」を参照してください。