JMS は、いくつかの機能でこれをサポートしています。
まず、JMSCorrelationId は、要求と応答を関連付けるために使用される JMS ヘッダーです。つまり、各メッセージには、グローバルに一意の (GUID) JMSMessageId が含まれています。メインフレーム アプリは、メッセージ ID を要求から応答メッセージの JMSCorrelationId に単純にコピーし、共有応答キューに送り返す必要があります。
したがって、次の方法でリクエストを送信するだけです。
(psuedo code - in one thread, do the following when you need to request data over JMS)
myMessage = session.createTextMessage("My nice request");
messageProducer.send(myMessage); // using some previously setup producer
// commit if needed
mc = session.createConsumer(queue,"JMSCorrelationId='"+myMessage.getMessageId()+"'");
responseMessage = mc.receive(TIMEOUT);
if( responseMessage != null){
//got OUR response data
}
// close down consumer here.
複数のコンシューマー スレッド (またはアプリケーション) を許可する秘訣は、コンシューマーのセレクターです。JMS セレクターは、SQL または同様のクエリ言語のサブセットに似ています。この場合、JMSCorrelationId がリクエストの ID と同じであるメッセージを選択するだけで、しばらくしてから送信されます。
これは、固定の共有キューが 1 つあり、要求が要求されたのとまったく同じスレッドに返される必要があるという制約で実行できる唯一の「安全な」セットアップです。
JMS セレクターのオーバーヘッドを回避するために、応答に一時キューを使用することもできます。リクエストごとに 1 つの一時キューを使用すると、特定の応答をリッスンする他のスレッドがなくなります。パフォーマンスを向上させるもう 1 つのオプションは、アプリケーションをより非同期にすることです。JMS は実際にこれを促進し、リクエストを起動し、コンシューマー スレッドのプールが非同期応答を処理できるようにします。各スレッドは、データを処理してデータベース (または同様のもの) に格納する際に、すべての応答を同等に処理できます。この設計パラダイムがあなたのケースに当てはまるかどうかはわかりませんが、少なくとも知っておく必要があります。