JRun によるアプリケーションの開発 戻る 上のレベルへ 進む
Web アプリケーションの開発


Web アプリケーションの概説

Web アプリケーションは、サーブレット、JSP ドキュメント、HTML ドキュメント、イメージ、およびその他のリソースから構成されています。あらかじめ定義されているディレクトリ構造に従ってこれらのリソースを配置し、どの Web アプリケーション サーバーにも公開できるようにします。

このセクションでは、Web アプリケーションの重要な機能と利点について説明します。

Web アプリケーションの利点

Web アプリケーションについては、Java サーブレット API バージョン 2.2 の仕様書で定義されています。Web アプリケーションによる方法には、次の利点があります。

Web アプリケーションの使用

1 つの JRun サーバーで、複数の Web アプリケーションをサポートできます。次の図は、複数の Web アプリケーションのホストとして機能している 2 つの JRun サーバーを示します。

Web アプリケーションでは、ほかのアプリケーション内のリソースの参照や、一般的なリソースの共有が可能です。共有することによって、Web アプリケーションは EJB やデータベース ドライバ クラスなど、多くのアプリケーションで一般的に使用されているリソースにアクセスできます。

JRun 接続モジュール (JCM) は、Web サーバーと JRun サーバー間の接続を管理します。JCM の設定の詳細については、『JRun セットアップ ガイド』を参照してください。

Web アプリケーションでは、データベースや EJB を使用してデータを共有することもできます。たとえば、電子商取引 Web サイトが、複数のアプリケーションから構成されているとします。このタイプのサイトの顧客は、ログイン名とパスワードによって識別できます。そのため、各 Web アプリケーションではログイン名を使用して、ショッピング カート、購入履歴、住所などのデータベース内の顧客の情報にアクセスします。

Web アプリケーションを開発する場合に決定しなければならないことは、複数の JRun サーバー上のアプリケーション間の境界線をどこに設定するかという点です。つまり、1 つのJRun サーバーですべてのアプリケーションを稼動できるようにするのか、複数の JRun サーバー間にアプリケーションを分散させる必要があるのかについて決める必要があります。

複数のJRun サーバーを作成する理由の 1 つは、アプリケーションをコンピュータ上の異なるプロセスに分離するためです。たとえば、JRun サーバー内のすべての Java サーブレット、JSP、およびアプリケーションは、1 つのプロセスで実行します。アプリケーションを複数の JRun サーバーに分離することによって異なるプロセスを使用し、アプリケーションが別のアプリケーションに悪影響を与えないようにすることができます。さらに、クラスパス、データ ソース、および EJB をサーバー レベルで定義できます。

Web アプリケーションをそれぞれ異なる JRun サーバーで実行するもう 1 つの理由は、各 JRun サーバーで独自のユーザ認証メカニズムや一連のユーザ認証ルールを実装できることです。異なる JRun サーバーでアプリケーションを実行することによって、特定のサーバーの認証設定を利用できます。認証の詳細については、第 39 章を参照してください。

Web アプリケーションのディレクトリ構造

次の図は、Web アプリケーションのディレクトリ構造を示します。

アプリケーションのルート ディレクトリ (この図では approot) は、アプリケーション ファイルを提供するためのドキュメント ルートとして機能します。このディレクトリには、Web アプリケーションの一部として開発された JSP が含まれます。たとえば、Web アプリケーションが c:/apps/app1 にある場合、既定のトップ ページ ファイルは c:/apps/app1/index.html に配置されます。

ディレクトリ ルートのサブディレクトリには、次のディレクトリが含まれる場合がありますが、これらに限定されません。

実際の Web アプリケーションで使用するのは、前出の図に示したディレクトリだけではありません。HTML ファイル、イメージ、その他のアプリケーション リソースなどのために、ほかのディレクトリを追加できます。これらのディレクトリは、クライアントが直接アクセスするリソース用 Web アプリケーションの公開ドキュメント ツリーの一部になります。アプリケーションへのディレクトリ追加の詳細については、"ディレクトリの追加"を参照してください。

ここに記載されているディレクトリ以外に、JRun サーバーでは、そのサーバーがホストとなる Web アプリケーションごとに一時ディレクトリが用意されます。この一時ディレクトリは JRun 自体では使用されませんが、Java サーブレットや JSP 実行時の一時的な領域スペースを取得できるように用意されています。たとえば、このディレクトリを使用してデータベース クエリの結果をキャッシュできます。

次の命名規約に従って、一時ディレクトリが Web アプリケーションごとに自動的に作成されます。 

サーバー名/tmp/アプリケーション名

