A
サーブレットとJSPの技術的なバックグラウンド

この付録では、サーブレットとJSPに関する技術的なバックグラウンドについて説明します。このマニュアルは、サーブレット・テクノロジの知識があるユーザーを対象にしていますが、ここで説明する内容は、その知識を新たにするのに役立ちます。

また、生成したJSPページ実装クラスによって自動的に実装される、標準のJSPインタフェースについても簡単に説明します。ただし、ほとんどのユーザーにはこの情報は必要ありません。

次の項目について説明します。

注意: サーブレットとOC4Jのサーブレット・コンテナの詳細は、『Oracle Application Server Containers for J2EEサーブレット開発者ガイド』を参照してください。

サーブレットに関するバックグラウンド

JSPページはJavaサーブレットに変換されるため、ここでは、サーブレット・テクノロジについて簡単に説明します。ここで説明する概念の詳細は、Sun社のJavaサーブレット仕様を参照してください。

この項で説明するメソッドの詳細は、Sun社の次のサイトでJavadocを参照してください。

http://java.sun.com/products/servlet/2.3/javadoc/index.html

サーブレット・テクノロジの概要

近年、サーブレット・テクノロジは、動的なHTMLページを介してWebサーバーの機能を拡張する強力な方法として急速に発展しました。サーブレットとは、Webサーバーで実行するJavaプログラムです。これとは対照的に、アプレットは、クライアント・ブラウザで実行するJavaプログラムです。サーブレットは、ブラウザからHTTPリクエストを取得して動的なコンテンツを生成し（データベースを問い合せるなどの方法で）、HTTPレスポンスをブラウザに戻します。

サーブレットが開発される前は、CGI（Common Gateway Interface）テクノロジが動的なコンテンツに使用されていました。このCGIプログラムは、Perlなどの言語で記述され、Webサーバーを介してWebアプリケーションによってコールされていました。しかし、CGIは、アーキテクチャとスケーラビリティに制限があったため、理想的なテクノロジではありませんでした。

サーブレット・テクノロジは、スケーラビリティの向上に加えて、Javaのメリットであるオフジェクト指向、プラットフォームからの独立性、セキュリティおよび堅牢さも備えています。サーブレットでは、すべての標準Java APIを使用できます。これには、データベース・プログラマにとって特に重要な、Javaデータベースに接続するためのJDBC APIも含まれます。

Javaのレルムでは、サーバー集中型アプリケーション（データベースにアクセスするアプリケーションなど）に関して、サーブレット・テクノロジは、アプレット・テクノロジよりも多くのメリットを提供します。このメリットの1つは、サーブレットが、一般的に多くのリソースを備えた堅牢なマシンであるサーバーで実行されるため、クライアントのリソースの使用を最小限に抑えることができることです。これに対して、アプレットはクライアントのブラウザにダウンロードされ、クライアントで実行されます。もう1つのメリットは、データに直接アクセスできることです。サーブレットが実行されるWebサーバーは、アクセスするデータと同じネットワーク・ファイアウォール側に存在します。クライアント・マシンで実行されるアプレットは、ファイアウォールの外側に存在するため、アプレットのダウンロード元ではないサーバーにアプレットがアクセスするには、特別な方法（署名付きアプレットなど）が必要です。

サーブレットのインタフェース

Javaサーブレットは、標準のjavax.servlet.Servletインタフェースを実装するように定義されています。このインタフェースは、サーブレットの初期化、リクエストの処理、サーブレットの構成などの基本情報の取得、およびサーブレット・インスタンスの終了を行うメソッドを指定します。

Webアプリケーションの場合、Servletインタフェースは、標準のjavax.servlet.http.HttpServlet抽象クラスを拡張することによって実装できます。HttpServletクラスには、次のメソッドが含まれます。

