3

Java EE コンテナー内で JMS を使用して同期要求応答パターンを実装しようとしています。シーケンスは次のようになります

  1. ブラウザーが Web アプリケーションにデータを要求します。これはブロッキング リクエストです (スレッド T1 など)。
  2. 上記の要求を満たすには、Web アプリがリモート Web サービスに接続する必要があります。したがって、リクエストを形成し、それをキューに入れます (reply-to キューも宣言されています)。
  3. リモート サービスは要求を処理し、手順 2 で宣言された応答先キューに応答を配置します。
  4. 応答は Web アプリの応答先 Q から読み取られ、ステップ 1 のブロッキング スレッド T1 で使用できるようになります。

T.Rob が提供する回答に従いました ( MQ サーバーの応答メッセージを正しい要求に一致させる方法) 。

QueueReceiver queueReceiver = 
  session.createReceiver(destination, "JMSCorrelationID='customMessageId'");
TextMessage receivedMessage = (TextMessage)queueReceiver.receive( 15000 );

上記のソリューションは、複数の同時リクエストが入ってくる可能性のある Java EE コンテナー (Web モジュール) で実行する場合に有効ですか?

4

2 に答える 2

2

これは「有効」の認識に依存します。おそらくコンパイルして動作します。しかし、デザインの観点からは、本当に改善できると言えます。

スレッドがブロックしている場合、非同期通信は何の価値も追加しません。代わりに、速度が低下し、リソースを消費し、問題が発生する可能性さえあります (以下のリンクを参照)。

メッセージを処理するシステム (おそらく MDB) によって公開されるサービスが何であれ、それを別のサービス クラスに抽出し、ステートレス セッション Bean の形で別のフロントエンドを提供します。したがって、サービスは同期インターフェースと非同期インターフェースの両方で公開され、クライアントは選択できます。

あなたのシナリオでは、サーブレットは EJB を同期的に呼び出すだけです。

そうしないと発生する可能性がある問題については、トランザクション環境での JMS 要求/応答パターンを参照してください(このアプローチでは一時キューを使用します)。

単一のキュー (質問で引用した方法) を使用すると、関連するメッセージを取得するためのセレクター (条件) が必要になります。これは、キューのボリュームによっては遅くなる可能性があります。

一方、( を使用して)非同期サポートも備えたサーブレットを@WebServlet(asyncSupported = true)実装する場合は、何かが異なります。その場合、それは有効なアプローチだと思います。

そのシナリオでは、キューをリッスンしている1 つのバックグラウンド スレッドが複数のクライアントにサービスを提供できるため、リソース (つまり、スレッド。ただし、HTTP 接続は開いたまま) を節約できます。パフォーマンスまたはリソースの問題がある場合は、これを考慮してください。それまでは、実装が簡単な同期方法をお勧めします。

于 2013-08-31T13:47:14.630 に答える