现有场景：两个应用程序正在使用队列进行通信。其中一个始终是生产者，另一个始终是消费者。
“生产者”生成数据并将其保存在自己的存储中。然后它使用队列将其发送给消费者。
我对 JMS 消费者（和侦听器）实现（使用 Spring）的了解越多，似乎我们可以轻松地将消息传递替换为轮询 Web 服务调用。
这是因为 JMS 监听器所做的只是保持线程打开，监听队列。因此，如果您的 JMS 侦听器 ConnectionFactory 设置为有 10 个连接，那么您将有 10 个阻塞线程。
因此，与其保持 10 个线程打开，不如使用 1 个线程每 30 秒左右轮询一次。一个 Poll 可以指示 WebService 在响应中向它发送 100 个数据项（或更多）。
答案是延迟。使用 JMS，消息在发送的同一秒就可供消费者使用。使用任何轮询解决方案，您总是会在平均轮询周期的一半左右遇到延迟。
这也会消耗更多的 CPU 和网络，因为轮询消费者必须每隔一秒唤醒一次并执行实际调用。
最后，您必须考虑重复和事务。通过正确设置 JMS，您可以保证收到完全正确的消息。
这两者都只是抽象。如果您考虑一下，它只是一个套接字，您正在推送数据。真正不同的是每个抽象所做的保证。太疯狂了，您实际上可以拥有通过 JMS 和使用 HTTP 作为传输的 JMS 提供服务的 SOAP Web 服务。
简而言之，JMS 指定了一组与消息传递（确认、重新传递、故障转移等）相关的保证。Web 服务（大多数人对它们的看法）主要由一组描述消息格式（SOAP、JSON）的规范组成，这些规范位于描述传输（HTTP）的规范之上。
关于投票。大多数 JMS 实现都是推送模型。订阅者向代理注册，并在消息到达时将它们推送给订阅者。推模型比拉模型具有更高的吞吐量。
那么这完全取决于您的要求。拥有基于 JMS 的通信有其自身的优势，例如：
当然，这一切都是有代价的，所以这一切都取决于你的需要。如果您的系统吞吐量较低，每分钟只有几条消息，并且可以忍受由于通信错误而丢失一些消息，那么您可以很好地切换到基于轮询的 Web 服务。
如果您想实现自己的排队服务，请随意。唯一的主要好处就是不必依赖第三个组件（JMS 服务器）。
如果您担心 10 个额外线程和 10 个额外套接字的资源，那么除了使用 JMS 服务器之外，您确实还有其他问题需要担心。这两个广告的增量成本都不重要。
如果您根本不需要排队，那么只需在线调用 Web 服务并完成它。
如果您自己实现它，那么您必须实现队列、持久性和恢复（当您的系统在第 29 秒出现故障并丢失 100 条未发送消息时）、事务恢复、重新连接逻辑等。
如果我必须为单个队列到单个目的地和单个生产者这样做，并且 JMS 服务器每年花费 X 千美元的许可费等，那么是的，我当然会考虑自己重做那一点逻辑。或者，如果我不想承担 JMS 服务器的内存压力。
但是 JMS 服务器是免费的，它们随我的应用程序服务器一起提供，配置了六次鼠标点击，并且它们“足够快”可以满足大多数需求。它们是当今无处不在的基础设施。
只是几率真的很高，恕我直言，重新发明这个轮子根本不值得。