IT-Walker on hatena

2006-11-22 Ajax+Javaアーキテクチャ構築記第五回

■

Cometd

さて、Cometの実装ということで大注目の技術、Cometdに関する解説も３回目を迎えました。

今日のメニューは

Cometdを使用した情報共有型サイトの作成方法
これまでのまとめ、リファレンス
Cometdの内部構造を簡単に解説

と言った感じで進めていきたいと思います。

Cometdを使用した情報共有型サイトの作成方法

前回は、Cometdを使用した情報配信型サイトの作成を行いました。

ポイントとしては

チャネル(Channel)の作成
Channel.publish(Object data, Client from)メソッドによるチャネルへのデータ配信
JavaScript 関数cometd.subscribe()によるチャネルの購読

でしたね。

この中でも重要だったのはChannel.publishによるチャネルへのデータ配信。

publishメソッドの第一引数にJavaのオブジェクトを渡すと、CometdがJSONデータに自動変換し、クライアントにPush配信してくれます。これが情報配信型アプリの作成方法。図にすると↓のような感じです。

では、チャットに代表されるような情報共有型サイト、つまり誰かがブラウザ上で行った変更がチャネルの購読者全てに配信されるようにするにはどうしたらよいのかというと、非常に簡単。

CometdのJavaScript APIを使用して、クライアントから直接チャネルにJSONデータを放り込んでやればよいです。図にすると↓。上の図と違うところは、配信データ作成とチャネルへのデータ配信がクライアント側に移動しているところです。

理屈がわかればあとは簡単。チャネルに配信するためのJavaScript API、cometd.publishさえ解説すれば終わりです。

/**
 * チャネルに対してデータ配信を行う
 * @param channel_ 配信対象のチャネル
 * @param data 配信データ
 * @param additionalMessage_ 追加で送信するメッセージ
 */
function publish(channel_,data,additionalMessage_)

チャネルを指定してデータを配信するというAPIになっていることに注目してください。もしチャネルがまだサーバサイドに存在していない場合、自動で作成されます。

情報共有型アプリの肝はこれだけですので、特にサンプルアプリケーションを作ったりはしません。cometd-demoのチャットアプリが非常によいサンプルなので、見てみてください。

しかし

cometd.publishを使用すると、チャネルへのデータ投稿から配信まで全てCometdが面倒を見てくれるので非常に楽チンなのですが、一つ欠点があります。

(あくまで現時点の実装では)全て自動で行われるため、途中で自前の処理をはさむことができないのです。(僕がやり方を知らないだけ？)

たとえば、チャットのログをファイルに残したい、なんて当たり前の要望を満たすことができません。将来的にはなんらかのフックが用意されるんじゃないかと思いますが、現時点では、cometd.publishを用いず別のサーブレットに自前の処理を行わせた後、情報配信型と同じく自分でChannel.publish()を呼び出すのが解決策かな。

僕が知らないだけかもしれません。誰か知ってたら教えてー

まとめとリファレンス

では、これまで学んだことをまとめてみましょう。

チャネルとは、Push配信の単位となる概念
同じチャネルを購読しているクライアント全てに対して同じデータがPush配信される
チャネルの購読は、JavaScript APIのsubscribe(channel,isGlobal,srcObj,funcName)で行う。funcNameで指定した関数がコールバックとして呼ばれる。
チャネルIDは任意で付ける事が出来るが、はスラッシュ("/")で始まる文字列で構成されることが推奨されている
チャネルへのデータ配信はChannel.publish(Object data, Client from)(サーバサイドAPI)か、cometd.publish(channel_,data,additionalMessage_)(JavaScript API)で行う
Cometdは、Bayeuxプロトコルという簡単な独自プロトコルを規定し、その枠組みに沿った通信を行うことによってPush配信を実現している

といったところです。

また、JavaScript APIを下にまとめておきます。これまで学んだものもあれば初出のものもありますが、まあわかるかと思います。(不明なところは、あとでわかったら埋めま～す)

関数名、シグネチャ	説明
init(message,root,additionalParameter)	Cometdの初期化を行う
publish(channel_,data,additionalMessage_)	チャネルへのデータ配信を行う
subscribe(channel,isGlobal,srcObj,funcName)	チャネルの購読を開始する
unsubscribe(channel_,isGlobal_,srcObj_,funcName)	チャネルの購読を終了する
deliver(array)	?(不明)
disconnect()	接続を切断する

Cometdの内部構造

ここからは、普通にCometdを使用している上では必要のない、Cometdの内部構造について僕の知っている限りでお話したいと思います。