init(...)およびdestroy(...): それぞれ、サーブレットの初期化メソッドおよび終了メソッド。
doGet(...): HTTP GETリクエスト用メソッド。
doPost(...): HTTP POSTリクエスト用メソッド。
doPut(...): HTTP PUTリクエスト用メソッド。
doDelete(...): HTTP DELETEリクエスト用メソッド。
service(...): HTTPリクエストを受信するためのメソッド。デフォルトでは、リクエストを適切なdoXXX()メソッドにディスパッチします。
getServletInfo(...): サーブレット自体の情報を提供するためにサーブレットで使用するメソッド。

HttpServletを拡張するサーブレット・クラスは、これらのメソッドの中から必要なメソッドを実装する必要があります。各メソッドは、標準のjavax.servlet.http.HttpServletRequestインスタンスおよび標準のjavax.servlet.http.HttpServletResponseインスタンスを入力として取得します。

HttpServletRequestインスタンスは、HTTPリクエストに関する情報（リクエスト・パラメータの名前と値、リクエストを送信したリモート・ホストの名前、リクエストを受信したサーバーの名前など）をサーブレットに提供します。HttpServletResponseインスタンスは、コンテンツ長とMIMEタイプの指定、出力ストリームの提供など、レスポンスを送信するときのHTTP固有の機能を提供します。

サーブレット・コンテナ

サーブレット・コンテナはサーブレット・エンジンとも呼ばれ、サーブレットを実行および管理します。通常、サーブレット・コンテナはJavaで記述され、Webサーバーに組み込まれます（WebサーバーがJavaで記述されている場合）。そうでない場合は、Webサーバーに関連付けられ、そのWebサーバーで使用されます。

サーブレットがコールされると（サーブレットがURLによって指定された場合など）、WebサーバーはHTTPリクエストをサーブレット・コンテナに渡します。次に、コンテナは、そのリクエストをサーブレットに渡します。サーブレットの管理を実行する間に、単純なコンテナは、次の処理を実行します。

サーブレットのインスタンスを作成し、init()メソッドをコールしてそのインスタンスを初期化します。
サーブレットのservice()メソッドをコールします。
必要に応じて、サーブレットのdestroy()メソッドをコールし、インスタンスを破棄します。これによって、そのインスタンスはガベージ・コレクションの対象になります。

パフォーマンス上の理由から、サーブレット・コンテナは通常、サーブレット・インスタンスをタスクの完了ごとに破棄せず、メモリー内に保持して再利用します。インスタンスを破棄するのは、Webサーバーの停止など、頻度の低いイベントの場合のみです。

サーブレットの実行中に別のサーブレット・リクエストが発生した場合のサーブレット・コンテナの動作は、そのサーブレットがシングル・スレッド・モデルを使用しているか、マルチスレッド・モデルを使用しているかによって異なります。シングル・スレッドの場合、サーブレット・コンテナは、同時にコールされた複数のservice()メソッドが、単一のサーブレット・インスタンスにディスパッチされないようにします。この場合は、複数のサーブレット・インスタンスを個別に起動します。マルチスレッド・モデルの場合、コンテナは、単一のサーブレット・インスタンスに対して複数のservice()メソッドを同時にコールできます（コールごとに個別のスレッドを使用します）。ただし、サーブレット開発者は同期を管理する責任があります。

サーブレット・セッション

サーブレットは、HTTPセッションを使用して、HTTPリクエストを行ったユーザーを追跡します。これによって、単一ユーザーからの複数のリクエストをステートフルな方法で管理できます。サーブレット・セッション・トラッキングは、CGIなど以前のテクノロジのHTTPセッション・トラッキングと類似しています。

HttpSessionインタフェース

標準のサーブレットAPIでは、各ユーザーは、標準のjavax.servlet.http.HttpSessionインタフェースを実装するクラスのインスタンスで表されます。サーブレットは、セッションに関する情報をこのHttpSessionオブジェクトに設定し（スコープは必ずアプリケーション・レベルを設定）、ここから情報を取得できます。

