JMS vs Webservices
JMS优于Webservices有什么大的优势，反之亦然？
（Web服务是否膨胀？JMS总体上更好地提供接口吗？）
从erickson校正后编辑：
JMS要求您具有JMS提供程序，实现MessageListener接口以处理消息的Java类，以及知道如何连接到JMS队列的客户机。 JMS表示异步处理 – 客户端发送消息而不一定等待响应。 JMS可以以点对点队列方式或发布/订阅使用。
“服务”是一个流动的术语。 我认为服务是一个存在于网络上的组件，并宣传合同：“如果你发给我X，我会为你执行这个任务并返回Y.”
分布式组件已经存在很长时间了。 每个人使用不同的协议（例如，COM，Corba，RMI等）进行通信，并以不同的方式公开他们的合同。
Web服务是分布式服务的最新趋势。 他们使用HTTP作为协议，可以与任何可以通过TCP / IP连接并发出HTTP请求的客户端进行互操作。
您可以使用SOAP或RPC-XML或REST或“收缩优先”样式，但仍然使用HTTP作为其协议的分布式组件的基本思想。
如果您接受所有这些，Web服务通常是同步调用。 它们不需要臃肿，但你可以用任何风格或语言编写坏组件。
您可以通过首先设计请求和响应来开始设计任何分布式组件。 鉴于这些，您可以根据您希望拥有的客户端类型以及通信是同步还是异步来选择JMS或Web服务。
基于消息的系统（包括JMS）提供了与另一端“按时间顺序解耦”的能力。 可以在没有另一端可用的情况下发送消息。
所有其他常见的A2A方法要求合作伙伴能够立即响应，要求他们能够处理峰值负载，几乎没有扩散处理的能力。
我说最大的区别是JMS是面向消息的，而不是面向RPC的。 开箱即用，大多数JMS提供程序支持执行重试，防止重复和支持事务的高级协议。
有许多应用程序不需要这些function。 但是在需要它们的地方，在RPC机制之上自己构建它们是复杂，昂贵且容易出错的。
让我来谈谈Web服务的SOAP协议实现…这是更好的JMS vs webservices …. JMS提供传输协议，它是底层消息传递提供程序，它描述了你的JMS提供程序有多少好或坏，例如MQ是一个强大的可靠的JMS提供程序，其中SOAP协议既可以被视为应用程序级协议，也可以被视为传输协议（在SOAP / HTTP意义上）… SOAP的装备支持基于XML的标准…作为在应用程序级协议中，我们将SOAP视为通过任何传输协议从一个系统传递到另一个系统的消息，作为传输协议，SOAP可以被视为传输有效负载的容器（消息数据）…… SOAP / HTTP可以也被视为JMS meesaging提供者……但在后一种forms中，HTTP具有可靠性问题，因为它涉及与网络，套接字连接，带宽等相关的错误……因此，长话短说，JMS与可靠的消息提供者使得它很好的标准 与良好的传输协议交互，其中webservice作为应用程序级协议使不同的应用程序使用类似XML的SOAP协议进行通信…希望这澄清……
将此作为评论添加到dyffymo的post，但还没有代表。
引用你的答案：
“Web服务是分布式服务的最新趋势。它们使用HTTP作为协议，可以与任何可以通过TCP / IP连接并发出HTTP请求的客户端进行互操作。
您可以使用SOAP或RPC-XML或REST或“契约优先”样式，但使用HTTP作为其协议的分布式组件的基本思想仍然存在。“
我假设Web服务是指WS- *协议集，WSDL和SOAP。 如果是这样，那么这些都不需要使用HTTP作为“传输”协议。 SOA协议集被设计为与所使用的传输协议无关，因此您可以使用HTTP，NamedPipes，原始TCP甚至JMS作为向Web服务传输消息和从Web服务传输消息的方法。
因此，在直接使用JMS与使用“Web服务”的情况下，我认为它主要归结为工具，舒适度，以及您是否真的需要直接访问某些JMS特定function（使用WS- *会隐藏您）。 在这一点上，我认为只有相当规范的应用程序才需要原始的JMS访问。
Web服务是面向服务的体系结构（SOA）的实现。 SOA有三个方面：提供者，代理和请求者，它们是松散耦合的。 提供程序提供代表特定实现的业务服务，请求者无法直接看到该实现。 请求者从代理学习它必须从提供者发送和接收的信息结构以及用于访问该服务的协议。 请求者不知道提供者实现业务服务的方式。
Web服务被定义为请求者和提供者之间所需的业务接口，而不是所有业务请求的公共管道。 有几个变量可以表征Web服务，包括：
- 它们可以紧密耦合，并且它们的部署可以基于调用框架的使用。
- 它们可以在同步请求/应答模式或异步模式下执行。
- 它们可以由J2EE或非J2EE提供程序公开。
- 他们可能会也可能不会为交易和安全提供支持。
JMS是一种基于异步消息的接口。 您还可以使用JMS访问异构系统之间分布的业务逻辑。 具有基于消息的界面可启用以下function：
点对点和发布/订阅机制 。 基于消息的框架可以将信息推送到其他应用程序，而无需明确请求它。 可以将相同的信息并行地传递给许多订户。
节奏独立。 JMS框架在异步模式下运行，但也提供模拟同步请求/响应模式的function。 这允许源系统和目标系统同时工作而不必彼此等待。
保证信息传递 。 JMS框架可以在事务模式下管理消息并确保消息传递（但不保证交付的及时性）。
异构框架之间的互操作性 。 源和目标应用程序可以在异构环境中运行，而不必处理与其各自框架相关的通信和执行问题。
让交流更加流畅 。 切换到消息模式允许更细粒度的信息交换。
资源
JMS和WS都支持分发应用程序。 区别在于异步（JMS）与同步（Web服务）。 Web服务可以用SOAP或REST样式实现。 JMS是一种api，支持两种模式的通信 – 点对点和发布 – 订阅。 Apache ActiveMQ，RabitMQ是许多JMS实现者中的一部分。
从我在这里完成的那些我发现的差异：JMS – 我绑定到JMS提供者 – 但是我有实现类型（pub / sub，点对点）Web服务的选择 – 更容易处理/架构师 – 但它更多的是盒子之间的直接通信。 很多用于开发的工具 – 以及一个干净的接口（WSDL），因此实现者和调用者可以是独立的。
哪一个使用？ 取决于问题所在。
这一切都取决于您的要求，您将使用哪些框架以及您的应用程序环境和行为。 如果您可以对此进行概述，那么您可以得到一个严格的答案。
现在就像比较一辆卡车和一辆轿车，你必须知道你将用它做什么，以及在哪条道路上能够决定哪一辆更好。