サーブレット3.0仕様書邦訳版

2010年5月

 

邦訳（ODF）のダウンロードはここから

PDF版のダウンロードはここから

サーブレット3.0とTomcat 7のチュートリアルはここから

 

このファイルはOpenOfficeのODTフォーマットであり、OpenOffice WriterまたはMicrosoft Office Word 2007以降で読むことができる。Internet Explorerでうまくダウンロード出来ないときは（ファイル拡張子が.zipとなったときは、これを元に戻す必要がある）、FirefoxやChromeなどのブラウザを使用をお勧めする。OpenOfficeはここからダウンロードできる。Writerを使うときは下図のようにナビゲータを左枠にはめ込むと、見たい章、節、図表を簡単に開くのにWordの見出しマップと同じ使い方ができる。

 

 

仕様書をアプリケーションの開発者が読むことはあまりないだろうが、問題が発生したりより高度な知識を得たい場合には、この邦訳版が寄与できよう。

 

なおこれまで当社のサイトにアップロードしていた2.2版の邦訳のODTファイルはここから、またPDFファイルはここからダウンロードできる。

 

 

サーブレット3.0について

 

サーブレット第3.0版仕様書が2009年12月に最終リリースされている。このバージョンはこれまでの2.2、2.3、2.4、2.5といったマイナー・バージョン部のアップデートから3.0とメージャー・バージョン部のアップデートへと大きく改版されている。Web2.0時代の強力なコンテナ技術という意味もあってかサーブレット3.0(Servlet 3.0)と一般的に呼ばれている。サーブレット3.0は仕様書の第15章でみられるように、Java EE 6プラットホームの要素でもあることを意識して開発されている。Java EE 6は2009年12月にリリースされている。サーブレット3.0対応のTomcatは7.0.ｘの予定だが、2010年下半期のリリースとされている。

 

オリジナルの仕様書とjavadoc等は以下のアドレスから取得できる：

http://jcp.org/aboutJava/communityprocess/final/jsr315/index.html

 

 

2.5版との比較

 

サーブレット3.0仕様書は2.5仕様書に比べて次のような追加等がなされている：

 

これらの変更箇所をざっと見れば、サーブレット3.0の大きなアップグレード要素は非同期処理による処理力向上、アノテーションの拡大よる開発の容易さ、及びフレームワーク親和性改善のためのプラグ可能性だということが分かる。

 

 

非同期処理(Asynchronous Processing)

 

第2.3.3.3節で説明しているように、クライアントからの要求で生成またはプールから取り出されたスレッドの数が、JDBC接続、リモートのウェブ・サービスからの応答、JMSメッセージ、あるいはチャットなどアプリケーションのあるイベント、などを待つことで増大し、VMのスタック・メモリ使用量が増大やスレッドの枯渇を起こすだけでなく、サーバ全体の処理能力を落とし、サービス品質(QoS)を劣化させてしまう。非同期処理ではそのスレッドを応答をクライアントに返すことなくコンテナに戻してしまい、そのイベントを取り扱っているスレッドが同じスレッド内で非同期処理を続ける、あるいはAsyncContext（非同期処理の実行コンテキスト）のAsyncContext.dispatchメソッドを使ってそのそのコンテナ内のあるリソースにその処理をディスパッチして処理を続ける。

 

非同期処理は、当該サーブレットまたはフィルタが@WebServletと@WebFilterアノテーションまたは配備記述子でasyncSupportedという属性がtrueにセットされており、req.startAsync(ServletRequest req, ServletResponse res)またはreq.startAsync()を呼んでAsyncContextオブジェクトを生成することで開始される。このメソッドの呼び出しにより当初のスレッドがServlet.service(request, response)を抜けても後述のcomplete()が呼ばれるまで応答がコミット（ネットワークへの送信）されないことが確保される。

 

非同期処理のスレッドはこのAsyncContextの多種のメソッド群を使って応答を生成する、あるいはAsyncContext.dispatchの3つのメソッドたちを使ってコンテナが管理する他のスレッドやJSPなどの指定されたリソースで処理をするようディスパッチする。AsyncContext.dispatchメソッドは開発者が用意した非同期ハンドラによって呼び出され、応答はコンテナのスレッド・プール、JSPやJSFなどのフレームワーク、あるいはJNDI、JTA、EJBなどによって書き込まれる。

 

非同期処理はAsyncContext.complete()が非同期ハンドラまたはコンテナによって呼ばれることで終了する。またその非同期処理が完了、エラー、またはタイム・アウトしたことの通知を受けるためのAsyncListnerというリスナが用意されている。

 

