組み込みデバイス上に完全に機能するジャージー/レストアプリケーションサーバーがあり、ファイアウォールを介して利用できるようにするために、それを大気ジャージーを使用して websocket に変換中です。いくつかの設計上の質問に出くわしました。
約 125 の異なるレスト コール エンドポイントがあります。それらのいくつかに Websocket をセットアップし、残りの場合と同様にデータを前後に転送しましたが、ライブ プッシュを使用しました。各エンドポイントのサブスクライバーでソケットを構築したので、接続エンドポイントごとにブラウザー側で実際に websocket を維持しているということですか? それとも、ブラウザは、同じドメインに対して単一のソケットを開いたままにして、各エンドポイントに要求をやり取りできるほどスマートですか? 多くの Websocket を維持している場合、単一の Websocket を使用して、複数のエンドポイントとのすべての通信を行う特定の戦略はありますか?
同様に、私のプロジェクトでは、登録されたソケット リスナーのデバイスへのログインを照合するための仲介サービスが必要になります。ログインを websocket ブローカーに一致させるためのコンテナーはありますか?それは、自分の Web サービスでホストできます (無料である必要があります)。私のバックエンド サービスはすべて残りのように見えるので、各エンドポイントを仲介者にサブスクライブする必要はありません。トラフィックを処理してエンドポイントにプッシュするために単一の Websocket ブローカーをセットアップする必要があるのか 、それとも jersey-atmosphere サービスがこれを処理するのに十分スマートなのか疑問に思っていますか?
編集：設計上の質問を追加しました：単一のWebSocketインターフェースを使用してWebブラウザーとバックエンドサーバー間で通信するため。受信ブローカーごとに POJO を生成するクリーンで簡単な方法はありますか? または、オブジェクトを受信する各クラスの最初のステップとして JSON 変換を行う必要がありますか? ブローカを決定する何らかのキーを使用して JavaScript メッセージを作成すると、キーをクラスにマップし、オブジェクトをハンドラーに戻すために pojo 生成を実行できます。 .