logo标签列表

JMS与Web服务的区别

javaweb-servicesjms
24

JMS和Web服务相比有哪些明显的优势？

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

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

3
JMS不仅限于Java。JMS经过精心设计，允许供应商为其专有的消息服务提供Java接口。同时，也有支持开放式消息协议如ebXML的JMS提供者。这两种方法都可以使基于JMS的Java应用程序与其他平台上的消息应用程序互操作。 - erickson
1
那么 WS-* 和 JMS 都是分布式通信中广告合同的方式。我应该在什么情况下使用 WS-*，什么情况下使用 JMS？我阅读了 http://www.unf.edu/~ree/1024IC.pdf 。JMS 在那里对小数据集的性能优于 WS-，并提供支持“离线目标”，而 WS- 可以更好地处理大量数据。这是唯一的优势 / 劣势吗？编写 JMS 端点的工作量是否等于 WS-* 端点？如何在它们之间做出决策？看起来 JMS 更轻量级，不是吗？ - Martin K.
2
当你说“大量”时，你指的是什么？由于大型XML文档的困难，WS-*在处理非常大的数据方面表现不佳。大多数JMS也没有针对处理巨大数据进行优化，但由于专有系统中实现的自由度更大，JMS提供者处于更好的处理位置。至于选择哪个，取决于应用程序以及消息如何使用，而不是消息本身（大小和格式）。而且，不要忘记，JMS提供者可以使用WS-*服务来实现。 - erickson
7

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

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

4

我认为最大的区别在于JMS是面向消息的，而不是面向RPC的。大多数JMS提供商都支持高级协议，可以执行重试、防止重复和支持事务。

虽然有很多应用程序并不需要这些功能，但在需要它们的情况下，如果要在RPC机制之上自己构建这些功能，那么会变得非常复杂、昂贵且容易出错。

HTTP、XML和SOAP不需要RPC模型。事实上，.NET中的WCF有处理通信作为传入和传出消息的选项。它非常面向消息。我认为在基于Java的“Web服务”堆栈中也有类似的隐喻可用。 - Cheeso
当然，您可以通过RPC传递“消息”，Java也提供了这种能力。我所说的“面向消息”是指异步、可靠和事务性，这些是REST或基于WS-*的Web服务无法提供的...尽管您当然可以使用单个不可靠的同步操作定义必要的高级协议。 - erickson
3

Web服务是面向服务的体系结构(SOA)的一种实现。SOA有三个参与方：提供者、代理和请求者，它们之间松散耦合。提供者提供了一个业务服务，表示特定的实现，这对于请求者来说并不直接可见。请求者从代理处学习信息结构，以便向提供者发送和接收信息，并使用什么协议访问该服务。请求者不会知道提供者如何实现业务服务。

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

  • 它们可以紧密耦合，其部署可以基于调用框架。
  • 它们可以在同步请求/响应模式或异步模式下执行。
  • 它们可以由J2EE或非J2EE提供商公开。
  • 它们可能或可能不提供事务和安全支持。

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

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

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

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

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

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

enter image description here

来源

2
让我谈一下关于Web服务的SOAP协议实现... JMS和Web服务哪个更好？JMS提供传输协议，是基础消息提供程序，它描述了您的JMS提供程序的好坏程度，例如MQ是一个功能强大可靠的JMS提供程序，而SOAP协议可以被认为是应用级协议，也可以被视为传输协议（在SOAP/HTTP的意义上）... SOAP的好处在于支持基于XML的标准...作为应用级协议，我们将SOAP视为要通过任何传输协议从一个系统传递到另一个系统的消息，而作为传输协议，SOAP可以被视为用于传输有效载荷（消息数据）的容器... SOAP/HTTP也可以被看作是JMS消息提供程序...但是在后一种形式中，HTTP存在可靠性问题，因为它涉及与网络、套接字连接、带宽等相关的错误...因此，长话短说，具有可靠消息提供程序的JMS使其成为与良好传输协议交互的良好标准，而Web服务作为应用级协议，使用类似XML的SOAP协议使不同的应用程序进行通信...希望这样能够澄清问题...
1

从我所做的几个方面来看，我发现了以下区别： JMS - 我被绑定到JMS提供商-但是我可以选择不同的实现类型(发布/订阅，点对点) Web Service - 更容易处理/设计 - 但它更像是盒子之间的直接通信。有许多工具可用于开发 - 并且具有干净的接口(WSDL)，因此实现者和调用者可以独立。

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

1
WSDL绝不是独立性的保证。如果您公开Java类，则必须使它们对客户端和服务器都可用。在WSDL中公开的这些类的更改需要更新两者。“契约优先”XML是更好的选择。 - duffymo
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访问。
0

这完全取决于您的需求，您将使用哪些框架以及您的应用程序环境和行为。如果您可以概述一下这些内容，那么您就可以得到一个明确的答案。

这就像比较卡车和轿车一样，您必须知道它将用于什么以及在哪条路上，才能决定哪个更好。

0
JMS和WS都可以实现分布式应用程序。它们的区别在于异步（JMS）与同步（Web Services）。Web Services可以采用SOAP或REST风格进行实现。JMS是一个API，支持点对点和发布-订阅两种通信模式。Apache ActiveMQ、RabitMQ等是众多JMS实现者之一。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接