サーブレット3.0の仕様作成のリーダであるSun Microsystems（現在はOracleによって買収されている）の上級スタッフ技術者のRajiv Mordan氏の技術資料にある非同期処理のシンプルなアプリケーション例がその動作を理解するのに適している：

   @WebServlet("/foo" asyncSupported=true)

   public class MyServlet extends HttpServlet {

        public void doGet(HttpServletRequest req, HttpServletResponse res) {

            ...

            AsyncContext aCtx = request.startAsync(req, res);

            ScheduledThreadPoolExecutor executor = new ThreadPoolExecutor(10);

            executor.execute(new AsyncWebService(aCtx));

        }

   }

 

   public class AsyncWebService implements Runnable {

        AsyncContext ctx;

        public AsyncWebService(AsyncContext ctx) {

            this.ctx = ctx;

        }

        public void run() {

            // Invoke web service and save result in request attribute

            // Dispatch the request to render the result to a JSP.

            ctx.dispatch("/render.jsp");

   }

}

 

この例ではまず@WebServlet("/foo" asyncSupported=true)というアノテーションで"/foo"というURLパタンの呼び出しは非同期対応であることを宣言している。対応サーブレットはMyServletで、そのdoGetメソッドではaCtxという非同期コンテキストを生成し非同期動作を開始させている。次に非同期処理のスレッドexecutorを用意し、非同期ハンドラであるAsyncWebServiceをこのスレッドで実行させ、もとのスレッドはdoGetそしてServlet.serviceのメソッドを抜けてウェブ・サーバに戻る。非同期ハンドラであるAsyncWebServiceはRunnableインターフェイスを実装しており、runメソッドがそのスレッド処理である。この例ではまずウェブ・サービスを呼び出し、その結果を要求の属性としてストアし、次にdispatchメソッドで"/render.jsp"というJSPに応答への書き出しをさせている。このJSPを実行するのはコンテナであり、この場合はcompleteメソッドを呼ぶのはコンテナである。

 

 

開発の容易性(EoD : Ease of Development)

 

第8.1節に示されているように、サーブレット、フィルタ、リスナ、及びセキュリティ制約を指定するアノテーションが用意されており、web.xmlを使わなくてもアプリケーションの設定が可能になっている。web.xmlはこれらのアノテーションをオーバライドするのに使用できる。

 

 

 

プラグ可能性（Pluggability）

 

ウェブ・アプリケーションの多くはApacheのWicket、JSF(Java ServerFaces)、Strutsなどのフレームワークを使って開発されている。フレームワークを使用する際はweb.xmlの配備記述子に面倒な登録を必要としている。その為web.xmlが複雑で大きなものとなってしまう。サーブレット3.0ではweb.xmlをモジュール化して、フレームワークが自分たちのjarファイルの中にそれを含めることを可能にしている。またプログラム的な設定を可能とするServletContextのなかのAPI及びアノテーションも用意されている。

 

その為に8.2.1節に書かれているように、ウェブ・モジュール配備記述子フラグメント（ウェブ・フラグメント：フラグメントは片割れという意味）の概念が導入されている。ウェブ・フラグメントというのはライブラリまたはフレームワークjarのMETA-INFディレクトリのなかで指定されまた含められ得るweb.xmlの一部または総てのことである。コンテナは配備の際に定められた規則に従いこの設定を拾い上げ使用する。ただし、web.xml記述子のなかでmetadata-complete要素がtrueにセットされていれば、クラス・ファイルたちとjarにバンドルされたウェブ・フラグメントたちは処理されない。

 

web-fragment.xmlはライブラリまたはフレームワークのための記述子であり、META-INFディレクトリの中に含められ、その内容は<web-fragment>ではじまり</web-fragment>で終わること以外はweb.xmlと殆ど同じである。フラグメントは名前を有しており、<name>要素で識別される。WEB-INF/libディレクトリのなかのjarファイルのみがウェブ・フラグメントが含まれているとみなされる。

 

フレームワークとのリソースの共有のために、静的ドキュメントやJSPはこれまでのアプリケーションのドキュメント・ルートではなくて、WEB-INF/lib/[*.jar]/META-INF/resourcesディレクトリに置かれることになろう。コンテナはクライアントからの要求に対しこの新しい場所を調べ、またServletContext.getResource[AsStream]を受け付ける。これまでのアプリケーションのドキュメント・ルートに置かれているリソースはこれらのjarでバンドルされたリソースより優先される。

 

8.2.4節に示されているように、WEB-INF/libのなかにバンドルされているものたちをプラグ・インできることだけでなく、フレームワークたちの共有コピーたちをプラグ・インできるServletContainerInitializerという仕組みが用意されている。

 

 

その他

 

·4.4節に記されているように、サーブレット、フィルタ、及びそれらをマップするためのURLパタンをプログラム的（ダイナミック）に定義できるようになっている。これもプラグ化可能性の強化になる。例えばあるフレームワークがこのメソッドを使ってあるコントローラ・サーブレットを宣言できるようになる。

 

 

参考になるネット上のリソース：

 

http://weblogs.java.net/blog/mode/servlet3.0/servlet3.0-javaone09.pdf

http://www.jteam.nl/specials/techtalks/0116/attachment/Servlet3.pdf

http://www.infoq.com/presentations/Apache-Tomcat-7