JMS与Web服务

Question

JMS优于Webservices有什么大优势，反之亦然？

（Web服务是否膨胀？JMS总体上更适合提供接口吗？）

Answer 1

从埃里克森校正后编辑：

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服务。

Answer 2

基于消息的系统（包括JMS）提供了从另一端“按时间顺序解耦”的能力。可以在没有另一端可用的情况下发送消息。

所有其他常见的A2A方法要求合作伙伴能够立即做出响应，要求他们能够处理峰值负载，几乎没有能力进行扩散处理。

Answer 3

我认为最大的区别是JMS是面向消息的，而不是面向RPC的。开箱即用，大多数JMS提供程序支持执行重试，防止重复和支持事务的高级协议。

有许多应用程序不需要这些功能。但是在需要它们的地方，在RPC机制之上自己构建它们是复杂，昂贵且容易出错的。

Answer 4

让我谈谈w.r.t Web协议的SOAP协议实现...这是更好的JMS vs webservices .... JMS提供传输协议，它是底层消息传递提供者，它描述了你的JMS提供者有多少好或坏。 MQ是一个功能强大的可靠JMS提供程序，其中SOAP协议既可以被视为应用程序级协议，也可以被视为传输协议（在SOAP / HTTP意义上）...... SOAP的装备支持基于XML的标准。 ..作为应用程序级协议，我们将SOAP视为通过任何传输协议从一个系统传递到另一个系统的消息，作为传输协议，SOAP可以被视为传输有效负载的容器（消息数据）...... SOAP / HTTP也可以看作是JMS meesaging provider ....但是在后一种形式中，HTTP具有可靠性问题，因为它会引发与网络，套接字连接，带宽等相关的错误......所以保持长篇短篇，JMS与可靠的消息提供程序使其成为与良好传输协议交互的良好标准，其中webservice作为应用程序级协议使不同的应用程序使用类似XML的SOAP协议进行通信...希望这澄清......

Answer 5

Web服务是面向服务的体系结构（SOA）的实现。 SOA有三个方面：提供者，代理和请求者，它们是松散耦合的。提供程序提供代表特定实现的业务服务，请求者无法直接看到该实现。请求者从代理学习它必须从提供者发送和接收的信息结构以及用于访问该服务的协议。请求者不知道提供者实现业务服务的方式。

Web服务被定义为请求者和提供者之间所需的业务接口，而不是所有业务请求的公共管道。有几个变量可以表征Web服务，包括：

• 它们可以紧密耦合，它们的部署可以基于调用框架的使用。
• 他们可以在同步请求/回复模式或异步模式下执行。
• 它们可以由J2EE或非J2EE提供者公开。
• 他们可能会也可能不会为交易和安全提供支持。

JMS 是一个基于异步消息的界面。您还可以使用JMS访问异构系统之间分布的业务逻辑。使用基于消息的界面可以实现以下功能：

点对点和发布/订阅机制。基于消息的框架可以将信息推送到其他应用程序，而无需明确请求它。可以将相同的信息并行地传递给许多订户。

节奏独立性。 JMS框架在异步模式下运行，但也提供模拟同步请求/响应模式的功能。这允许源系统和目标系统同时工作而不必彼此等待。

保证信息传递。 JMS框架可以在事务模式下管理消息并确保消息传递（但不保证交付的及时性）。

异构框架之间的互操作性。源和目标应用程序可以在异构环境中运行，而不必处理与其各自框架相关的通信和执行问题。

让交流变得更加流畅。切换到消息模式允许更细粒度的信息交换。

Source

Answer 6

将此作为评论添加到dyffymo的帖子中，但还没有代表。

引用你的回答：

“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特定功能（使用WS- *）会躲避你）。在这一点上，我认为只有相当规范的应用程序才需要原始的JMS访问。

Answer 7

从我在这里所做的那些我发现的差异： JMS - 我绑定到JMS提供程序 - 但是我有实现类型的选择（pub / sub，point to point） Web服务 - 更易于处理/架构 - 但更多的是它们之间的直接通信。很多用于开发的工具 - 以及一个干净的接口（WSDL），因此实现者和调用者可以是独立的。

使用哪一个？取决于问题所在。

Answer 8

这完全取决于您的要求，您将使用哪些框架以及您的应用程序环境和行为。如果您可以对此进行概述，那么您可以得到一个严格的答案。

现在比较一辆卡车和一辆轿车，你必须知道你将用它做什么，以及在哪条路上能够决定哪一辆更好。

Answer 9

JMS和WS都支持分发应用程序。区别在于异步（JMS）与同步（Web服务）。 Web服务可以用SOAP或REST样式实现。 JMS是一种api，支持两种模式的通信 - 点对点和发布 - 订阅。 Apache ActiveMQ，RabitMQ是许多JMS实现者中的一部分。