0

Java で描画アプリケーションを作成する必要があります。このアプリケーションでは、ユーザーがマスター アプリケーションで特に線や色を描画し、多数のクライアント ビューアーがそれに応じてビューを更新します。各クライアント ビューアーは、受信したデータを異なる方法で視覚化する場合があります (たとえば、マスター アプリケーションで描画された線が与えられた場合、ビューアー 1 は同じことを行い、ビューアー 2 はフィルタリングを適用して違いを示す場合があります)。

Java Messaging Service アプローチは、そのようなアプリケーションに適していますか? マスター アプリは変更をメッセージで送信し、クライアントはビューを非同期的に更新します。後で、送信されたデータのタイプを区別する必要があるかもしれないので、クライアントごとに異なるトピックを設定するために CAMEL を検討していました。これらが適切な選択ではない場合、適切なテクノロジは何ですか?

後で設計が変更され、すべてのクライアントも更新を送信し、それに応じて更新する必要がある場合、それらはまだ良い選択ですか?

マスター アプリケーションの更新レート/量が膨大な場合、このアプローチはスケールアウトしますか? (たとえば、1024x768 ピクセル以上で 60 フレーム/秒の更新。 - おそらく、フレームの差分を計算して、変更のみを送信できます。)

お時間をいただきありがとうございます。多くの質問をして申し訳ありません。私の仮定が間違っている場合もお知らせください。

4

1 に答える 1

0

実行可能ではありますが、JMS と Camel がこのタイプの分散アプリケーションに最適であるとは思えません。

JMS/Camel は、サービスとコンシューマーの間である程度の分離が必要なエンタープライズ統合シナリオに適しています。デカップリングには通常、メンテナンスとパフォーマンスのオーバーヘッドが伴います。

あなたが説明したアプリのタイプでは、私たちを分離することは重要ではないように聞こえるので、クライアントとサーバーが同じ言語で実装され、それらの間で rpc 呼び出しがある分散アプリケーション環境を見たほうがよいかもしれません。

言語の選択に応じて、分散 Java、分散 Ruby、Celluloid、HTML5+Websockets (たとえば、meteor.com をチェックしてください) などの分散テクノロジを検討できます。

于 2012-04-19T07:32:02.543 に答える