はじめに
Jetty 6には、継続（continuation）という機構が用意されました。この記事では、その応用例であるCometによるウェブアプリケーションの実装を取り上げ、解説をします。
Cometでは、サーバプッシュ型アプリケーションを実現するために、サーバに対してHTTPコネクションを張り続ける必要があります。こうした接続の手法は、従来のHTTPサーバでは想定されているものではありません。
また、Cometが提供するイベントドリブン型のウェブアプリケーションでは、サーバ側や、クライアントであるウェブブラウザー側での実装も複雑化します。そういった意味で、従来のウェブアプリケーション設計方法についても、見直しが進められていくことでしょう。
このような、Cometを契機とするウェブアプリケーション開発方法の変化に対応するにあたって、Jetty 6は有望な選択肢といえます。というのも、Jetty 6は単独で動作するHTTPサーバであり、継続の機構を利用することによって、比較的簡単にサーバプッシュ型ウェブアプリケーションを実装することができるからです。
long-pollと継続
実装にはいる前に、この記事の肝であるlong-pollと継続について、簡単に説明をします。
Jetty 6では、継続を利用してCometのlong-pollを実現します。ただ、継続といっても、call/ccのようなものではなく、ある時点で一時停止させた処理を簡単に再開させられる単純な仕組みにすぎません。ちょうど、デバッグのときに行ブレークポイントで処理を一時停止させ、そこから処理を再開させるような仕組みとして理解していただいてもかまいません。
図を見てください。通常のHTTPリクエストでは、クライアントからの要求に対して即時に結果を返します。Jetty 6の継続を利用すると、クライアントからの要求をうけたサーバ側の処理を一時停止（suspend）させ、――例えば、サーバ側の値を0から1にするイベントにをうけて――処理を再開（resume）させることができます。この間、クライアントは、コネクションを張りっぱなしの状態（砂時計がまわりっぱなしの状態）で、サーバからのレスポンスを待つことになります。
サーバからレスポンスが帰ってきた時点で、また同様の通信を行なうと、サーバとクライアント間で、あたかもコネクションが常時張られているかのような状態を実現することができます。これが、long-pollです。サーバ側アプリケーションは、リアルタイムでおこったイベントをクライアント側アプリケーションに通知することができます。
このような動作を時系列でまとめると次のようになります。
- クライアントがサーバに対してリクエストを行なう。
- サーバは、クライアントからのリクエストの処理を一時停止させる。
- サーバは、何らかのイベントによってリクエストの処理を再開させる。
- サーバからクライアントに対してレスポンスを返す。
- クライアントはレスポンスを受け、再度サーバへリクエストを送る。
後編その１へ続きます。