サーブレット&JSPの基本｜アプリケーションサーバのしくみ

サーブレット&JSPの基本｜アプリケーションサーバのしくみ

ブラウザから届いた要求をJavaの処理へつなぐ、アプリケーションサーバの役割を理解しよう。

サーブレットクラスを作成できたとしても、そのJavaファイルをWebサーバへ置くだけでは、ブラウザから実行することはできません。

一般的なWebサーバには、ブラウザから送られたHTTPリクエストを受け取り、HTMLや画像などのファイルを返す機能があります。しかし、Javaで書かれたサーブレットクラスを読み込み、必要なメソッドを呼び出し、実行結果をHTTPレスポンスとして返す機能までは持っていません。

そこで必要になるのが、アプリケーションサーバです。

JavaによるWebアプリケーション開発では、Webサーバとしての通信機能に加えて、サーブレットやJSPを実行するための環境を備えたソフトウェアを利用します。その中心となる機能が、サーブレットコンテナです。

サーブレットコンテナは、ブラウザから届いたリクエストを適切なサーブレットへ渡し、サーブレットを実行して、その結果をブラウザへ返すまでを支えてくれます。

ここでは、通常のWebサーバとアプリケーションサーバの違い、サーブレットコンテナの役割、Apache Tomcatの特徴、Webアプリケーションを配置して実行する流れを順番に見ていきましょう。

通常のWebサーバだけではサーブレットを実行できない

Webサーバは、ブラウザから送られたHTTPリクエストを受け取り、要求されたデータをHTTPレスポンスとして返します。

たとえば、ブラウザからindex.htmlが要求された場合、Webサーバは保存されているindex.htmlを探し、その内容をブラウザへ返します。

このような処理は、静的なWebページの配信です。

一方、サーブレットは固定されたファイルをそのまま返すものではありません。ブラウザから送られた情報を受け取り、Javaのプログラムを実行し、その結果に応じたHTMLなどを生成します。

サーブレットを動かすには、次のような処理が必要です。

1. HTTPリクエストを受け取る
2. URLに対応するサーブレットを探す
3. サーブレットクラスを読み込む
4. 必要に応じてインスタンスを生成する
5. GETやPOSTに対応するメソッドを呼び出す
6. リクエスト情報をJavaから扱える形にする
7. サーブレットが作った結果をHTTPレスポンスへ変換する
8. ブラウザへレスポンスを返す

一般的なWebサーバには、このようなJavaプログラムの実行管理機能がありません。

そのため、JavaによるWebアプリケーションを動かすには、サーブレットを実行できる環境が必要になります。

Webサーバとアプリケーションサーバの違い

Webサーバとアプリケーションサーバは、どちらもブラウザからのアクセスを受け付けますが、担当できる処理が異なります。

学習上は、Webサーバの機能とサーブレットコンテナの機能を持つ環境を、アプリケーションサーバと呼ぶことがあります。

ただし、厳密な製品分類では、Apache TomcatやJettyはサーブレットコンテナ、またはWebコンテナと呼ばれることが多く、WebSphere Application ServerやOracle WebLogic Serverのような多くの業務機能を備えた製品を、アプリケーションサーバと区別して呼ぶ場合もあります。

最初の段階では、次のように整理すると分かりやすいでしょう。

• Webサーバ機能は、HTTPリクエストを受け取り、静的ファイルなどを返す
• サーブレットコンテナ機能は、サーブレットやJSPを管理して実行する
• 学習で使用するサーバ環境は、この2つの機能を組み合わせてWebアプリケーションを動かす

図1：Webサーバとアプリケーションサーバの違い

この図から分かること

通常のWebサーバは、保存されているHTMLや画像などを探してブラウザへ返すことを得意としています。

一方、Javaのサーブレットを動かすには、Javaクラスを管理して実行する機能が必要です。その役割を担当するのがサーブレットコンテナです。

JavaのWebアプリケーションを動作させる環境では、HTTP通信を担当するWebサーバ機能と、Javaプログラムを実行するサーブレットコンテナ機能が連携しています。

サーブレットコンテナとは

サーブレットコンテナは、サーブレットを実行するための専用環境です。

サーブレットクラスを単にJavaのプログラムとして起動するのではなく、HTTPリクエストとの対応付けや、オブジェクトの生成、メソッドの呼び出しなどを管理します。

