 |
||||||||||||||||||
|
||||||||||||||||||
| 1 2 3 次のページ | ||||||||||||||||||
|
||||||||||||||||||
| Javaのシステム更改についてありがちな事例と対処法 | ||||||||||||||||||
|
これまで3回にわたり、Javaの運用・保守を考慮したシステム開発について説明してきましたが、今回が最終回です。最終回はJavaのシステム更改についてありがちな事例と対処法を説明します。 システムの運用・保守の段階では、システム更改は必ず発生するものです。お客様の要望による更改、不具合の解消による更改と理由はさまざまですが、読者の皆さんも表1のようなシステム更改に関する経験はないでしょうか。
表1：システム更改に関するトラブル事例： ケース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はコンテンツのディレクトリ構成と配置箇所の例になります。
表2：コンテンツのディレクトリ構成と配置箇所の例 |
||||||||||||||||||
|
1 2 3 次のページ |
||||||||||||||||||
|
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
-
-
連載