とはいえ、やはりCometdは正式リリース版などまだまだ先にならないと望めないような全く枯れていないプロダクトですので、内部のことを理解してソースを追えるようになっておいたほうがトラブルシューティングも楽です。では、まずはCometdを構成するコンポーネントの説明を行います。

コンポーネント名	説明
CometdServlet	Cometdの中心をなすコントローラ
Bayeux	プロトコル。接続の確立、切断やチャネルへの配信、購読などの動作を規定している
Client	Cometdのクライアント。
Channel	チャネル。
Transport	サーバとクライアントの間の通信経路。XMLHttpRequest、IFrameなどが使用可能
JSON	Java オブジェクト→JSONデータへの変換を行う
DataFilter	レスポンスデータのフィルタリングを行う。スクリプトの無効化、サニタイジングなどに利用できる

上で示したコンポーネントがどう協調するかは以下の図を見てください。

Cometdは上の絵で示した動作を繰り返し行うことにより、Push配信を行っています。

繰り返しここが重要。

つまり、ちまたのComet簡易実装がよくやっているようなHTTP接続をつなぎっぱなしにするという実装とは違い、はっきり言ってポーリングを少し工夫したような実装になっています。

以下、絵の中の番号を振った部分の補足説明。

①リクエスト

CometdのJavaScript APIを使用すると、サーバとの通信が発生します。その際使用されるプロトコルがBayeux。通信経路はTransportというコンポーネントが担当します。

②リクエストに応じた処理

リクエストを受け付けたら、リクエストに含まれる文字列データからBayeuxプロトコルで規定された処理を実行します。Bayeuxプロトコルには接続の開始と終了、チャネルデータの購読などの動作が規定されています。

③チャネルにデータが来るか、タイムアウトまでウェイト

チャネルの購読をクライアントが要求してきた場合、チャネルに配信データが存在するかどうか確認します。あればそのデータをそのまま配信するのですが、ない場合はタイムアウトが発生するまでデータを待ち受けます。この「ウェイト」処理が非常に重要で、ポーリングの間隔を長く取ることにより、ネットワークトラフィックの負荷軽減に役立っています。

④JSONデータに変換

チャネルに配信されたJava オブジェクトから、JSON形式への変換を行います。ただ、Cometdが持つJSON コンバータは非常に機能が貧弱で、普通のJavaBean等を渡すとtoString()された文字列になってしまいます(笑)。このJava→JSONの変換は非常に重要な部分なので少し残念。とはいえ、JSON形式の文字列を自作して渡すなどの抜け道はいくらでもあります。

⑤フィルタリング

配信データのフィルタリングを行うことができます。フィルタはチャネルごとに設定できます。

サーブレットの初期化パラメータ"filters"で指定したJSONファイルに設定を記述します。

⑥レスポンス

レスポンスが実際にクライアントに返ります。Bayeuxプロトコルヘッダの付与などは全てCometdが面倒を見てくれるので気にする必要はありません。

というわけで、Cometdは一般的に認知されているPush配信の実現方法(HTTPレスポンスを切断しない)とは違い、「チャネルにデータが来たら即配信、それまではウェイト」という動作を繰り返すというアーキテクチャになっています。

このアーキテクチャは、「取得すべきデータがあるかないかに関わらず定期的にポーリング」というPull型のアーキテクチャに比べて非常に効率的です。

Continuation

ただし、一つ注意が必要なのは、リクエストを処理するスレッドを一時停止している時間帯があるということです。

ということはどういうことかというと、クライアント一人につきスレッドを占有する時間が非常に長くなる可能性があるということ。現在のWebアプリケーションサーバが大量のクライアントを同時に捌けるのは、コネクションの持続時間に比べて、リクエストの処理はほとんど時間がかからないという特性を生かしているからであって、もしクライアントごとにスレッドを一つ割り当てる必要が生じてしまうと、Webアプリケーションのスケーラビリティが損なわれてしまいます(とはいえ、HTTPレスポンスを延々切断しないというアーキテクチャよりはましか)。

Cometdの実装は、これに対しContinuationというAPIを使用することで対処しようとしています。

Continuationは、Jetty サーバで開発された「リクエストを処理するスレッドの一時停止&再利用」などを実現するためのAPIです。

これにより、CometdはJetty サーバ上で動作させる場合は非常に効率的に動作し、それ以外のサーバで動かす場合は昔ながらのwait¬ifyが使用されるようになっています。

Permalink | コメント(0) | トラックバック(0) | 21:03

トラックバック - http://d.hatena.ne.jp/Syunpei/20061122/1164197003

Jungle Java - Comet 関連情報メモ

リンク元