開発者がサーブレットクラスを作成すると、サーブレットコンテナがブラウザとサーブレットの間に入り、必要な処理を自動的に行ってくれます。

HTTPリクエストを受け取る

ブラウザがWebアプリケーションのURLへアクセスすると、HTTPリクエストがサーバへ届きます。

サーブレットコンテナは、リクエストされたURLを確認し、どのWebアプリケーションに属する要求なのかを判断します。

URLに対応するサーブレットを探す

Webアプリケーションでは、URLとサーブレットを対応付けます。

たとえば、商品一覧を表示するURLには商品一覧用のサーブレット、ログイン処理を行うURLにはログイン用のサーブレットを対応させます。

サーブレットコンテナは、この対応付けをもとに、実行するサーブレットを決定します。

リクエストとレスポンスのオブジェクトを用意する

ブラウザから届くHTTPリクエストは、文字列や通信データで構成されています。

サーブレットコンテナは、これらをJavaプログラムから扱いやすいオブジェクトへ変換します。

サーブレットでは、主に次のオブジェクトを使用します。

開発者は通信データを最初から解析する必要がありません。サーブレットコンテナが用意したオブジェクトを通じて、必要な情報を取得したり、返すデータを設定したりできます。

サーブレットのメソッドを呼び出す

サーブレットコンテナは、リクエストメソッドに応じて、サーブレットの適切な処理を呼び出します。

ブラウザからGETリクエストが送られると、サーブレットコンテナは対応するサーブレットのdoGetを呼び出します。

POSTリクエストが送られると、doPostを呼び出します。

開発者がmainメソッドからサーブレットを直接呼び出すわけではありません。サーブレットコンテナが、HTTP通信とJavaのメソッド呼び出しを結び付けています。

実行結果をHTTPレスポンスにする

サーブレットが処理を終えると、サーブレットコンテナは設定された内容をもとにHTTPレスポンスを作成します。

レスポンスには、次のような情報が含まれます。

• HTTPステータスコード
• Content-Type
• 文字コード
• Cookie
• HTMLなどのデータ本体

作成されたHTTPレスポンスは、Webサーバ機能を通じてブラウザへ返されます。

サーブレットコンテナが管理する範囲

サーブレットコンテナは、単にJavaクラスを実行するだけではありません。Webアプリケーションを安定して動かすためのさまざまな機能を持っています。

これらをすべて自分で作るのは大変です。

サーブレットコンテナを利用することで、開発者はWebアプリケーション固有の処理に集中できます。

アプリケーションサーバ内で処理される流れ

ブラウザからサーブレットへリクエストが送られると、サーバ内では複数の処理が行われます。

たとえば、商品検索用のサーブレットへアクセスした場合は、次のように進みます。

1. ブラウザが検索条件を含むHTTPリクエストを送る
2. Webサーバ機能がHTTPリクエストを受け取る
3. 動的な処理が必要だと判断する
4. リクエストをサーブレットコンテナへ渡す
5. サーブレットコンテナがURLに対応するサーブレットを探す
6. HttpServletRequestとHttpServletResponseを用意する
7. 検索用サーブレットのdoGetまたはdoPostを呼び出す
8. サーブレットが検索処理を実行する
9. サーブレットまたはJSPがHTMLを生成する
10. サーブレットコンテナがHTTPレスポンスを作る
11. Webサーバ機能がレスポンスをブラウザへ返す
12. ブラウザが結果を表示する

この間、利用者が操作しているのはブラウザだけです。

Webサーバ機能とサーブレットコンテナの間でどのような処理が行われているかは、通常、利用者からは見えません。

図2：サーブレットが実行されるまでの流れ

この図から分かること

ブラウザから届いたリクエストは、最初にサーバのHTTP通信機能が受け取ります。

サーブレットの実行が必要な場合は、リクエストがサーブレットコンテナへ渡されます。サーブレットコンテナはURLに対応するサーブレットを選び、必要なメソッドを呼び出します。

実行結果は再びHTTPレスポンスへ変換され、ブラウザへ返されます。

Tomcatは、HTTPによる通信とJavaプログラムの実行を結び付ける役割を持っています。

Apache Tomcatとは

