Javaのシステム更改を考慮していますか？

Javaのシステム更改についてありがちな事例と対処法

これまで3回にわたり、Javaの運用・保守を考慮したシステム開発について説明してきましたが、今回が最終回です。最終回はJavaのシステム更改についてありがちな事例と対処法を説明します。

システムの運用・保守の段階では、システム更改は必ず発生するものです。お客様の要望による更改、不具合の解消による更改と理由はさまざまですが、読者の皆さんも表1のようなシステム更改に関する経験はないでしょうか。

ケース1

Javaで作成したWebアプリケーションのシステムで、「ブランドロゴの画像ファイルを変えたい」というお客様の要望。お客様はサーバ上の画像ファイルを置き換えるだけだから、作業工数はそれほどかからないと予想。

しかし画像ファイルをWebモジュール（.warファイル）の中に格納しているため、アプリケーションのビルドとアプリケーションサーバへのデプロイが必要となり、作業工数が予想以上にかかってしまった。

ケース2

法律改正に伴い、システムの機能改修が必要となった。システム更改の際、アプリケーションの更新のため、アプリケーションサーバの再起動（＝システムの停止）が必要であり、お客様へ「システム更改の際、システムの停止が必要」と説明した。

しかし「業務を止めたくない。システムの停止をしない方法でシステムの更改をして欲しい」というお客様の要望があり、いろいろ対策を検討したが方法が見つからなかった。結局、お客様を説得した上で、業務を停止し、システムの更改を行った。

ケース1については、画像ファイルのほかに「スタイルシートを更新したい」や「HTMLファイル中にある文章を変更したい」という要望が考えられます。画像ファイルやスタイルシートのような静的コンテンツがWebサーバに配置してある場合なら、ファイルをコピーするだけですみます。

しかしJavaでWebアプリケーションを作成すると、静的コンテンツをWebモジュール（.warファイル）やエンタープライズ・アプリケーション（.earファイル）の中に格納することがあります。この場合、静的コンテンツを更新するには、アプリケーションのビルドとデプロイが必要になるため、ファイルをコピーするだけの更新と比べて作業工数が増えます。Webモジュール（.warファイル）やエンタープライズ・アプリケーション（.earファイル）の中に格納した構成は、パッケージ単位でのファイル構成管理のメリットがある反面、柔軟性に劣る構成といえるでしょう。

またケース2については、「業務を停止する」ということを関係者へ事前連絡したり承認をとるといった手続きが必要となることがあります。このような場合は、システム更改に時間がかかります。

今後起こり得るすべてのシステム更改を考慮したシステム開発はできませんが、システムの要件によって起こり得るケースを予め想定し、システム開発時 から定型化作業ができるように考慮する必要があります。今回は、トラブル事例であげた各ケースの対応方法について説明します。

ケース1の対応法：コンテンツ配置の工夫

ケース1は、画像ファイルなどの静的コンテンツをWebモジュール（.warファイル）の中に格納していることが原因です。対応方法としては、Webアプリケーションを構成するコンテンツを静的コンテンツと動的コンテンツに分離し、静的コンテンツをアプリケーションサーバ以外へ配置するようにし ます。

具体的には3層構成のWebアプリケーションのシステムの場合、図1のように画像ファイルなどの静的コンテンツはWebサーバに配置し、サーブレットなどの動的コンテンツはアプリケーションサーバへ配置します。

図1：コンテンツ配置の工夫
（画像をクリックすると別ウィンドウに拡大図を表示します）

この工夫のポイントとしては、コンテンツの構成（配置方法）になります。現在のアプリケーションサーバは、オープンソースや商用製品を問わず、Webサーバと連携するプラグインが提供されています。

このプラグインは、図1のような3層システム構成の場合に特定のディレクトリに対してWebサーバからアプリケーションサーバへHTTPリクエスト を転送する機能を持ちます。この機能を使い、画像ファイルなどの静的コンテンツはWebサーバに配置するようにします。

表2はコンテンツのディレクトリ構成と配置箇所の例になります。