サーブレットは、HttpServletRequestオブジェクト（HTTPリクエストを表します）のgetSession()メソッドを使用して、ユーザー用のHttpSessionオブジェクトを取得または作成します。このメソッドは、セッション・オブジェクトがない場合、ブール型の引数を取得して、ユーザー用に新規のセッション・オブジェクトを作成する必要があるかどうかを指定します。

HttpSessionインタフェースは、次のメソッドを指定して、セッション情報の取得および設定を行います。

public void setAttribute(String name, Object value)

このメソッドは、指定のオブジェクトを指定の名前でセッションにバインドします。
public Object getAttribute(String name)

このメソッドは、指定の名前でセッションにバインドされたオブジェクトを取得します。一致するオブジェクトがない場合は、nullを取得します。

注意: 以前のサーブレット実装では、setAttribute()およびgetAttribute()のかわりに、同じシグネチャを持つputValue()およびgetValue()が使用されます。

サーブレット・コンテナとサーブレット自体の実装に応じて、セッションは、設定された時間の経過後に自動的に終了するか、サーブレットによって明示的に無効にすることができます。サーブレットは、HttpSessionインタフェースで指定した次のメソッドを使用して、セッションのライフ・サイクルを管理できます。

public boolean invalidate()

このメソッドは、セッションを即時に無効にして、オブジェクトをセッションからバインド解除します。
public boolean setMaxInactiveInterval(int interval)

このメソッドは、タイムアウト時間を秒単位の整数で設定します。
public boolean isNew()

このメソッドは、セッションを作成したリクエスト内ではtrueを戻し、そうでない場合はfalseを戻します。
public boolean getCreationTime()

このメソッドは、セッション・オブジェクトの作成時間を、1970年1月1日午前0時以降の経過時間としてミリ秒単位で戻します。
public boolean getLastAccessedTime()

このメソッドは、クライアントによる最新のリクエストの時間を、1970年1月1日午前0時以降の経過時間としてミリ秒単位で戻します。

セッション・トラッキング

HttpSessionインタフェースは、セッションの追跡に関するいくつかの機能をサポートします。各機能には、セッションIDを割り当てる方法が含まれます。セッションIDは、サーブレット・コンテナが割り当て、使用する中間ハンドルです。同じユーザーによる複数のセッションでは、必要に応じて、同じセッションIDを共有できます。

次のセッション・トラッキング機能がサポートされています。

Cookie

HTTPリクエストごとに、サーブレット・コンテナはCookieをクライアントに送信し、クライアントはそのCookieをサーバーに戻します。これによって、Cookieが示すセッションIDにリクエストが関連付けられます。この機能は最も頻繁に使用され、サーブレット仕様2.2以上に準拠するサーブレット・コンテナでサポートされます。
URL書換え

サーブレット・コンテナは、次の例に示すようにセッションIDをURLパスに追加します。
```
http://host:port/myapp/index.html?jsessionid=6789
```
この機能は、クライアントがCookieを受け取らない場合に最も頻繁に使用されます。

サーブレット・コンテキスト

サーブレット・コンテキストは、単一のJVM内にある、1つのWebアプリケーションの全インスタンス（つまり、Webアプリケーションの一部であるサーブレットとJSPページの全インスタンス）に関する状態情報を維持するために使用します。これは、サーバー上の単一のクライアントに関する状態情報をセッションで維持する方法に類似していますが、サーブレット・コンテキストは、単一ユーザーに対して固有ではなく、複数のクライアントを処理できます。通常は、指定のJVM内で実行されるWebアプリケーションごとに、1つのサーブレット・コンテキストが存在します。サーブレット・コンテキストは、アプリケーション・コンテナと考えることができます。

サーブレット・コンテキストは、標準のjavax.servlet.ServletContextインタフェースを実装するクラスのインスタンスです。このようなクラスは、複数のサーブレットをサポートするWebサーバーに提供されます。

ServletContextオブジェクトによって、サーブレット環境に関する情報（サーバー名など）が提供され、単一のJVM内では、グループ内の複数サーブレット間でリソースを共有できます（複数の同時JVMをサポートするサーブレット・コンテナの場合は、リソース共有の実装が異なります）。