Apache Tomcatは、JavaによるWebアプリケーションを動かすためのオープンソースソフトウェアです。

Apache Software Foundationによって開発されており、サーブレットやJSPを実行するための環境を提供します。

学習教材では、Tomcatをアプリケーションサーバと呼ぶことがあります。厳密には、TomcatはサーブレットコンテナやWebコンテナとして位置付けられる製品です。

Tomcatには、主に次の機能があります。

• HTTPリクエストの受け付け
• HTMLや画像などの静的ファイルの配信
• サーブレットの実行
• JSPの変換と実行
• セッション管理
• Webアプリケーションの配置と起動
• ログの出力
• エラーページの表示
• 複数のWebアプリケーションの管理

Tomcatをパソコンへインストールして起動すると、そのパソコンをJavaのWebアプリケーションを実行できるサーバとして利用できます。

Tomcatが学習で利用される理由

Tomcatは、サーブレットとJSPの学習環境として広く利用されています。

その理由には、次のようなものがあります。

無料で利用できる

Tomcatはオープンソースソフトウェアであり、学習や開発で利用できます。

商用製品のようなライセンス費用を必要としないため、個人学習や学校、企業研修でも導入しやすいソフトウェアです。

サーブレットとJSPの基本を学びやすい

Tomcatは、サーブレットとJSPを実行するための主要な機能を提供します。

大規模な商用アプリケーションサーバに比べると構成が比較的シンプルなので、リクエストがどのサーブレットへ届き、どのようにレスポンスが返されるのかを学びやすくなっています。

動作が比較的軽い

Tomcatは、サーブレットやJSPを中心としたWebアプリケーションの実行に必要な機能へ重点を置いています。

多くの機能を最初から備えた大規模なアプリケーションサーバと比較すると、構成を小さくしやすく、開発用のパソコンでも動かしやすいという利点があります。

実際の開発でも利用される

Tomcatは学習専用のソフトウェアではありません。

実際のWebサービスや社内システムでも利用されています。必要な機能をライブラリや外部製品と組み合わせながら、システムを構築できます。

TomcatとApache HTTP Serverは別のソフトウェア

Apache TomcatとApache HTTP Serverは、どちらもApacheという名前を含みますが、別のソフトウェアです。

TomcatにもHTTP通信や静的ファイル配信の機能があるため、学習環境ではTomcatだけでWebアプリケーションを動かせます。

一方、大規模なシステムでは、Apache HTTP ServerやほかのWebサーバを前段に置き、動的なJava処理をTomcatへ転送する構成もあります。

その場合は、次のように役割を分担します。

1. Webサーバがブラウザからのアクセスを受け付ける
2. 静的ファイルであればWebサーバが返す
3. サーブレットの処理であればTomcatへ転送する
4. Tomcatがサーブレットを実行する
5. 実行結果をWebサーバ経由でブラウザへ返す

学習中は、まずTomcat単体でサーブレットとJSPを動かし、HTTP通信とJava処理の流れを理解すれば十分です。

代表的なサーバソフトウェア

JavaのWebアプリケーションを実行できるソフトウェアには、Tomcat以外にもさまざまな製品があります。

TomcatやJettyは、サーブレットやJSPなどのWeb機能を中心に提供します。

WebSphereやWebLogicなどのアプリケーションサーバは、Web機能に加えて、大規模な業務システム向けのさまざまな機能を備えています。

ただし、学習を始める段階で、それぞれの製品機能を細かく覚える必要はありません。

まずは、サーブレットとJSPを実行するためには、対応するコンテナまたはサーバソフトウェアが必要であることを押さえておきましょう。

製品が変わるとサーブレットの書き方も変わるのか

使用するサーバ製品が変わると、インストール方法、管理画面、設定ファイル、Webアプリケーションの配置方法などが変わることがあります。

しかし、サーブレットやJSPの基本的な仕様は標準化されています。

現在のJava Web技術では、サーブレットはJakarta Servlet、JSPはJakarta Server Pagesという仕様のもとで扱われます。以前の環境や教材ではJava ServletやJavaServer Pages、Java EEという名称が使われていることもあります。

標準仕様に沿って作成したWebアプリケーションであれば、対応するサーバ製品でも基本的な考え方や文法を利用できます。

