Java Servlet 仕様書 v2.2

Java^TM Servlet 仕様書 v2.2 邦訳版

邦訳にあたって

サーブレットはウェブサーバサイドで動くServlet API使用のモジュールであり、従来のブラウザ用サーバのCGIスクリプトとのインターフェイスであるCGI(Common Gateway Interface)と比較して以下のような特徴を有する。

・クライアントの要求毎に新たなプロセスを必要としない

サーブレットは、サーバ上でひとつの常駐スレッドとして動作する。従って最初にインスタンス化するとき以外はCGIよりは高速で動作する

・マルチスレッドで動作する

複数のクライアントから同じ要求（例えばGETやPOST）が到来した場合、その要求に対応したメソッドは最初のクライアントに対する処理が終了しなくても新たなクライアント用として、別のスレッドに要求を割り当てる

・サーバ上に常駐する

例えば3層モデル（例えばブラウザからなるクライアント、サーバ上のサービスプロセス群、そしてデータベースといった構成）では、データベースなどその先のコネクションを張ったまま常駐するので、処理が早くなる

・セキュリティ・モデルがある

すべてのJava環境はSecurity Managerを有する。またサーブレットをJARファイルからアップロードするときもSecurity Managerが関与し、システムに危害を及ぼす恐れのある処理を実行しない

サーブレットは、プラットフォームに依存しない洗練されたサーバサイドアプリケーションを作成することができ、安全なネットワーク配信、スマートカードからスーパーコンピューティングまでのスケーラビリティが実現される。従って現在ウェブサーバの主流となりつつある。更にサーブレットはJSP(JavaServer Pages)として発展を続け、非常に簡単にアプリケーションが記述できるようになってきている。

Sun MicrosystemsのServlet APIをサポートするサーブレットエンジンとして現在ポピュラーなものは、LiveSofware のJrun、 New Atlanta のServletExec、Gefion のWAICoolRunner、IBM のWebSphere、そしてApacheのApache JServ などである。

サーブレットに関する日本語の資料も最近多くなった。しかし、より詳細に勉強したい方には結局Sunのチュートリアル、API参照と、今回邦訳した公式仕様書をお勧めすることになる。特に公式仕様書はサーブレットのドキュメントの原点であるにも関わらず、まだ日本語化されたものは見受けない。従ってここでは、この公式仕様書の翻訳を試みたものである。つたない翻訳なので、間違いがあればご指摘いただきたい。また、不明の個所は原文を参照いただきたい。邦訳による責は負いません。

サーブレット(Servlet)の概念

サーブレット(Servlet)とは

サーブレットとは要求／応答(Request/Response)ベースのサーバ（例えばJavaベースのウェブサーバ）を拡張するモジュールである。上図のようなオーダエントリシステムを考えてみよう。このような系は、良く3層クライアントサーバ構造(Three-tier Architecture)と呼ばれるものである。サーブレットは、HTMLのオーダエントリのフォームデータを受理し、これにこのシステムのビジネスロジックを適用し、データベースを更新する。サーブレットはサーバ上で動作し、Appletはブラウザ上で機能する。Appletと異なり、サーブレットはGUIを有さない。これから我々が作成しようとするサーブレットに使用するサーブレット APIは、サーバの環境やプロトコルを仮定してはいないので、サーブレットは各種のサーバ上に実装させることができる。特に現在は、HTTPサーバ上のサーブレットがもっとも一般的に使用されており、また多くのウェブサーバがサーブレットAPIに対応している。クライアントが一般的なブラウザそのものである場合は、このような系はクライアントに変更をかけることなく、サーバサイドでビジネスロジックの変更ができ、また各種ブラウザがクライアントとして使えるので一般的である。

サーブレットの位置付けを、よりソフトウエア的に説明すれば上の構成図のように捉えることができよう。サーブレット APIは、既存の成熟したウェブサーバに乗り、複雑性や特定のサーバに実装する為のプラットフォーム固有の振る舞いを遮蔽する。各サーブレットは、APIが提供する標準化されたクラスを使用する。前述のとおりサーブレットは一回ロードされると意図的に終了させない限りメモリ上に駐在する。APIからのservice(), doGet(), doPost()などのメソッドが、複数のクライアントからの要求に対応して、並行処理のためのスレッドを提供する。各サーブレットが共通資源にアクセスするときは、スレッドフリーなプログラムを書かねばならない。この図のように、外部データベースに対しては、ヘルパとしてその為のサーブレットを用意するのが一般的であろう。