サーブレット・コンテキストは、アプリケーションを実行するユーザーのセッション・オブジェクトを維持し、そのアプリケーションの実行インスタンスにスコープを提供します。この機能によって、各アプリケーションが固有のクラス・ローダーからロードされ、その実行時オブジェクトが、他のアプリケーションの実行時オブジェクトと区別されます。特に、HttpSessionがアプリケーションのユーザーごとに固有であるのと同様に、ServletContextオブジェクトはアプリケーションに対して固有です。

サーブレット仕様2.2以上では、ほとんどの実装で、単一のホスト内で複数のサーブレット・コンテキストを提供できます。これによって、各Webアプリケーションは、独自のサーブレット・コンテキストを使用できます（以前の実装では、通常、特定のホストに対して1つのサーブレット・コンテキストのみ提供されていました）。

ServletContextインタフェースは、サーブレットが、そのサーブレットを実行しているサーブレット・コンテナと通信できるメソッドを指定します。これは、サーブレットがアプリケーション・レベルの環境と状態情報を取得できる方法の1つです。

注意: 以前のバージョンのサーブレット仕様では、サーブレット・コンテキストの概念が十分に定義されていませんでした。バージョン2.1（b）以上では概念がより明確になり、HTTPセッション・オブジェクトが複数のサーブレット・コンテキスト・オブジェクト間で存在できないように指定されました。

イベント・リスナーによるアプリケーションのライフ・サイクル管理

サーブレット仕様2.2で、標準のJavaイベント・リスナー機能による限定的なアプリケーションのライフ・サイクル管理が初めて提供されました。HTTPセッション・オブジェクトでは、セッション・オブジェクト内のオブジェクトの追加または削除を認識するためにイベント・リスナーを使用できます。一般的に、セッション・オブジェクト内のオブジェクトを削除するのは、そのセッションが無効になった場合であるため、この機能によって、開発者はセッション・ベースでリソースを管理できます。同様に、イベント・リスナー機能によって、ページ・ベースおよびリクエスト・ベースのリソースも管理できます。

サーブレット仕様2.3では、イベント・リスナーに対する追加サポートが提供され、サーブレット・コンテキスト・ライフサイクル、サーブレット・コンテキスト属性、HTTPセッション・ライフサイクルおよびHTTPセッション属性の変更が通知されるイベント・リスナーに対して実装可能なインタフェースを定義しています。詳細は、『Oracle Application Server Containers for J2EEサーブレット開発者ガイド』を参照してください。

サーブレットの起動

HTMLページと同様に、サーブレットもURLを使用して直接起動できます。サーブレットは、Webサーバー実装でサーブレットがURLにマッピングされた方法に従って起動されます。次のマッピング方法があります。

特定のURLを特定のサーブレット・クラスにマッピングできます。
ディレクトリ全体をマッピングできるため、ディレクトリ内の任意のクラスをサーブレットとして実行します。たとえば、/servletというディレクトリをマッピングすると、/servlet/servlet_nameの形式のURLでサーブレットを実行できます。
ファイル名拡張子をマッピングできるため、ファイル（ファイル名にその拡張子を含む）を指定したURLでサーブレットを実行できます。

マッピング方法は、Webサーバー構成の一部として指定されます。OC4Jでは、global-web-application.xmlファイルの設定によってマッピング方法が決まります。

JSPページと同様に、サーブレットも、jsp:includeタグやjsp:forwardタグを使用して間接的に起動できます。「JSPページからのサーブレットの起動」を参照してください。

Webアプリケーション階層

Webアプリケーション（サーブレットとJSPページの組合せで構成される）に関連するエンティティは、単純な階層構造ではありませんが、次の順序の階層と考えることができます。

サーブレット・オブジェクト（ページ実装オブジェクトを含む）