つまり、TomcatでサーブレットとJSPの基本を学ぶことは、ほかの対応製品を使う場合にも役立ちます。

製品ごとの差を覚える前に、HTTPリクエストを受け取り、Javaで処理し、HTTPレスポンスを返すという共通の流れを身に付けることが大切です。

Webアプリケーションをサーバへ配置する

作成したサーブレットやJSPは、開発用のフォルダに保存しただけではブラウザから実行できません。

Tomcatなどのサーバが認識できる形で、Webアプリケーションを配置する必要があります。

この配置作業をデプロイと呼びます。

デプロイでは、サーブレットクラス、JSP、HTML、CSS、画像、ライブラリ、設定情報などを、1つのWebアプリケーションとしてまとめます。

Webアプリケーションに含まれる主なものは次のとおりです。

サーバは、配置されたWebアプリケーションを読み込み、ブラウザからアクセスできる状態にします。

コンテキストパスとは

1台のTomcatには、複数のWebアプリケーションを配置できます。

たとえば、次のようなアプリケーションを同じTomcatで動かせます。

• 社員管理アプリケーション
• 商品管理アプリケーション
• 予約管理アプリケーション

それぞれを区別するために、URLにはアプリケーションを表す部分が含まれます。この部分をコンテキストパスと呼びます。

URLが次の形であるとします。

http://localhost:8080/shop/ProductList

各部分の役割は次のようになります。

サーブレットへアクセスするときは、サーバの場所だけでなく、どのWebアプリケーションの、どの処理を呼び出すのかをURLで指定します。

localhostとポート番号

学習環境では、自分のパソコンにTomcatをインストールして使用することがよくあります。

自分自身のコンピュータを表すホスト名としてlocalhostを使用できます。

Tomcatの初期設定では、HTTP通信の待ち受けに8080番ポートが使われることがあります。

そのため、Tomcatが正しく起動しているかを確認するときには、次のようなURLへアクセスします。

http://localhost:8080/

URLの各部分には次の意味があります。

ただし、ポート番号は設定によって変更できます。別のアプリケーションが8080番ポートを使用している場合は、Tomcatを別のポートで動作させることもあります。

サーバの起動と停止

Tomcatをインストールしただけでは、Webアプリケーションへアクセスできません。Tomcatのプログラムを起動し、ブラウザからのリクエストを受け付けられる状態にする必要があります。

基本的な流れは次のとおりです。

1. Javaの実行環境を用意する
2. Tomcatをインストールまたは展開する
3. Tomcatを起動する
4. 指定されたポートでリクエストを待ち受ける
5. ブラウザからURLへアクセスする
6. Webアプリケーションを実行する
7. 作業終了後にTomcatを停止する

Tomcatが停止している状態でlocalhostのURLへアクセスしても、ブラウザは接続できません。

Webページが表示されないときは、プログラムの内容だけでなく、Tomcatが起動しているかも確認する必要があります。

図3：開発からデプロイ、実行までの流れ

この図から分かること

サーブレットやJSPを作成しただけでは、ブラウザからWebアプリケーションを利用できません。

作成したファイルをWebアプリケーションとしてまとめ、Tomcatが認識できる場所へデプロイします。その後、Tomcatを起動し、ブラウザからURLへアクセスします。

TomcatはURLに対応するWebアプリケーションやサーブレットを探し、必要な処理を実行して、結果をブラウザへ返します。

開発、デプロイ、サーバ起動、ブラウザからのアクセスという一連の流れを理解することが、サーブレット・JSP開発の基本になります。

アプリケーションサーバで起こりやすいトラブル

サーブレットやJSPを実行するときは、HTMLファイルを直接開く場合よりも確認する場所が増えます。

HTMLだけのページでは、タグやファイル名を中心に確認しました。

サーブレット・JSPでは、それに加えて、サーバの起動状態、Webアプリケーションの配置、URLの対応付け、Javaの例外なども確認します。

サーバログを確認する

Tomcatは、起動時の情報や、Webアプリケーションで発生したエラーをログへ出力します。

ブラウザに500 Internal Server Errorとだけ表示された場合でも、Tomcatのログには原因となったJavaの例外やファイル名、行番号などが記録されていることがあります。

サーバ側の問題を調べるときは、次の情報を確認します。

