JMS——常见用途
JMS 和消息驱动 Bean 有哪些常见且有用的用途？
What is common and useful uses of JMS and Message Driven Beans?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
JMS 和消息驱动 Bean 有哪些常见且有用的用途？
What is common and useful uses of JMS and Message Driven Beans?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（2）
异步通信：调用者快速返回，可以继续其工作（无需创建新线程）并且可以稍后处理消息。消息可以被存储，即使服务器出现故障，一旦服务器再次启动，消息也可以继续被处理。消息可以分发到多台机器（可选地基于规则）。
调用者和被调用者可以解耦（调用者不必知道，谁将消费该消息，以及有多少个消息消费者）。
与同步通信相比，它具有巨大的性能优势。这样的消息中间件对于每秒必须处理大量消息的服务至关重要（例如 Twitter）。但它并不限于人类可读的消息。
Asynchronous communication: The caller returns quickly, and can continue its work (without creating a new thread) and the message can be processed later. Messages can be stored, and even when the server fails, they can continue to be processed, once the server starts up again. Messages can be distributed to multiple machines (optionally based on rules).
Callers and callees can be decoupled (the caller doesn't have to know, who will consume the message, and how many message consumers there are).
It can have enormous performance advantages compared to synchronous communication. Such a messaging middleware can be crucial for services that have to handle lots of messages per second (think of Twitter for example). But it's not restricted to human readable messages.
选择 JMS 和 MDB 的另一个原因是保证交付。如果接收者不可用，同步点对点调用就会失败，但是可以设置队列来保证传递、处理重试或事务失败、对“有毒”消息使用错误队列等。
构建了两种传输模型JMS：使用队列进行点对点并使用主题进行发布/订阅。每个都有自己的优点。
JMS 和 MDB 的缺点是响应速度。您可能喜欢这种解耦，但如果您阻止并等待响应，它肯定会比直接远程方法调用慢，因为涉及两次网络旅行而不是一次。
Another reason to choose JMS and MDBs is guaranteed delivery. A synchronous, point to point call fails if the receiver is unavailable, but a queue can be set up to guarantee delivery, handle retries or transactional failures, use error queues for messages that are "poison", etc.
There are two transmission models built into JMS: point-to-point using queues and publish/subscribe using topics. Each has its own advantages.
The downside of JMS and MDBs is speed of response. You might like the decoupling, but if you block and wait for a response it'll certainly be slower than a direct remote method invocation, because there are two network trips involved instead of just one.