4

データがクライアントにすぐにプッシュされるイベントベースのサーバーが必要です。フォーラムで読んだように、websocket ベースのサーバーが私の最善の策です。それが機能していることと、製品ボックスでの使用がどれほど安定しているかを説明してください。

4

1 に答える 1

2

Web ソケットは非常に新しいため、多くのアプリケーション サーバーがまだ Web ソケットを十分にサポートしているとは思えません。たとえば、Tomcat は次のように述べています。「Tomcat は、RFC 6455 で定義されている WebSocket のサポートを提供します。この機能はまだ完成していないため、バグ レポートの形式でフィードバックを提供することをお勧めします。」ただし、アーキテクチャを少し異なる方法で見ると、Web ソケットの利点を利用できます。イベント ベースの株価の変更を送信 するサンプル アプリケーションは、次の論理的な手順で機能します。

1) クライアント アプリケーション (Web アプリまたは他の Web ソケット対応アプリ) は、要求されたリソース サービング サーバーとの Web ソケット接続を確立します。
2) サーバーは、外部 (バックエンド イベント) を受信し、対応するメッセージを受信するクライアントを選択する責任があります。
3) そのメッセージは、websocket 接続を介してクライアントに送信されます。標準で定義されている Websocket では、クライアントがオンラインである限りその接続を開いたままにする必要があり、そのデータをほぼリアルタイムで配信する必要があります。さらに、Web 経由で確実に配信できる標準化されたポート/プロトコルで実行できるという利点があります。

このことから、インフラストラクチャには実際に 4 つの論理部分があることがわかります。1) イベントを受け取るようにカスタマイズされたバックエンド。株価の場合、これは機関のバックエンドになります。2) イベントを対応するクライアントに論理的にリンクする役割を持つメッセージ ブローカ。3) クライアントへの Websocket 接続。4) クライアント自体

バックエンド:実際には、イベントに接続するために必要なものは何でも記述できます。株価情報システムの場合、これは金融サービス プロバイダーにリンクされたカスタム アプリケーションになります。

Message Broker については、 JMS または AMQP を使用して「イベント ベースのサービス」を処理することをお勧めします。これらのメッセージ ブローカーは明確に定義されており、多くのエンタープライズ アプリケーションで使用されています。ハードウェアの観点からは、バックエンドで直接実行することも、個別に実行することもできます。さらに、アプリケーションで利用したいさまざまなサービス (ポイントツーポイント、パブリッシュ、サブスクライブなど) を提供します。または、独自のカスタム メッセージング サービスを作成する場合は、Netty などを使用できます。

Websocket 接続には、メッセージ ブローカー システムに簡単かつ確実に接続できるサービスが必要です。たとえば、Kaazing (免責事項および完全開示私は Kaazing で働いています) は、メッセージ ブローカーに直接接続できるエンタープライズ AMQP エディションと JMS エディションの両方を提供します。

クライアントに関する問題:ブラウザーが Web ソケットをサポートしているかどうか、およびフォールバック メカニズム (ロング ポーリング、ajax) を含めます。これらは、WebSocket 接続を作成するために使用するサービスに大きく依存します。フォールバック メカニズムを提供するオープン ソース サービスは数多くありますが、Kaazing は、Websocket が置き換えるために作成されたフォールバック メカニズム (ロング ポーリング/ajax) ではなく、Websocket のように論理的に機能するエミュレートされた Websocket 接続も提供します。

安定性に関して: JMS と AMQP は広く使用されており、安定しています。すでに自社のテクノロジーを使用している業界ユーザーの印象的なリストがあります。

詳細については、この生きたWeb アーキテクチャのホワイト ペーパーをご覧ください。

于 2012-08-15T20:46:44.787 に答える