• Tomcatが正常に起動したか
• Webアプリケーションが読み込まれたか
• サーブレットが正しく登録されたか
• Javaの例外が発生していないか
• JSPの変換やコンパイルに失敗していないか
• ポート番号がほかのソフトウェアと重複していないか

ブラウザの画面だけでは、サーバ内部の問題をすべて判断できません。

Webアプリケーション開発では、ブラウザの表示とサーバログの両方を確認する習慣が大切です。

サーブレットのライフサイクル

サーブレットコンテナは、サーブレットの生成から終了までを管理します。この流れをサーブレットのライフサイクルと呼びます。

基本的には、次のように進みます。

1. サーブレットクラスを読み込む
2. サーブレットのインスタンスを生成する
3. 初期化処理を行う
4. ブラウザからのリクエストを処理する
5. 複数のリクエストに繰り返し対応する
6. サーバ停止などの際に終了処理を行う

サーブレットは、リクエストが届くたびに必ず新しいインスタンスが作られるとは限りません。

一般的には、サーブレットコンテナが管理する1つのインスタンスが、複数のリクエストを処理します。

そのため、サーブレットのフィールドへ利用者ごとの情報を保存すると、複数の利用者のデータが混ざる可能性があります。利用者ごとの情報は、リクエスト、セッション、データベースなど、目的に合った場所で管理する必要があります。

この点は、サーブレットのプログラムを作成するときに重要になります。

複数の利用者からのリクエストを処理する

公開されたWebアプリケーションには、複数の利用者が同時にアクセスします。

サーブレットコンテナは、複数のHTTPリクエストを効率よく処理するため、一般に複数の処理を並行して進めます。

たとえば、ある利用者が商品を検索している間に、別の利用者がログイン処理を行うことがあります。

サーブレットコンテナは、各リクエストを適切なサーブレットへ渡し、処理結果をそれぞれのブラウザへ返します。

開発者は、複数の利用者が同時に操作しても、情報が混ざらないようにプログラムを作る必要があります。

JSPもサーブレットコンテナが実行する

JSPファイルはHTMLに近い形で記述できますが、ブラウザが直接実行しているわけではありません。

サーブレットコンテナは、JSPへアクセスがあったとき、JSPをサーブレットクラスへ変換します。その後、Javaのコードとしてコンパイルし、実行します。

JSPの処理結果として生成されたHTMLが、HTTPレスポンスのボディ部へ入れられ、ブラウザへ返されます。

流れを整理すると、次のようになります。

このしくみからも、サーブレットとJSPが密接に関係していることが分かります。

用語を整理しよう

Webアプリケーションの実行環境には、似た言葉がいくつか登場します。

これらの用語は、教材、製品、開発現場によって少し異なる範囲で使われることがあります。

Tomcatをサーブレットコンテナと呼ぶこともあれば、学習上の分かりやすさからアプリケーションサーバと呼ぶこともあります。

名称だけにとらわれず、どの機能について話しているのかを考えることが大切です。

サーブレット・JSPの学習へ進むために

アプリケーションサーバは、ブラウザとJavaのプログラムをつなぐ重要な役割を持っています。

ブラウザはHTTPリクエストを送りますが、Javaのサーブレットを直接呼び出すことはできません。サーブレットコンテナがHTTPリクエストを受け取り、Javaから扱えるオブジェクトを用意し、適切なサーブレットを実行します。

サーブレットの処理結果は、サーブレットコンテナによってHTTPレスポンスへ変換され、ブラウザへ返されます。

これから実際にサーブレットやJSPを作成するときは、次の流れを意識すると理解しやすくなります。

1. Tomcatを起動する
2. ブラウザがURLへアクセスする
3. TomcatがHTTPリクエストを受け取る
4. サーブレットコンテナが対象のサーブレットを探す
5. doGetまたはdoPostを呼び出す
6. サーブレットがJavaの処理を行う
7. サーブレットまたはJSPがHTMLを生成する
8. TomcatがHTTPレスポンスを返す
9. ブラウザがHTMLを表示する

この一連の動きを頭に置いておくと、プログラムが動かなかったときにも、URL、Tomcat、サーブレット、JSP、レスポンスのどこに問題があるのかを順番に確認できるようになります。