実行アプリケーションの各サーブレットと各JSPページ実装には、1つのサーブレット・オブジェクトがあります（使用する実行モデルがシングル・スレッドかマルチスレッドかによって、複数のオブジェクトが存在する場合があります）。サーブレット・オブジェクトは、クライアントからのリクエスト・オブジェクトを処理し、レスポンス・オブジェクトをそのクライアントに戻します。JSPページは、サーブレット・コードと同様に、レスポンス・オブジェクトの作成方法を指定します。

1つのページまたはサーブレットが別のページまたはサーブレットにインクルードまたは転送された場合など、特定の状況での複数のサーブレット・オブジェクトは、1つのリクエスト・オブジェクト内に存在しているサーブレット・オブジェクトと考えることができます。

通常、ユーザーは、セッション中に複数のサーブレット・オブジェクトにアクセスし、そのサーブレット・オブジェクトはセッション・オブジェクトに関連付けられています。

サーブレット・オブジェクトは、ページ実装オブジェクトと同様に、標準のjavax.servlet.Servletインタフェースを間接的に実装します。Webアプリケーション内のサーブレットの場合は、標準のjavax.servlet.http.HttpServlet抽象クラスをサブクラス化することで、このインタフェースを実装します。JSPページ実装クラスの場合は、標準のjavax.servlet.jsp.HttpJspPageインタフェースを実装することで、このインタフェースを実装します。
リクエスト・オブジェクトとレスポンス・オブジェクト

これらのオブジェクトは、ユーザーによるアプリケーションの実行によって生成された個別のHTTPリクエストとHTTPレスポンスを表します。

ユーザーは通常、セッション中に、複数のリクエストを生成し、複数のレスポンスを受け取ります。リクエスト・オブジェクトとレスポンス・オブジェクトは、セッション内に含まれているのではなく、セッションに関連付けられています。

クライアントから送信されたリクエストは、URLの仮想パスに従って、適切なサーブレット・コンテキスト・オブジェクト（クライアントが使用するアプリケーションに関連付けられたオブジェクト）にマッピングされます。仮想パスには、アプリケーションのルート・パスが含まれます。

リクエスト・オブジェクトは、標準のjavax.servlet.http.HttpServletRequestインタフェースを実装します。

レスポンス・オブジェクトは、標準のjavax.servlet.http.HttpServletResponseインタフェースを実装します。

セッション・オブジェクト

セッション・オブジェクトには、指定のセッションのユーザーに関する情報が格納され、複数のページ・リクエスト間で単一ユーザーを識別する方法を提供します。ユーザーごとに1つのセッション・オブジェクトが存在します。

任意の時点で、1つのサーブレットまたはJSPページに対して複数のユーザーが存在できます。各ユーザーは、固有のセッション・オブジェクトで表されます。ただし、すべてのセッション・オブジェクトは、アプリケーション全体に対応するサーブレット・コンテキストによって維持されます。実際には、各セッション・オブジェクトは、共通のサーブレット・コンテキストに関連付けられたWebアプリケーションのインスタンスを表すと考えることができます。

通常、セッション・オブジェクトは、複数のリクエスト・オブジェクト、レスポンス・オブジェクト、およびページまたはサーブレット・オブジェクトを順に使用し、他のセッションは同じオブジェクトを使用しません。ただし、このセッション・オブジェクトは、これらのオブジェクトを実際には含んでいません。

特定ユーザーのセッションのライフ・サイクルは、そのユーザーの最初のリクエストから始まります。そのユーザー・セッションが終了すると（ユーザーがアプリケーションを終了したり、タイムアウトが発生した場合など）、ライフ・サイクルが終了します。

HTTPセッション・オブジェクトは、javax.servlet.http.HttpSessionインタフェースを実装します。

注意: バージョン2.1（b）より前のサーブレット仕様では、1つのセッション・オブジェクトが複数のサーブレット・コンテキスト・オブジェクト間で存在することが可能でした。

サーブレット・コンテキスト・オブジェクト

