10g（10.1.3.1.0）
B31859-01
 目次 |
 索引 |
| Oracle Containers for J2EE サーブレット開発者ガイド 10g（10.1.3.1.0） B31859-01 |
|
Oracle Containers for J2EE（OC4J）を使用すると、標準J2EE準拠のアプリケーションを開発およびデプロイできます。アプリケーションは、標準Enterprise Archive（EAR）デプロイメント・ファイルにパッケージされており、Webモジュールをデプロイするための標準Web Archive（WAR）ファイル、リソース・アダプタ用のResource Adapter Archive（RAR）ファイル、ならびにアプリケーション内のEnterprise JavaBeans（EJB）およびアプリケーション・クライアント・モジュール用のJava archive（JAR）ファイルが含まれます。
Oracle Application Server 10g（10.1.3.1.0）では、OC4Jは、Java 2 Platform Enterprise Editionバージョン1.4に準拠し、OC4Jコンテナ内ではSun社のJavaサーブレット仕様、バージョン2.4に完全に準拠しています。（特に記載のないかぎり、このマニュアルではサーブレット仕様はこのバージョンを指します。）
この章では、サーブレット・テクノロジの概要を示し、最後にサーブレットの機能を表にまとめます。この章には、次の項が含まれます。
サーブレットの仕様は、次のサイトを参照してください。
http://java.sun.com/products/servlet/reference/api/index.html
次の項では、サーブレットおよびその他のJ2EEテクノロジの概要を説明します。
近年、サーブレット・テクノロジは、動的Webページを使用してWebサーバー機能を拡張する強力な手段として登場しました。サーブレットは、Webサーバーで稼働するJavaプログラムです。一方、アプレットはクライアント・ブラウザで稼働します。通常、サーブレットは、ブラウザからHTTPリクエストを取得し、データベース問合せなどによって動的コンテンツを生成し、HTTPレスポンスをブラウザに返します。または、直接別のアプリケーション・コンポーネントからアクセスされるか、または別のコンポーネントに出力を送信する場合もあります。ほとんどのサーブレットはHTMLテキストを生成しますが、かわりにXMLを生成してデータをカプセル化するサーブレットもあります。
具体的には、サーブレットは、OC4JなどのJ2EEアプリケーション・サーバーで稼働します。サーブレットは、JavaServer Pages（JSP）およびEnterprise JavaBeans（EJB）と同様、J2EEアプリケーションの主要なアプリケーション・コンポーネント・タイプの1つです。JSPやEJBも、サーバー・サイドJ2EEコンポーネント・タイプです。サーブレットは、アプレット（Java 2 Platform, Standard Edition仕様の一部）などのクライアント・サイド・コンポーネントやアプリケーションのクライアント・プログラムとともに使用されます。 アプリケーションは、任意の数のコンポーネントで構成できます。
サーブレット以前は、動的コンテンツの作成に、Common Gateway Interface（CGI）が使用されていました。CGIプログラムは、Perlなどの言語で記述され、WebアプリケーションによってWebサーバーを介してコールされます。しかし、CGIはアーキテクチャやスケーラビリティに制限があるため、理想的なプログラムでないことが実証されました。
Javaレルムでは、サーブレット・テクノロジは、データベースにアクセスするアプリケーションなどのサーバー集中型アプリケーションの場合、アプレット・テクノロジより利点があります。サーバーで実行することの利点の1つは、サーバーが通常多くのリソースを持つ堅牢なマシンであるため、プログラムがよりスケーラブルになることです。サーバーで実行すると、より直接的にデータにアクセスすることもできます。サーブレットが稼働中のWebサーバーは、アクセス対象データと同様に、ネットワーク・ファイアウォールの内側にあります。
サーブレットのプログラミングには、サーバー・サイドのWebアプリケーション開発における初期のモデルと比べると、次のような多くの利点もあります。
http://java.sun.com/j2ee/docs.html
サーブレットは、Javaプログラミング言語で記述されているため、Java Virtual Machine（JVM）を持つすべてのプラットフォーム、およびサーブレットをサポートしているすべてのWebサーバーでサポートされます。サーブレットは、再コンパイルせずに別のプラットフォーム上で使用できます。サーブレットをグラフィックス、サウンドおよび他のデータなどの関連するファイルとともにパッケージングして、完全なWebアプリケーションを作成することができます。パッケージングによって、アプリケーションの開発とデプロイが簡素化されます。
さらに、サーブレット・ベースのアプリケーションを他のWebサーバーからOC4Jに簡単に移植できます。J2EE準拠のWebブラウザ用に開発されたアプリケーションの場合、移植の手間は最小限で済みます。
サーブレットには、予測可能で管理可能なライフ・サイクルが存在します。
web.xmlWebモジュール構成ファイルから読み取られます。これらの詳細には初期化パラメータを含めることができます。
service()を起動します。service()メソッドはそのリクエストを、リクエスト・ヘッダーの情報に基づいて、doGet()（HTTP GETリクエストの場合）、doPost()（HTTP POSTリクエストの場合）、またはその他のオーバーライドされたリクエスト処理メソッドに委任します。
java.io.PrintWriterまたはjavax.servlet.ServletOutputStreamオブジェクトを使用して、レスポンス・オブジェクトを書き込みます。
destroy()メソッドをコールします。
アプリケーションには、サーブレットに加えて、JSPページやEJBなどのサーバー・サイド・コンポーネントを組み込むことができます。サーブレットは、OC4Jサーブレット・コンテナによって管理されます。一方、EJBはOC4J EJBコンテナ、JSPページはOC4J JSPコンテナによって管理されます。これらのコンテナはOC4Jの中核を形成します。
サーブレットとJSPページは、特に密接に対応しています。 サーブレットとJSPページは、ともに「Webコンポーネント」と呼ばれ、どちらもweb.xmlファイルを使用して構成されます。JSPページの変換時にJSPコンテナによって作成されるJSPページ実装クラスは、実際にはサーブレットであり、他のサーブレットと同じようにjavax.servlet.Servletインタフェースを実装しています。JSPページとサーブレットは、Webアプリケーションを作成する際に、透過的に併用することができます。
サーブレットまたはJSPページは、しばしば、後続の処理を実行するためにEJBをコールします。一般的なJ2EEアプリケーションは、ユーザー・インタフェースやユーザー・リクエストの初期処理にサーブレットまたはJSPページを使用し、EJBをコールしてビジネス・ロジックやデータベース・アクセスを実行します。
JSPページとEJBの詳細は、次のマニュアルを参照してください。
この項では、サーブレット・モデルの重要なコンポーネントとプログラミング・インタフェースをまとめます。この項には、次の内容が含まれます。
この項で説明するAPIの詳細は、次のサイトでSun社のjavax.servletおよびjavax.servlet.httpパッケージのJavadocを参照してください。
http://java.sun.com/j2ee/1.4/docs/api/index.html
Javaサーブレットは、当然javax.servlet.Servletインタフェースを実装しています。このインタフェースは、サーブレットの初期化、リクエストの処理、サーブレットの構成情報や他の基本情報の取得、およびサービスからのサーブレット・インスタンスの削除などを行うメソッドを指定します。
Webアプリケーションの場合は、javax.servlet.http.HttpServlet抽象クラスを拡張して、Servletインタフェースを実装できます。このクラスは、Webサイトに適したHTTPサーブレット用で、Servletインタフェースを実装するjavax.servlet.GenericServletクラスを拡張します。
HttpServletクラスには、次のメソッドが含まれています。これらのメソッドは、サーブレットの実行時に、必要に応じて、OC4Jサーブレット・コンテナによってコールされます（この章の後半を参照）。また、これらのどのメソッドについても、必要に応じて、コードを作成してオーバーライドすることによって、サーブレットで機能を提供することができます。 「サーブレット・インタフェースのメソッドを実装する場面」を参照してください。
void init(ServletConfig config)リクエストを処理できるように、サーブレットを初期化します。 入力として、サーブレット構成オブジェクト（「サーブレット構成オブジェクト」を参照）を取得します。サーブレットのすべての特別な起動要件に対して、このコードを実装します。
void destroy()サービスからサーブレットを削除します。サーブレットのすべての特別なシャットダウン要件（リソースの解放など）に対して、このコードを実装します。
void doGet(HttpServletRequest req, HttpServletResponse resp)HTTP GETリクエストを実行するには、このコードを実装します。HTTPのリクエスト・オブジェクトおよびレスポンス・オブジェクトについては、次項の「サーブレット通信: リクエスト・オブジェクトおよびレスポンス・オブジェクト」を参照してください。
void doPost(HttpServletRequest req, HttpServletResponse resp)HTTP POSTリクエストを実行するには、このコードを実装します。
void doPut(HttpServletRequest req, HttpServletResponse resp)HTTP PUTリクエストを実行するには、このコードを実装します。
void doDelete(HttpServletRequest req, HttpServletResponse resp)HTTP DELETEリクエストを実行します。
String getServletInfo()サーブレットに関する情報（作成者、リリース日など）を取得します。
次のメソッドもあります。
void service(HttpServletRequest req, HttpServletResponse resp)これは、サーブレットの主要メソッドです。HTTPリクエストを受信し、デフォルトで、そのリクエストを、定義済の適切なdoXXX()メソッドに送信します。通常、このメソッドをオーバーライドする必要はありません。
ServletConfig getServletConfig()初期化および起動パラメータを含むサーブレット構成オブジェクトを取得します。
前の項で説明した、HTTP操作のdoGet()、doPost()、doPut()およびdoDelete()を処理するサーブレット・メソッドは、HTTPリクエスト・オブジェクト（javax.servlet.ServletRequestインタフェースを拡張するjavax.servlet.http.HttpServletRequestインタフェースを実装するクラスのインスタンス）とHTTPレスポンス・オブジェクト（javax.servlet.ServletResponseインタフェースを拡張するjavax.servlet.http.HttpServletResponseインタフェースを実装するクラスのインスタンス）を入力として取得します。
リクエスト・オブジェクトは、サーブレットにHTTPリクエストに関する情報を提供します。情報には、リクエスト・パラメータ名と値、リクエストを作成したリモート・ホスト名、リクエストを受信したサーバー名などが含まれます。レスポンス・オブジェクトは、レスポンスの送信時に、コンテンツ長とMIMEタイプの指定および出力ストリームの指定など、HTTP固有の機能を提供します。
この項では、HTTPリクエスト・オブジェクトに関係のあるメソッドをまとめます。 いくつかのメソッドの使用例は、「HTMLフォームおよびリクエスト・パラメータの使用方法」を参照してください。
次のメソッドは、HttpServletRequestインタフェースで定義されます。
HttpSession getSession()このリクエストに関連付けられたクライアント・セッションを表すオブジェクトを（必要に応じて作成してから）返します。「サーブレット・セッション（ユーザー・セッション）の使用目的」を参照してください。 オプションで、ブールのtrueまたはfalseを入力して、セッションがあらかじめ存在しない場合に新しいセッションを作成するかどうかを指定できます。
Cookie[] getCookies()セッション・トラッキングに使用される、このリクエストとともに送信されたCookieの一連のCookieオブジェクトを返します。 「サーブレットでのCookieの使用方法」を参照してください。
java.lang.StringBuffer getRequestURL()このリクエストに使用されたURLを再作成します。
String getContextPath()このリクエストのURLのコンテキスト・パス部分を返します。これは、Webアプリケーションのサーブレット・コンテキストのルート・パスに対応します。 「URL構成要素のサマリー」を参照してください。
String getServletPath()このリクエストのURLのサーブレット・パス部分を返します。これは、標準web.xmlファイルでの構成に従って、リクエストされている特定のサーブレットを起動する部分です。
String getRequestURI()このリクエストのURLの、ホストおよびポートの後ろの部分（問合せ文字列がある場合は問合せ文字列まで）を返します。これは、通常、コンテキスト・パスおよびサーブレット・パスです。
String getQueryString()「?」デリミタの後に、URL（該当する場合）に追加される問合せ文字列を返します。
String getMethod()このリクエストとともに使用されるGET、POSTまたはPUTなどのHTTPメソッドを返します。
String getProtocol()プロトコル（通常、HTTP）と使用されているバージョンを返します。
次のメソッドは、ServletRequestインタフェースから継承されます。
String getParameter(String name)名前によって指定されるリクエスト・パラメータの値を示す文字列（検出されない場合は、null）を返します。
java.util.Enumeration getParameterNames()このリクエストのすべてのリクエスト・パラメータの名前を示す文字列を含む列挙オブジェクトを返します。
javax.servlet.ServletInputStream getInputStream()リクエストのボディをバイナリ形式で取得します。
java.io.BufferedReader getReader()リクエストのボディを文字形式で取得します。
String getContentType()このリクエストのボディのMIMEタイプを示す文字列（MIMEタイプが不明の場合は、null）を返します。
void setCharacterEncoding(String charset)オーバーライドしないと、このリクエストのボディおよびパラメータの解析に使用される文字コード（MIMEキャラクタ・セット）をオーバーライドします。
String getCharacterEncoding()このリクエストのボディおよびパラメータの解析に使用される文字コードを示す文字列を返します。
RequestDispatcher getRequestDispatcher(String path)指定されたパスにあるリソースのラッパーとして使用されるリクエスト・ディスパッチャを返します。 「インクルードおよび転送による他のサーブレットへのディスパッチ」を参照してください。
この項では、HTTPレスポンス・オブジェクトに関係のあるメソッドをまとめます。 詳細は、「レスポンスの設定」を参照してください。
次のメソッドは、HttpServletResponseインタフェースで定義されます。
void sendRedirect(String location)リダイレクトについて、クライアントがリダイレクトされる代替の場所（URL）を指定します。（リダイレクションは、たとえば、ロード・バランシングのために行われます。また、ドキュメントが別のURLに移動したことなどが理由で行われます。）
String encodeURL(String url)セッション・トラッキングについて、Cookieが無効になっている場合、指定されたURLをセッションのIDによってエンコードするためにURLリライティングで使用されます。エンコードされたURLを返します。 「セッション・トラッキングのためのURLリライティングの使用」を参照してください。
String encodeRedirectURL(String url)リダイレクトについて、encodeURL()と同じ機能を実行します。
void addCookie(javax.servlet.http.Cookie cookie)セッション・トラッキングについて、Cookieが有効になっている場合、指定されたCookieをレスポンスに追加します。 「サーブレットでのCookieの使用方法」を参照してください。
void sendError(int code)void sendError(int code, String msg)エラー・レスポンスを、指定された整数エラー・コードとともにクライアントに送信します。オプションで、説明メッセージを指定することもできます。
次のメソッドは、ServletResponseインタフェースから継承されます。
javax.servlet.ServletOutputStream getOutputStream()クライアントへのレスポンスにバイナリ・データを書き込むために使用することができるストリーム・オブジェクトを返します。
java.io.PrintWriter getWriter()クライアントへのレスポンスに文字データを書き込むために使用することができるPrintWriterオブジェクトを返します。
void setContentType(String type)このレスポンスのボディのMIMEタイプを指定します。オプションで、文字コード（MIMEキャラクタ・セット）を指定することもできます。たとえば、「text/html;charset=UTF-8」と指定します。
String getContentType()このレスポンスのボディのMIMEタイプを示す文字列を返します。このメソッドは、文字コード（MIMEキャラクタ・セット）も返します（指定されている場合）。
void setCharacterEncoding(String charset)このレスポンスのボディの文字コードを指定します。文字コードは、setContentType()メソッドを使用して指定することもできます。setCharacterEncoding()での設定は、setContentType()で設定されるすべての文字コードをオーバーライドします。
String getCharacterEncoding()このレスポンスのボディの文字コードを示す文字列を返します。
Javaクライアント・プログラムとは異なり、サーブレットには静的なmain()メソッドがありません。したがって、サーブレットは、外部コンテナの制御下で実行する必要があります。
サーブレット・コンテナは、サーブレット・エンジンとも呼ばれ、サーブレットの実行と管理を行います。サーブレット・コンテナは、サーブレット・メソッドをコールし、サーブレットの実行中に必要なサービスを提供します。サーブレット・コンテナは通常Javaで作成し、Webサーバーに組み込むか（WebサーバーもJavaで作成されている場合）、Webサーバーに関連付けて使用します。OC4Jには、完全な標準準拠のサーブレット・コンテナが組み込まれます。
サーブレット・コンテナにより、サーブレットは、ヘッダーやパラメータなどHTTPリクエストのプロパティに容易にアクセスできます。URLによる指定などでサーブレットがコールされると、Webサーバーは、HTTPリクエストをサーブレット・コンテナに渡します。コンテナは、次に、そのリクエストをサーブレットに渡します。サーブレットの管理で、サーブレット・コンテナは、次のタスクを実行します。
init()メソッドをコールして初期化します。
HttpServletクラスに実装されている、サーブレットのservice()メソッドを起動します。サービス・メソッドは、リクエスト内のHTTPヘッダーに応じて（GETまたはPOST）、サーブレットのdoGet()またはdoPost()メソッドにリクエストを送ります。
destroy()メソッドをコールして、必要に応じてそのサーブレットをガベージ・コレクションの対象とするために破棄します。（パフォーマンス上の理由から、通常サーブレット・コンテナはサーブレット・インスタンスをメモリー内に保持して再利用します。タスクが終了するたびにインスタンスを破棄することはありません。破棄されるのは、Webサーバー・シャットダウンなどの使用頻度が低いイベントの場合のみです。）
図1-1に、サーブレットがサーブレット・コンテナおよびWebブラウザなどのクライアントとどのように関連するかを示します。
JavaオブジェクトおよびEnterprise JavaBeans（EJB）をリレーショナル・データベースに格納、およびJavaオブジェクトとXML文書（JAXB）の間の変換用メカニズムを提供するJavaのオブジェクトとリレーショナル間の永続性アーキテクチャであるOracle TopLinkを使用することにより、サーブレットでJ2EE永続性を使用できます。 TopLinkを使用して、永続性およびオブジェクト変換をアプリケーションに統合する方法の詳細は、『Oracle TopLink開発者ガイド』を参照してください。
サーブレット構成オブジェクトには、サーブレットの初期化および起動パラメータが含まれます。このオブジェクトは、javax.servlet.ServletConfigインタフェースを実装するクラスのインスタンスです。このクラスは、任意のJ2EE準拠のWebサーバーにより提供されます。
サーブレットは、サーブレットのgetServletConfig()メソッドを使用して、サーブレット構成オブジェクトを取得することができます。このメソッドはjavax.servlet.Servletインタフェースで指定されており、javax.servlet.http.HttpServletクラスでデフォルトが実装されています。
サーブレットのinit()メソッドは、入力としてServletConfigオブジェクトを取得します。このため、init()メソッドをオーバーライドすると、サーブレットは、サーブレット・コンテナがサーブレットの実行時に作成して渡すサーブレット構成オブジェクトにアクセスします。
ServletConfigインタフェースは、次のメソッドを指定します。
ServletContext getServletContext()アプリケーションのサーブレット・コンテキストを取得します。次項の「サーブレット・コンテキスト: アプリケーション・コンテナ」を参照してください。
String getServletName()サーブレットの名前を取得します。
Enumeration getInitParameterNames()サーブレットの初期化パラメータの名前がある場合、その名前を取得します。名前は、Stringオブジェクトのjava.util.Enumerationインスタンスに戻されます。（初期化パラメータがない場合、Enumerationインスタンスは空です。）
String getInitParameter(String name)指定した初期化パラメータの値を含むStringオブジェクトを戻します。その名前のパラメータがない場合は、nullを戻します。
サーブレット・コンテキストは、単一JVM内のWebアプリケーションの全インスタンス（つまり、Webアプリケーションに含まれる全サーブレットとJSPページ・インスタンス）に関する情報を保持するために使用します。任意のJVM内で稼働するWebアプリケーションごとに1つのサーブレット・コンテキストがあります。これは常に1対1の設定です。サーブレット・コンテキストは、特定のアプリケーションのコンテナと考えられます。
サーブレット・コンテキストは、javax.servlet.ServletContextインタフェースを実装するクラスのインスタンスです。このクラスは、サーブレットをサポートするWebサーバーに含まれています。
ServletContextオブジェクトは、サーブレット環境に関する情報（サーバー名など）を提供し、単一JVM内のグループのサーブレット間でリソースを共有できるようにします。（同時に複数のJVMをサポートしているサーブレット・コンテナの場合、リソース共有の実装は一様ではありません。）
サーブレット・コンテキストは、アプリケーションの実行インスタンスに対してスコープを設定します。このメカニズムによって、各アプリケーションは別個のクラスローダーからロードされ、その実行時オブジェクトは他のアプリケーションのオブジェクトとは明確に区別されます。特に、ServletContextオブジェクトはアプリケーションごとに異なります。これは、各HttpSessionオブジェクトがそのアプリケーションのユーザーごとに異なるのと同じです。
サーブレット仕様のバージョン2.2から、ほとんどの実装で単一ホスト内に複数のサーブレット・コンテキストを設定できます。そのため、各Webアプリケーションが独自のサーブレット・コンテキストを持つことができます。（以前の実装では、任意のホストに設定できるサーブレット・コンテキストは1つのみでした。）
サーブレットは、サーブレット構成オブジェクトのgetServletContext()メソッドを使用して、サーブレット・コンテキストを取得することができます。 「サーブレット構成オブジェクト」を参照してください。
ServletContextインタフェースは、サーブレットにそのサーブレットを実行するサーブレット・コンテナとの通信を許可するメソッドを指定します。この方法によって、サーブレットはアプリケーション・レベルの環境と状態情報を取得できます。ServletContextでは、次のようなメソッドが指定されます。
void setAttribute(String name, Object value)指定したオブジェクトをサーブレット・コンテキストの指定した属性名にバインドします。属性を使用すると、サーブレット・コンテナは、サーブレットに情報を提供できます。属性を使用しない場合、ServletContextインタフェースを介して情報を提供できません。
Object getAttribute(String name)指定した名前を持つ属性を戻します。その名前の属性がない場合は、nullを戻します。属性は、java.lang.Objectインスタンスとして戻されます。
java.util.Enumeration getAttributeNames()サーブレット・コンテキストで使用可能な全属性の名前が含まれたjava.util.Enumerationインスタンスを戻します。
void removeAttribute(String attrname)指定した属性をサーブレット・コンテキストから削除します。
String getInitParameter(String name)指定したコンテキスト全体の初期化パラメータの値を示す文字列を戻します。その名前のパラメータがない場合は、nullを戻します。これによって、このサーブレット・コンテキストに関連付けられたWebアプリケーションに有用な構成情報にアクセスできます。
Enumeration getInitParameterNames()サーブレット・コンテキストの初期化パラメータ名が含まれたjava.util.Enumerationインスタンスを戻します。
RequestDispatcher getRequestDispatcher(String path)指定されたパスにあるリソースのラッパーとして動作するリクエスト・ディスパッチャを戻します。 「インクルードおよび転送による他のサーブレットへのディスパッチ」を参照してください。
RequestDispatcher getNamedDispatcher(String name)指定したサーブレットのラッパーとして動作するリクエスト・ディスパッチャを戻します。
String getRealPath(String path)指定した仮想パスに対する実際のパスを文字列で戻します。
URL getResource(String path)指定したパスにマップされたリソースに対するURLが含まれたjava.net.URLインスタンスを戻します。
String getServerInfo()サーブレット・コンテナの名前とバージョンを戻します。
String getServletContextName()web.xmlファイルの<display-name>要素に基づいて、サーブレット・コンテキストが関連付けられているWebアプリケーションの名前を戻します。
HTTPプロトコルは、設計上ステートレスです。これは、単にリクエストを取得し、簡単な処理を行って結果を出力した後に消滅するような、ステートレスなサーブレットについては問題ありません。ただし、ほとんどのサーバー・サイド・アプリケーションでは、状態情報を保持してクライアントとの対話を続ける必要があります。このような場合の最も一般的な例は、ショッピング・カートのアプリケーションです。クライアント・ユーザーは、同じブラウザから何度かサーバーにアクセスして、いくつかのWebページを表示します。クライアント・ユーザーは、Webサイトで販売されているいくつかのアイテムの購入を決め、「製品の購入」ボタンをクリックします。各トランザクションがステートレスなサーバー・サイド・オブジェクトで処理されており、各リクエストに対してクライアントから識別情報が提供されない場合、クライアントからの複数のHTTPリクエストに渡ってショッピング・カートの中身を維持することはできません。このケースでは、クライアントをサーバー・セッションに関連付ける手段がないため、ステートレスなトランザクション・データを永続性のある記憶域に書き込んでも問題は解決されません。
セッション・トラッキングは、ユーザー・セッションを識別し、ユーザーのすべてのリクエストをそのユーザーのセッションに適切に関連付けます。このプロセスは通常CookieまたはURLリライティングによって実行されます。
標準サーブレットAPIでは、各ユーザー・セッションは、javax.servlet.http.HttpSessionインタフェースを実装するクラスのインスタンスによって表されます。
詳細は、第3章「サーブレット・セッションの理解および使用方法」を参照してください。
非分散環境のサーブレットでは、サーブレット・コンテナは1回のサーブレット宣言当たり1つのサーブレット・インスタンスのみ使用します。分散環境では、コンテナは各JVMの1回のサーブレット宣言当たり1つのサーブレット・インスタンスを使用します。したがって、OC4Jサーブレット・コンテナを含めたサーブレット・コンテナがサーブレットに対する同時リクエストを処理するには、一般的に複数のスレッドを使用してサーブレットの主要メソッドのservice()を同時に複数実行します。
サーブレットの開発者は、この点を念頭に置き、複数のスレッドによる同時処理用の措置を講じ、共有リソースへのアクセスが同期化または調整されるよう、サーブレットを設計する必要があります。 詳細は、「スレッド・モデルの考慮事項」を参照してください。
表1-1は、このマニュアルで説明しているサーブレット開発機能（前述のものを含む）と情報の相互参照をまとめたものです。サーブレット2.4仕様で追加された機能が注記されています。
| 機能 | 情報 |
|---|---|
|
リクエスト・オブジェクトおよびレスポンス・オブジェクト |
|
|
サーブレット・コンテナ |
|
|
サーブレット構成オブジェクト |
|
|
サーブレット・コンテキスト |
|
|
セッション |
「サーブレット・セッション（ユーザー・セッション）の使用目的」の概要、第3章「サーブレット・セッションの理解および使用方法」の詳細 |
|
インクルードおよび転送 |
|
|
サーブレット・フィルタ |
「前処理および後処理のためにフィルタを使用する場面」の概要、第4章「サーブレット・フィルタの理解および使用方法」の詳細 注意: インクルードまたは転送ターゲットとともにフィルタを使用する機能は、サーブレット2.4仕様で追加されました。 |
|
イベント・リスナー |
「サーブレット通知にイベント・リスナーを使用する場面」の概要、第5章「イベント・リスナーの理解および使用方法」の詳細 注意: （サーブレット・コンテキストやセッション・リスナーとは異なる）リクエスト・リスナーのサポートは、サーブレット2.4仕様で追加されました。 |
|
JDBCおよびデータソースの使用 |
|
|
EJBの使用 |
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|