ここで、サーバー名は JRun サーバーのディレクトリ名で、アプリケーション名はサーバーがホストとなる Web アプリケーションの名前に対応するディレクトリの名前です。実行時は、次のステートメントを使用して、サーブレット内からこのディレクトリへの参照を取得できます。 

File f = (File) getServletContext().getAttribute
("javax.servlet.context.tempdir");

公開記述子 (web.xml)

Web アプリケーションは、web.xml ファイルの内容によって定義されます。このファイルは、公開記述子とも呼ばれます。このファイルには、アプリケーション サーバー上でアプリケーションを実行するために必要なすべての情報が含まれています。web.xml の内容は JRun 固有のものではなく、Java サーブレット API バージョン 2.2 の仕様書に定義されています。Java サーブレット API バージョン 2.2 の仕様書に定義されているように Web アプリケーションをサポートしているすべてのプラットフォームは、web.xml ファイルの内容を認識して、解釈します。

web.xml ファイルを使用して、Web アプリケーションの次のような設定情報と公開情報を定義します。

web.xml ファイルには、Web アプリケーションについての情報だけでなく、EJB についての情報も含まれています。この情報には、サーブレットが EJB のホーム インターフェイスを探すときに必要な設定値が含まれています。

web.xml ファイルは標準的なテキスト エディタや XML エディタを使用して編集する XML ファイルです。また、JRun 管理コンソール (JMC) を使用すると、このファイルの多くの属性を変更できます。web.xml ファイルの各設定値については、本書の該当する部分で説明しています。web.xml ファイルのすべてのプロパティの全リストについては、Java サーブレット API バージョン 2.2 の仕様書を参照してください。

アプリケーション コンポーネント

Web アプリケーションは次のコンポーネントから構成されます。

アプリケーションにリソースを追加するには、Web アプリケーションの適切なディレクトリにそのリソースを配置します。アプリケーションへのこれらのリソースの追加の詳細については、"Web アプリケーション コンポーネントの追加"を参照してください。

Web アプリケーション、JRun サーバー、Web サーバー

Web アプリケーションは、JRun などのアプリケーション サーバーをホストとして利用します。Web アプリケーション開発時の最初の作業の 1 つとして、アプリケーションを特定の JRun サーバーに関連付けます。多くの場合、Web アプリケーションを default JRun サーバーまたはユーザが作成した JRun サーバーに関連付けます。


メモ

Web アプリケーションを admin JRun サーバーと関連付けないでください。admin JRun サーバーは、主にすべての JRun サーバーを含む JRun インストールの管理に使用 します。


次の図は、複数のアプリケーションのホストとして機能する default JRun サーバーを示します。

この図には、この JRun サーバーに関連付けられている Web サーバーも示されています。Web サーバーはクライアントからの要求を URL 形式で受け取り、要求が Java サーブレットや JSP などの Web アプリケーション リソースを参照するときに JRun にこの要求を渡します。

JRun サーバーをホストとするさまざまな Web アプリケーションにクライアントの要求を割り当てるには、各 Web アプリケーションをマッピングして異なる URL パターンに対応します。この方法で、JRun サーバーは適切な Web アプリケーションに要求を転送できます。

アプリケーションのマッピング

アプリケーションのマッピングによって、要求の URL をアプリケーションが含まれている物理ディレクトリに関連付けます。Web アプリケーション公開の一環として、アプリケーションへの URL パスを指定して Web サーバーによって認識されるようにする必要があります。

Web アプリケーションが http://hostname/appURL/resourcename の形式の URL に応答するように、URL マッピングを設定します。このマッピングを設定すると、接頭辞 http://hostname/appURL/ で始まるすべての URL がこのアプリケーションにマッピングされます。


メモ

JRun ではアプリケーションの URL マッピングに制限はありません。アプリケーション 名を URL マッピングの一部として使用する必要はありませんが、これを任意の文字列 にマッピングできます。


たとえば、次の表は Web アプリケーション、アプリケーション URL マッピング、およびアプリケーション リソースの要求 URL の物理的位置の一覧です。
Web アプリケーションの
ディレクトリ
アプリケーションの
URL マッピング
クライアント要求 URL
 
c:/apps/app1
/app1
 http://hostname/app1/resource_name
 
c:/apps/app2
/app2
 http://hostname/app2/resource_name

この例では、c:/apps という名前のディレクトリを作成し、すべての Web アプリケーションを格納します。次に、要求 URL が app1 または app2 のどちらかにマッピングされるように、JRun でアプリケーション URL マッピングを設定します。

JRun が特定のリソースの要求 URL を解決する方法については、第 6 章を参照してください。

