我正在使用SOA风格实现的实时应用程序（通过一些消息传递协议（JMS，MQ或HTTP）连接读取松散耦合的组件）。实时SOA应用程序的最佳消息传递媒介？
设计此系统的架构师选择使用JMS来连接组件。这个系统是实时的，因此如果一个组件发生故障，交易将不再需要排队。此外，没有必要保证交付或回滚。
在这种情况下，使用JMS而不是HTTP Web服务（速度，资源占用等）有什么好处？
我在想的一件事是，由于JMS方法要求我们设置线程池大小（侦听JMS主题/队列的组件数量），因此不会更好地适应HTTP服务不需要额外的配置（为每个HTTP请求创建一个新线程，使应用程序可以扩展到“无限”数量的请求，直到服务器资源耗尽）。
我错过了什么吗？
我不与美国洛特提出在所有的点不同意，但这里有几点需要考虑关于HTTP web服务：
你的客户端只需要知道如何沟通通过HTTP协议 - 几乎每种现代语言都支持这种协议。 JMS虽然很流行，但比HTTP更专业，因此限制了互联系统可以使用的语言。目前对于您的系统来说可能不是问题，但是您以后需要插入其他可能难以支持JMS连接的系统吗？
您可以为您的服务提供的WSDL和SOAP等标准很好的支持许多语言，并且有很多工具可以生成代码以实现管道的两端（客户端和服务器） WSDL文件，减少你必须做的dev的数量。这些标准还使得定义和发布您将在系统之间传递的数据规范变得相对简单，您可能必须亲自使用像JMS这样的排队技术来完成这些规定。正如S.Lott指出的那样，JMS为您提供了使用（无状态）HTTP协议丢弃的功能：保证排序&可靠性;监测;可扩展性;等等。你确定你不需要这些，并且不需要这些前进吗？
伟大的问题，顺便说一句。
我对您的要求不够了解，但您可能忽略了可管理性，灵活性和性能。
JMS允许您监视和管理队列。这些是HTTP缺乏的功能，你必须建立而不是从供应商处购买。
另外，JMS中有一些队列和主题，允许多个订户到单个发布者。在HTTP中不可能。
虽然在版本1.0中可能不需要这些东西，但您可能会在将来想要它们。另外，JMS可以使用其他传输机制，如命名套接字，这样可以减少开销（如果没有所有套接字协商正在进行（几乎）每个请求。
如果你停下HTTP路由，并且你想支持多台机器或某种可靠性 - 你将需要一个能够发现可用Web服务器并在它们之间加载请求的负载平衡器 - 然后故障转移到另一个网络服务器，如果一个特定的盒/过程死亡。进行HTTP请求的客户也将不得不处理服务器失败并在某个循环中重试操作。
这是消息队列的主要特性之一 - 可靠的负载均衡，故障转移和生产者与消费者之间的松散耦合，而不必包含重试逻辑 - 因此您的客户端或服务器代码不必担心这种事情。这与你是否想要消息持久化或想使用ACID事务来产生/使用消息（这可能非常方便）是完全分离的。
如果您只关注使用Java的服务器端 - 无论是Servlets还是MessageListener/MDB，它们实际上都有点类似。区别在于负载平衡器。
所以也许这个问题应该是真的 - 与设置您的DNS/NAT/IP/HTTP负载平衡器基础设施相比，JMS代理更容易设置&吗？
我认为这确实取决于情况。在我工作的地方，我们支持Remoting，JMS，MQ，HTTP和sFTP。我们正在实施一种可以说Remoting，JMS，MQ和HTTP的中间件设备，以及一种说JMS，MQ和HTTP的软件中间件组件。
正如上面提到的，标准帮助我们变得灵活，但专有格式允许更多功能。
简而言之，我会说使用HTTP进行无状态调用（最终可以满足几乎所有的需求），以及您需要进行有状态调用的任何专有格式。如果您在大型企业工作，硬件设备通常非常适合作为中间件：闪电般的快速压缩，加密，转换和转换，总体拥有成本非常低。
我想这取决于你的意思是实时的......我认为JMS和HTTP都不能很好地支持“实时”应用程序，这意味着它们不能提供可预测的/确定性的性能，也不能正确地确定流中的流的优先级的争夺。
部分原因是这些技术是建立在TCP之上的，它将所有流量串行化为单个FIFO，这意味着不能轻易优先考虑不同的流量。此外，TCP定时器不易控制，从而导致不可预知的阻塞和超时...因此，许多流式应用程序使用UDP而不是TCP作为底层协议。
JMS的另一个问题是典型的实现使用集中化消息分发的代理。这不是获得确定性性能的最佳体系结构。
如果您正在寻找一种中间件，它可以为您提供可靠的保证以及您使用JMS获得的发布 - 订阅语义，但是为了适应实时应用程序领域而开发，我建议您查看一下OMG数据分发服务（DDS）。请参阅dds.omg.org和我写的这篇文章，论证为什么DDS是实现实时SOA的最佳中间件。 http://soa.sys-con.com/node/467488