たとえば、新しいメールがユーザーの受信トレイに到達したときに表示される「gmail.com」を考えてみましょう。私が理解しているように、トリガーは、ユーザーの受信トレイ ページを更新するデータベース/Web サーバーから発生します。
更新せずに、またクライアント側から明示的な要求を行わずに、動的 Web ページを更新するコードを提案できますか [Gmail アカウント ページがサーブレットのようなテクノロジによって生成されると仮定します] (XHR がサーバーに要求を固定で送信することを考慮しないでください)間隔もクライアント側からのものになるため）。
XHRを含むAJAXコードで実装できますか?もしそうなら、どうやって実装できますか?
現在、これを行う通常の方法は、 Cometとしても知られる「ロングポーリング」を使用することだと思います。さまざまな具体的な手法がありますが、基本的な考え方は、ブラウザーがサーバーに要求を送信し、サーバーはブラウザーに送信するものがあるまで接続を開いたままにしておくというものです。たとえば、Gmail では、ブラウザー アプリがすぐに受信トレイにある次の新しいメッセージを要求する場合があります。サーバーは、新しいメッセージが実際に受信トレイに届くまでに 30 分かかるため、それを送信する前に 30 分待つ場合があります。
技術的には、これは依然としてクライアント主導ですが、クライアントの「要求」は、実際には、サーバーが選択した将来の時点でクライアントにデータを送信する機会をサーバーに提供するだけです。
ロング ポーリングを使用すると、ほとんどの場合、サーバーには多くの保留中のリクエストがアイドル状態になります。 サーブレット API のバージョン 3では「非同期サポート」が導入されました。これにより、スレッドは要求を保留にし、最初の要求が待機している間に他の要求を処理できます。古い API バージョン用に作成されたサーブレットは、それほどうまくスケーリングできません。service()メソッドは、応答が生成されるまで返されてはならず、応答するまで待機するだけのスレッドを結び付けなければならないからです。あるいは、Tomcat にはComet 用の特別な拡張機能があり、イベント駆動型 I/O を使用して、サーブレットが同じスレッドで同時に多くの要求を処理できるようにします。他のサーブレット コンテナが同様の拡張機能を提供する場合があります。
HTTP のオーバーヘッドなしで永続的な接続を介した双方向通信を可能にするWebSocketsと呼ばれる新しいプロトコルがありますが、まだ広くサポートされていません。
ajax または Web ソケットを使用して実行できます。
Ajax を使用すると、現在ほとんどの大企業が行っているロング ポーリングによってこれを実現できます。Web ソケットは未来ですが、サポートが不十分です。node.js 環境で実行している場合、socket.io はこの種のものに最適ですが、ruby と php 用のオプションもあります。
socket.io のようなツールの優れた点は、Web ソケットを使用できることです。Web ソケットは、使用できない場合は ajax ロング ポーリングに劣化するため、機能は損なわれません。
Comet を使用する場合、サーブレット api 3.0 の新しい非同期サーブレットも使用できます。Tomcatの comet 拡張機能は必要ありません。
これを行うには、現在考えられる4つの方法があります。
詳細については、サーブレット 3.0 および Spring MVC 3.2 での非同期サポートの紹介も記載されているこのブログ投稿を確認してください。