Web アプリケーション クラスパスの決定

Web アプリケーションのクラスパスは、アプリケーションがアクセスできるクラスを定義します。たとえば、Java サーブレットの .class ファイルは、サーブレットを処理できるように、JRun 用の Web アプリケーションのクラスパスに含まれているディレクトリ内になければなりません。このクラスパスには、.class ファイルが含まれているディレクトリまたは JAR ファイルも含まれます。

Web アプリケーションのクラスパスの定義は、再ロード可能部分と、再ロード不可部分の 2 つに分けられます。再ロード可能なクラスには、JSP や Java サーブレットがあります。実行時は、クラスパスの再ロード可能部分で定義されるクラスがチェックされます。メモリ内のクラスのイメージがディスク上のイメージと異なる場合は、クラスが再ロードされます。

アプリケーションのクラスパスの再ロード不可部分によって参照されるクラスは 1 度だけロードされ、変更についてはチェックされません。通常、Web アプリケーションの開発の一環として変更しない基本的な Java クラス、JRun ファイル、JVM クラスなどが再ロード不可クラスとなります。

Web アプリケーションの既定の再ロード可能なクラスパスには、次のディレクトリが含まれます。

既定の再ロード不可クラスパスには、次のディレクトリとファイルが含まれます。

Web アプリケーションのクラスパスの変更

再ロード可能部分と再ロード不可部分の両方とも、個別の JRun プロパティ ファイルを使用して Web アプリケーションのクラスパスを変更します。

JRun プロパティ ファイルの階層によって、個々の JRun サーバーによって処理されるすべての Web アプリケーションのクラスパスを設定したり (local.properties を使用)、個々の Web アプリケーションのクラスパスを設定できます(webapp.properties を使用)。

クラスパスの再ロード可能部分を変更するには、webapp.classpath プロパティの設定を変更します。webapp.classpath の既定値は、次のとおりです。 

webapp.classpath=/WEB-INF/classes;/WEB-INF/lib;/WEB-INF/jsp

webapp.classpath に指定されるパスは通常、アプリケーションの /WEB-INF ディレクトリの下にあります。

再ロード不可部分のアプリケーション クラスパスは、次の 2 つのプロパティから構成されています。

これらの 2 つのプロパティによって指定されるディレクトリについては、そのディレクトリに含まれている各 JAR ファイルが、JRun が呼び出される前にクラスパス内のディレクトリの後ろに自動的に追加されます。これらの 2 つのプロパティの既定値は、次のとおりです。 

jrun.classpath = {jrun.rootdir}/lib/ext;{jrun.rootdir}/lib/
jrun.jar;{jrun.rootdir}/lib/install.jar

user.classpath={jrun.rootdir}/servers/lib;{jrun.server.rootdir}/lib

Web アプリケーション間でのクラスの共有

Web アプリケーションのディレクトリ構造は、Java サーブレット API バージョン 2.2 の仕様書に定義されています。この仕様に定義されているように、Web アプリケーションに関連付けられているすべての .class ファイルは、そのアプリケーションのルート ディレクトリに格納する必要があります。

ただし、JRun には、複数の Web アプリケーションで共通ファイルを共有できるように、ディレクトリ構造の外部にある .class ファイルにアクセスする Web アプリケーションの機能が追加されました。ファイルを共有すると、複数のアプリケーションに共通するデータベース ドライバ クラスやカスタム タグ ライブラリなどの .class ファイルを 1 つの場所に格納しておくことができます。共有リソースの追加は、共有ディレクトリに .class や JAR ファイルを移動し、これらのリソースにアクセスするアプリケーションのホストである JRun サーバーを再起動するだけなので簡単です。


メモ

アプリケーションのディレクトリ構造の外部の .class ファイルにアクセスするように アプリケーションを定義する場合、アプリケーションの WAR ファイルを作成する前に、 Web アプリケーションのディレクトリ構造にすべての共有リソースをコピーする必 要があります。


JRun では、各 Web アプリケーションは JRun サーバーをホストとします。すべての Web アプリケーションが同じ JRun サーバーをホストとするように環境を定義したり、Web アプリケーションを複数の JRun サーバー間に分散できます。Web アプリケーションのホストになる JRun サーバーに関係なく、Web アプリケーション間でクラス ファイルを共有できます。

JRun には、共有 .class ファイルに使用できる次のライブラリ ディレクトリがあります。

分散型 Web アプリケーション

今回の JRun では、分散型 Web アプリケーションをサポートしていません。

Copyright © 2001, Macromedia Inc. All rights reserved. 戻る 上へ 進む