サーブレットの概要

サーブレットの概要

在席状態を通知するプログラムを作成する場合、Cometでの双方向通信は、jettyが提供するContinuationオブジェクトが実体となります。これは、org.eclipse.jetty.continuationライブラリが提供しており、org.eclipse.jetty.io.nioライブラリによってブロックが行われないリクエストを生成することができます。ブロックが行われないリクエストはサスペンド状態にすることが可能で、いずれかの社員の在席状態が変わったというイベントが発生するとコールバック処理で、リクエストの続き（レスポンスを返す処理）が実行できます。

このレスポンスを返す処理は、接続している全社員に対して行われるように、サスペンド状態にする際にユーザーリストに追加していきます。処理の流れとしては、アプリケーションの開始で、Continuationオブジェクトを、HttpServletRequestを使って作成します。

［リスト 02］jettyでCometを行う場合の一般的なサーブレットコード（Continuationオブジェクトの生成）

初期表示では、Continuationオブジェクトがペンディングの場合（処理中の場合）でなければ、レジューム（サスペンド状態）でサーバーの応答を待っていますから、サーバーの全社員の在席状態を返答します。

［リスト 03］jettyでCometを行う場合の一般的なサーブレットコード（レスポンスを返す）

Continuationオブジェクトの状態がペンディングの場合（処理中の場合）は、レジューム（サスペンド状態）にセットし、次のイベント（いずれかの社員の在席状態が変わるの）を待ちます。

［リスト 04］jettyでCometを行う場合の一般的なサーブレットコード（レジューム状態へ移行）

コードについては、英文ですが以下が参考になります。
　→参照リンク：Eclipse Jetty/Feature/Continuations

まとめ

このように、サーバー側で双方向通信の多くの部分を制御するのがAjax+Cometアプリケーションの特徴です。そのため、Ajax+Cometアプリケーションの構築は、サーバーによって実装方法も構築手順も異なります。その分、クライアント側については、標準のAjax技術だけで作成できるので、コンテンツのインターフェースに注力できます。

なお、いずれのWebサーバーを選択した場合も、Cometを構築する時に共通して注意が必要なのは、各リクエストの、アイドル状態の時間の設定（タイムアウトの設定）が重要になることです。タイムアウトでレスポンス待ちのリクエストを破棄すると、クライアントは次回の通知受取のためのリクエストをサーバーに発行するようにしなければいけません。つまり、この時間が短いということは、単にAjaxによる定期的なポーリングと何ら変わりない状態になることに注意してください。通信が張りっ放しになるコストよりも、リクエストを開始するコストが大きいため、Ajaxによる定期的なポーリングは多くのリソースを消費します。

この問題を解決するのも双方向通信の大きな役割ですので、Ajax+Cometでの双方向通信実装の際は、タイムアウトの時間設定とシステムを使う全員のボリューム（社員数など）をうまく設計してください。