Java EE容器中的同步请求-应答模式 [英] Synchronous request-reply pattern in a Java EE container

问题描述

我正在寻找使用Java EE容器内的JMS实现同步请求-答复模式的方法.序列会是这样的

I am looking to implement an synchronous request-reply pattern using JMS inside a Java EE container. The sequence would be something like this

1. 浏览器向Web应用程序发出数据请求.这是一个阻塞请求(例如在线程T1上).
2. 该网络应用需要连接到远程网络服务才能满足上述要求.因此，它形成一个请求并将其放置在队列中(还声明了答复队列).
3. 远程服务处理请求并将响应放入步骤2中声明的回复队列
4. 在Web应用程序中从对Q的答复中读取响应，并将其提供给步骤1的阻止线程T1.

我遵循了T.Rob(

I have followed the answer provided by T.Rob (How to match MQ Server reply messages to the correct request)

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

以上解决方案在Java EE容器(Web模块)中运行时是否有效，其中可能会有多个并发请求进入?

Is the above solution valid when running in a Java EE container (web module) where there could be multiple concurrent requests coming in?

推荐答案

这取决于对有效"的理解:它可能会编译并起作用.但是从设计的角度来看，可以说您确实可以改进它.

This depends on the perception of "valid": It will probably compile and work. But from the design perspective, one could say that you can really improve it.

如果您的线程正在阻塞，则任何异步通信都不会增加任何价值.相反，它将使速度变慢，将消耗资源，甚至可能会造成麻烦(请参见下面的链接).

If your thread is blocking, any asynchronous communication won't add any value. Instead it will make it slow, it will consume resources, and it might even create trouble (see link below).

系统处理消息时公开的任何服务(可能是MDB)，将其提取到单独的服务类中，并以无状态会话bean的形式提供另一个前端.因此，您的服务同时通过同步和异步界面公开，客户端可以选择.

Whatever service is exposed by the the system processing the messages (possibly an MDB), extract it into a separate service class, and provide another frontend in the shape of a stateless session bean. So your service is exposed both by an sync and async interface, and the client can choose.

在您的方案中，您的servlet只是同步调用EJB.

In your scenario your servlet just calls an EJB synchronously.

关于可能发生的其他问题:请查看交易环境中的JMS请求/响应模式(本方法使用一个临时队列.

As for the problems which may happen otherwise: Have a look at JMS request/response pattern in transactional environment (this approach uses a temporary queue).

使用单个队列(问题中引用的方式)，您需要一个选择器(条件)来获取相关消息:可能的速度很慢，具体取决于队列中的音量

Using a single queue (the way you have quoted in your question), you need a selector (the condition) to get relevant messages: This might be slow, depending on the volume in the queue.

另一方面，如果您还通过异步支持实现了 servlet (使用@WebServlet(asyncSupported = true))，则有所不同.在那种情况下，我会说这是一种有效的方法.

On the other hand, if you implement your servlet with asynchronous support as well (using @WebServlet(asyncSupported = true)), it's something different. In that case I would say it's a valid approach.

在这种情况下，您可以节省资源(即线程；但是HTTP连接保持打开状态)，因为一个后台线程在队列中侦听可以为多个客户端提供服务.如果您有性能或资源问题，请考虑此问题.在此之前，我建议使用同步方式，因为它更易于实现.

In that scenario you can save resources (namely threads; but the HTTP connections remain open), because one background thread listening on a queue can serve multiple clients. Consider this if you have performance or resource problems. Until then I suggest the synchronous way, because it is easier to implement.

这篇关于Java EE容器中的同步请求-应答模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！