24

JMS 相对于 Web 服务的最大优势是什么，反之亦然？

（Web 服务是否臃肿？JMS 总体上是否更适合提供接口？）

4

9 回答 9

29

埃里克森更正后编辑：

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

于 2009-05-12T22:57:31.200 回答
6

基于消息的系统，包括 JMS，提供了与另一端“按时间顺序分离”的能力。可以在另一端不可用的情况下发送消息。

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

于 2009-05-12T23:14:40.907 回答
4

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

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

于 2009-05-12T23:10:14.143 回答
3

Web 服务是面向服务的体系结构 (SOA) 的一种实现。SOA 包含三方：提供者、代理和请求者，它们是松散耦合的。提供者提供代表特定实现的业务服务，请求者无法直接看到该实现。请求者从代理那里了解它必须从提供者发送和接收的信息结构，以及使用什么协议来访问该服务。请求者不知道提供者实现业务服务的方式。

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

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

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

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

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

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

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

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

在此处输入图像描述

来源

于 2015-12-18T01:04:41.430 回答
2

让我谈谈 Web 服务的 SOAP 协议实现……JMS 与 Web 服务更好……JMS 提供传输协议，它是底层消息传递提供程序，它描述了你的 JMS 提供程序的好坏，例如 MQ 是一个强大的可靠的 JMS 提供程序，其中 SOAP 协议既可以被视为应用程序级协议，也可以被视为传输协议（在 SOAP/HTTP 的意义上）...SOAP 的好处是支持基于 XML 的标准...作为应用程序级协议，我们将 SOAP 视为通过任何传输协议从一个系统传递到另一个系统的消息，其中作为传输协议，SOAP 可以被视为传输有效负载（消息数据）的容器......SOAP/HTTP 可以也被视为 JMS 消息传递提供者....但在后一种形式中，HTTP 存在可靠性问题，因为它涉及与网络、套接字连接、带宽等相关的错误......所以长话短说，具有可靠消息提供程序的 JMS 使其成为与良好传输协议交互的良好标准，其中 web 服务作为应用程序级协议使不同的应用程序使用XML-like-SOAP 协议...希望这可以澄清...

于 2010-12-05T17:35:43.567 回答
1

从我所做的这些是我发现的差异： JMS - 我与 JMS 提供者绑定 - 但是我可以选择实现类型（发布/订阅，点对点） Web 服务 - 更易于处理/架构师- 然而，它更多的是盒子之间的直接通信。许多工具可用于开发 - 以及干净的接口 (WSDL)，因此实现者和调用者可以独立。

使用哪一个？取决于问题是什么。

于 2009-05-12T23:04:36.713 回答
1

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

引用你的回答：

“Web 服务是分布式服务的最新趋势。它们使用 HTTP 作为协议，可以与任何可以通过 TCP/IP 连接并发出 HTTP 请求的客户端进行互操作。

您可以使用 SOAP 或 RPC-XML 或 REST 或“契约优先”样式，但使用 HTTP 作为其协议的分布式组件的基本思想仍然存在。”

我假设 Web 服务是指 WS-* 协议集、WSDL 和 SOAP。如果是这样，那么这些都不需要使用 HTTP 作为“传输”协议。SOA 协议集设计为与所使用的传输协议无关，因此您可以使用 HTTP、NamedPipes、原始 TCP 甚至 JMS 作为与 Web 服务之间传输消息的方法。

因此，在直接使用 JMS 与使用“Web 服务”的情况下，我认为这主要归结为工具、舒适度以及您是否真的需要直接访问某些 JMS 特定功能（使用 WS-* 会隐藏你）。在这一点上，我认为只有相当特殊的应用程序才需要原始 JMS 访问。

于 2009-05-13T05:01:07.487 回答
0

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

现在就像将卡车与轿车进行比较，您必须知道将其用于什么以及在哪条道路上才能决定哪条更好。

于 2013-09-17T01:20:27.587 回答
0

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

于 2016-11-10T19:20:52.353 回答