「Comet」がこれらのテクノロジーの用語であることは事実ですが、バイユープロトコルはいくつかの実装でのみ使用されています。コメットテクニックは、必要なプロトコルを使用できます。バイユーはその1つです。
そうは言っても、非同期サーブレットソリューションとComet+Bayeuxソリューションの間には2つの主な違いがあります。
最初の違いは、Comet + Bayeuxソリューションは、Bayeuxを転送するプロトコルから独立していることです。CometDプロジェクトには、バイユーを運ぶことができるクライアントとサーバーの両方にプラグ可能なトランスポートがあります。バイユーがPOSTリクエストのコンテンツであるHTTPを使用して運ぶことができますが、バイユーがWebSocketメッセージのペイロードであるWebSocketを使用して運ぶこともできます。非同期サーブレットを使用する場合、HTTPよりもはるかに効率的なWebSocketを利用することはできません。
2つ目の違いは、非同期サーブレットはHTTPのみを伝送し、リモートのCometクライアントを処理するにはそれ以上のものが必要になることです。
たとえば、同じページの2つのタブが2つの異なるクライアントになるように、クライアントを一意に識別したい場合があります。これを行うには、非同期サーブレットリクエストに「プロパティ」を追加する必要があります。それを呼び出しましょうsessionId
。
次に、クライアントを認証できるようにします。認証されたクライアントのみがを取得できますsessionId
。ただし、認証する最初のリクエストと、すでに認証されている他の後続のリクエストを区別するには、別のプロパティが必要ですmessageType
。
次に、ネットワークの損失やその他の接続の問題による切断をすばやく通知できるようにする必要があります。したがって、ハートビートソリューションを考え出す必要があります。これにより、ハートビートが発生した場合は接続が有効であり、ビートが発生しなかった場合は接続が停止していることがわかり、レスキューアクションを実行できます。
次に、切断機能が必要です。等々。
HTTPの上に別のプロトコルを構築していることにすぐに気付きます。
その時点で、Bayeuxのような既存のプロトコルと、CometD(Bayeuxプロトコルを使用するCometテクニックに基づく)のような実績のあるソリューションを再利用することをお勧めします。
- シンプルでありながら強力なAPIを備えたJavaおよびJavaScriptクライアントライブラリ
- 注釈付きサービスを介してHTTPやWebSocketなどの低レベルの詳細を処理する必要なしにアプリケーションロジックを実行するJavaサーバーライブラリ
- クライアントとサーバーの両方のトランスポートプラグ可能性
- Bayeuxプロトコルの拡張性
- 怠惰なメッセージ
- クラスタリング
- 最高のパフォーマンス
- 将来の保証:WebSocketが登場する前のCometDのユーザーは、WebSocketを利用するためにコード行を変更しませんでした-すべての魔法はライブラリに実装されました
- 標準に基づく
- Webプロトコルの専門家によって設計および保守されています
- 拡張ドキュメント
- 続けることはできますが、要点はわかります:)
HTTPのみに結び付ける低レベルのソリューションは使用したくありません。使用するComet手法と、Bayeuxを転送するプロトコルからアプリケーションを抽象化する高レベルのソリューションを使用して、アプリケーションを一度作成し、将来のテクノロジーの改善を活用できるようにします。テクノロジーの改善の例として、CometDは非同期サーブレットが登場する前はうまく機能していましたが、非同期サーブレットを使用するとスケーラブルになり、アプリケーションの1行を変更する必要がなくなりました。
より高いレベルのソリューションを使用することで、非同期サーブレットを正しく作成する方法の厄介な詳細ではなく、アプリケーションに集中できます(そして、思ったほど簡単ではありません)。
あなたの質問への答えは次のようになります:巨人の肩の上に立ちたいので、Comet+Bayeuxを使用します。