まとめ

［リスト 05］サーバーとのコネクション終了時

クライアントのWebSockets APIインターフェースは非常にシンプルです（W3C - 『The Web Sockets API』日本語訳：http://www.html5.jp/trans/w3c_websockets.html）。そのため、在席状態の変更時にコネクションの状態を見て、再接続するといったことはできません。コネクションが閉じている場合は、WebSocketオブジェクトを一度破棄して、再生成、送信といった初期表示時の動作を行う等の対処を講じてください。

サーバー側コードも非常にシンプルです。基本的にonConnectイベント時の処理、onMessageイベント時の処理、onDisconnectイベント時の処理を作成するだけです。

［リスト 06］サーバーとのコネクション終了時

doWebSocketConnectは、WebSocketServletが提供するメソッドで、クライアントからの新たな接続が発生すると、サーバー側のWebSocketのインスタンスに対してonConnect等のイベントとwsパイプライン（筆者はWebSocketsのサーバー、クライアント間に維持され、複数のメッセージ交換に流用されるコネクションをそう呼んでます）を関係づける機能を持ちます。

onConnectイベント発生時には接続ユーザーをリストに格納しています。この部分は、Javaの提供するCopyOnWriteArraySetコレクションを使います。

［リスト 07］サーバーとのコネクション終了時

社員の在席状態を変更する時は、ユーザーリストの社員すべてにその状態を通知します。

この例のように、クライアント側に状態を蓄積していくような構造にする場合は、クライアント側で表示結果と受け取った新しい情報をマージするプログラムも必要になると思います。

WCF+Silverlightで、サーバー側での結果のマージを紹介しましたので、ここではクライアント側に逐次追加情報が送られてくる例を紹介しました。株価チャートやチャットプログラムなど、リアルタイムWebの双方向通信では、こちらのケースが多いかもしれません。

イベント駆動型プログラミングモデルでは、プログラムの構造についてはほとんど変わり無く、イベントハンドル内のサービス内容が変わるという点が重要です。

コードの構造については、英文ですが以下が参考になります。
　→参照リンク：Eclips Jetty WebSocket Server

まとめ

WebSocketsの場合、jettyを使うことでjettyが提供するWebSocketクラスがさまざまなイベントを提供してくれます。その結果、Ajax+Cometの際のタイムアウトの設定によるスレッドのスリープといった制御が必要なくなります。

お気づきの方もいると思いますが、コード的にはAjax+CometよりもWCF+Silverlightに近いと考えられます。これは、WCFサービスを使ったエンドポイント共有（PollingDuplexHttpBinding）もjettyが提供するWebSocketクラスもイベント駆動型プログラミングモデルだからです。

Ajax+Cometの場合、特定のWebサーバーに依存してしまうことを解説しましたが、将来的にServlet3.0ではイベント駆動型プログラミングモデルによるComet提供も考えられるため、JavaでサーバーをComet化するというスタイルの場合、移植性が高まることは十分考えられます。

双方向通信の実装は、イベント駆動型プログラミングモデルが主流になっていくのではないでしょうか。