1

Java EE を使用した全二重ストリーミング ソリューションを探しています。

状況: クライアント アプリケーション (JavaFX) が周辺機器からデータを読み取ります。このデータは、処理のためにほぼリアルタイムでサーバーに転送され、処理のために新しいデータを送信し続けている間、非同期で応答を返す必要があります。

サーバーとの通信では、オーバーヘッドをできるだけ低くする必要があります。受信するデータは、基本的にセンサー データであり、処理後、一連のコマンドとして記述できるものに変換されます。

私が調べたこと：

  1. TCP/IP サーバー (これは非 Java EE アプローチです)。これは明らかな解決策です。各クライアント アプリから 2 つの接続が同時に開かれました。1 つはアップストリーム データ用で、もう 1 つはダウンストリーム データ用です。
  2. リモート & ステートレス EJB。これは、ストリーミングが含まれていないことを意味し、センサー データを小さなウィンドウ (1 ～ 2 秒相当のセンサー データ) にパックしてから、サーバーに送信して処理し、処理結果を応答として取得することを意味します。このアプローチでは、スケーラブルではありますが、1 ～ 2 秒ごとにリクエストを行う必要があることを考えると、どれくらい速くなるかわかりません。私はまだこれをテストする必要がありますが、疑問があります。
  3. RMI。これは、技術的に EJB と何か違いはありますか?
  4. ロング ポーリングの 2 つのサーブレット (アップ/ダウン)。私はこれを行ったことがないので、テストする必要があります。

とりあえず、アプローチ 2 のパフォーマンスをテストしたいと思います。最初の解決策は確実に機能しますが、別のサーバー (既に何かを実行している Tomcat の隣) を持つことはあまり好きではありません。

ただし、それまでの間、これを簡単に解決できる Java 固有の (EE であるかどうかに関係なく) テクノロジが他にあるかどうかを知っておく価値があります。誰かがアイデアを持っている場合は、それを共有してください。

4

3 に答える 3

2

これはJMSを使用するのに適した場所のようです。ステートレス EJB の代わりに、おそらくメッセージ駆動型 Beanを使用することになります。

これにより、TCP/IP 接続の代わりに 2 つのメッセージ キューを使用する、最初のソリューションと同様のアプローチが得られます。JMS は通信を完全に非同期にし、サーバーがどれだけ速くメッセージを消費できるかに関係なく、クライアントができる限り速くメッセージを送信できるという意味で、オーバーヘッドが低くなります。また、配信保証やその他の JMS の利点も得られます。

ただし、Tomcat には JMS が付属していません。TomEEを試すか、既存の Tomcat をActiveMQのような JMS 実装と統合することができます。

于 2013-02-20T06:49:45.880 に答える
1

あなたが試すことができる多くのオプションがあります。適切なソリューションは、アプリケーションの性質、通信プロトコル、データ転送の種類、クライアントとサーバーに対する制御、およびクライアント サーバー ルートに対するファイアウォールの制限によって異なります。

あなたの質問にはこれに関する多くの情報はありませんが、あなたが提供したものを考えると、 nettyは非常に汎用的で柔軟性があり、要件に合っているように見えるため、 nettyを見たいと思うかもしれません。Netty には、二重 websocket 実装も含まれています。netty ベースのソリューションは、他のソリューション (jms など) よりも実装が複雑で、背景調査が必要になる場合があることに注意してください。

私はまだ使用していませんが、GraniteDSで可能な別の解決策です。GraniteDS は、Flex/Flash でおなじみの Active Message Format を使用して comet (ロング ポーリング モデルの 2 つの非同期サーブレット) をデータに使用します。

于 2013-02-20T07:05:30.843 に答える
0

解決策として Websocket を見たことがありますか? それらは永続的な接続を維持することが知られているため、非同期応答は迅速になります。

于 2013-02-20T06:21:21.937 に答える