サーブレットはまた、コンテナ(Container)により管理されたウェブコンポネントでもある。サーブレットコンテナとは何であろうか？サーブレットコンテナは、ウェブサーバ（あるいはアプリケーションサーバ）とともに、要求と応答の設定、MIMEベースのクライアントからの要求のデコード、及びクライアントへのMIMEベースの応答へのフォーマット化からなるネットワークサービスを提供するものである。サーブレットコンテナは、複数のサーブレットを各々のライフサイクルにわたって包含し、管理するものである。

事例として、ブラウザのごときクライアントプログラムがウェブサーバをHTTPのRequestでアクセスしたときを考えてみよう。この要求はウェブサーバで処理され、サーブレットコンテナに引き渡される。サーブレットコンテナは、その内部設定をもとにどのサーブレットに該当するか決定し、要求と応答のオブジェクトとともに該サーブレットを呼び出す。サーブレットコンテナは、ホストのウェブサーバと同じプロセスの中で実行できるし、同じホスト上の別のプロセスのなかで実行できるし、またはウェブサーバとは別の、要求を処理するホスト上で走らせることも可能である。

サーブレットはこの要求オブジェクトを、リモートユーザは誰か、この要求の部分として送られてきたHTMLフォームパラメタはなにか、及びその他の関連するデータを取得するのに使用する。これにより、サーブレットはプログラミングされたロジックを実行し、該クライアントに送り返すデータを作成できる。このデータは応答オブジェクトを介してクライアントに返される。該要求に対応した処理をサーブレットが終了したら、サーブレットコンテナは応答が正しくクライアントに送られ応答オブジェクトが消去されたことを確認し、制御をホストのウェブサーバにかえす。

サーブレットのスレッド処理

ところでサーブレットにおいて並行処理はどのように扱われるのであろうか？

複数のクライアントからの要求の同時処理には、下図のようにSingleThreadModelを実装してサーブレットのインスタンスのプールが使われる（もしそうなっていれば。プールされなければ要求が待ち行列に入れられる）ようにする方法と、あるサーブレットのインスタンスのserviceメソッドが複数のスレッドから呼ばれる方法とがあり得る。楕円で記したのがサーブレットのオブジェクトである。SingleThreadModelを実装したサーブレットでは、ひとつのserviceメソッドにはただひとつのスレッドしか存在しない。そうでない場合には複数のスレッドがserviceメソッドを走ることになる。この場合はこのメソッドをスレッドフリーとなるよう記述しなければならない。

ところでスレッドは誰がどのように生成・管理しているのだろうか？そのメカニズムは、Webサーバの要求処理スレッドが行う一連の過程の一例を知れば理解できる。

1. スレッドはTCPソケット(ポート80)を調べ、クライアントが接続するまで待機状態となる。

2. クライアントが接続するとスレッドは要求処理のため待機状態から目覚める。

3. スレッドは要求の情報をストアするための構造体を作成する為のHTTP受け取りを行う。

4. スレッドは誰が(file handler, cgi handler, webserver API plugin, servlet, etc..)該要求を処理するかを決定する。

5. スレッドはwebサーバのAPI層に入る。

6. スレッドはサーブレットエンジンに入る。

7. サーブレットエンジンはサーブレットのための要求と応答オブジェクトを組み立てる。

8. サーブレットエンジンはサーブレットを呼び出し、要求と応答のオブジェクトを渡す。

9. スレッドは該サーブレットのserviceメソッドに入る。

10. スレッドは該サーブレットのserviceメソッドを出る。

11. サーブレットエンジンは要求と応答のオブジェクトをクリーンアップする。（応答はwebサーバのAPI層に返す）

12. スレッドはサーブレットエンジンを出、webサーバのAPI層に戻る。

13. webサーバのAPI層は応答をクライアントに返す。

14. スレッドはwebサーバのAPI層を出る。

15. webサーバはスレッドをクリーンアップする。

16. ステップ1に戻る。

サーブレット APIの構成

Servlet仕様書の第2.2版のAPIを図示すると、下図のようになる。この図の見方は、楕円がインターフェイス、矩形がクラスである。矢印は拡張またはインターフェイスの実装を意味する。小さな楕円と矩形は外部のパッケージに属する。水色がJavax.servletパッケージに、黄色がjavax.servlet.httpパッケージに属する。

サーブレットのAPIの中心となるのが抽象インターフェイスであるServletである。アプリケーションは、これを実装したGenericServletをサブクラス化するか、HTTPベースのサーブレットであればHttpServletをサブクラス化させて各サービスに対応したクラスを作成する。