サーブレット・コンテキスト・オブジェクトは、サーバー内の特定のパスに関連付けられます。このパスは、サーブレット・コンテキストに関連付けられたアプリケーションのモジュールに対するベース・パスで、アプリケーション・ルートと呼ばれます。

特定のJVM内では、1つのアプリケーションの全セッションに対して、1つのサーブレット・コンテキスト・オブジェクトが存在し、アプリケーションを形成するサーブレットとJSPページにサーバーから情報を提供します。また、他のアプリケーションから独立したセキュアな環境内では、サーブレット・コンテキスト・オブジェクトによって、複数のアプリケーション・セッションでデータを共有できます。

サーブレット・コンテナは、標準のjavax.servlet.ServletContextインタフェースを実装するクラスを提供し、ユーザーがアプリケーションを最初にリクエストしたときにこのクラスをインスタンス化して、このServletContextオブジェクトにアプリケーションの場所を示すパス情報を提供します。

サーブレット・コンテキスト・オブジェクトには、通常、アプリケーションを同時に使用する複数のユーザーを表すためのセッション・オブジェクトのプールがあります。

サーブレット・コンテキストのライフ・サイクルは、対応するアプリケーションに対する（いずれかのユーザーからの）最初のリクエストから始まります。ライフ・サイクルが終了するのは、サーバーが停止または終了した場合のみです。

サーブレット・コンテキストの概要は、「サーブレット・コンテキスト」を参照してください。
サーブレット構成オブジェクト

サーブレット・コンテナは、サーブレットが初期化されるとき、サーブレット構成オブジェクトを使用して情報をサーブレットに渡します。Servletインタフェースのinit()メソッドは、サーブレット構成オブジェクトを入力として取得します。

サーブレット・コンテナは、標準のjavax.servlet.ServletConfigインタフェースを実装するクラスを提供し、必要に応じてそのクラスをインスタンス化します。サーブレット・コンテキスト・オブジェクト（サーブレット・コンテナによってインスタンス化されます）は、サーブレット構成オブジェクトに含まれます。

標準のJSPインタフェースとメソッド

次の2つの標準インタフェースは、両方ともjavax.servlet.jspパッケージ内に存在し、JSPトランスレータによって生成されたコード内に実装するために使用できます。

JspPage
HttpJspPage

JspPageは、使用するプロトコルを特定しない汎用的なインタフェースです。このインタフェースは、javax.servlet.Servletインタフェースを拡張します。

HttpJspPageは、HTTPプロトコルを使用するJSPページ用のインタフェースです。このインタフェースはJspPageを拡張し、通常、JSPトランスレータによって生成されたサーブレット・クラスによって、直接かつ自動的に実装されます。

JspPageは、生成されたクラスのインスタンスを初期化したり終了するときに使用する、次のメソッドを指定します。

jspInit()
jspDestroy()

特別な初期化機能または終了機能が必要な場合は、次の例に示すように、JSP宣言を指定して、関連のメソッドをオーバーライドする必要があります。

<%! void jspInit()
    {
        ...your implementation code...
    }
%>

HttpJspPageによって、次のメソッドの指定が追加されます。

_jspService()

このメソッドのコードは、通常、トランスレータによって自動的に生成され、次の内容が含まれます。

JSPページのスクリプトレットからのコード
JSPディレクティブからのコード
ページの静的なコンテンツ

（JSPディレクティブは、スクリプトレット用のJava言語の指定、パッケージのインポートの提供など、ページに関する情報を提供します。詳細は、「ディレクティブ」を参照してください）。

Servletメソッドと同様に、_jspService()メソッドは、HttpServletRequestインスタンスとHttpServletResponseインスタンスを入力として取得します。

JspPageインタフェースとHttpJspPageインタフェースは、Servletインタフェースから次のメソッドを継承します。

init()
destroy()
service()
getServletConfig()
getServletInfo()

Servletインタフェースとその主要なメソッドの詳細は、「サーブレットのインタフェース」を参照してください。

A サーブレットとJSPの技術的なバックグラウンド