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