Hitachi

Cosminexus V11 アプリケーションサーバ 機能解説 運用/監視/連携編


5.6.1 J2EEアプリケーションの入れ替えとは

システムの運用を開始したあとで,J2EEアプリケーションのバージョンアップやメンテナンスを実施するために,J2EEアプリケーションを入れ替えることがあります。

通常,J2EEアプリケーションを入れ替える場合には,J2EEサーバ上で動作しているJ2EEアプリケーションを停止したあと削除し,新しいJ2EEアプリケーションをインポート,デプロイする必要があります。通常のJ2EEアプリケーションの入れ替えの手順を次の図に示します。

図5‒14 通常のJ2EEアプリケーションの入れ替えの手順

[図データ]

通常のJ2EEアプリケーションの入れ替えでは,J2EEアプリケーションを入れ替える間,サービスを停止する必要がありますが,サービスの部分閉塞を使用すると,サービスを停止することなくJ2EEアプリケーションを入れ替えることができます。また,リデプロイ機能やリロード機能を使用すると,通常のJ2EEアプリケーションの入れ替えに比べて,少ない手順で入れ替えができるようになります。

J2EEアプリケーションの入れ替え方法を次の表に示します。

表5‒26 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アプリケーションを入れ替える場合に使用できます。リデプロイ機能による入れ替え手順を次に示します。

図5‒15 リデプロイ機能による入れ替え手順

[図データ]

リデプロイ機能を使用する場合には,通常のアーカイブ形式のJ2EEアプリケーションの入れ替えと比べて,少ない手順で入れ替えができます。

参考

リデプロイを実行する前に,JSP事前コンパイル機能を実行しておくことをお勧めします。JSP事前コンパイル機能は,Webアプリケーションに含まれるJSPファイルをデプロイ前にコンパイルし,クラスファイルを生成する機能です。あらかじめ,クラスファイルの生成までを実施しておくので,JSPに最初にリクエストが到着したときのレスポンスタイムおよびWebアプリケーションの開始時間を短縮できます。JSP事前コンパイル機能については,マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.5 JSP事前コンパイル機能とコンパイル結果の保持」を参照してください。

リデプロイ機能については,マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「18.7 J2EEアプリケーションのリデプロイ」を参照してください。

(3) リロード機能による入れ替え

アプリケーション開発でのテストやシステムの運用中に,修正したJ2EEアプリケーションと動作中のJ2EEアプリケーションを入れ替えたい場合,リロード機能を使用した入れ替えができます。展開ディレクトリ形式のJ2EEアプリケーションを構成するファイルを更新した場合に,更新検知やコマンド実行によって,更新したJ2EEアプリケーションをリロードできます。リロード機能を使用することで,少ない手順でJ2EEアプリケーションを動的に入れ替えられるようになります。

リロード機能による入れ替えは,展開ディレクトリ形式のJ2EEアプリケーションを入れ替える場合に使用できます。リロード機能による入れ替え手順を次に示します。

図5‒16 リロード機能による入れ替え手順

[図データ]

リロード機能を使用する場合には,通常の展開ディレクトリ形式のJ2EEアプリケーションの入れ替えと比べて,少ない手順で入れ替えができます。

リロード機能については,マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「18.8 J2EEアプリケーションの更新検知とリロード」を参照してください。

J2EEアプリケーションの入れ替えと保守については,「5.6.3 J2EEアプリケーションの入れ替えと保守」を参照してください。サーバ管理コマンドの操作については,マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3. サーバ管理コマンドの基本操作」を参照してください。