Java JMS 与 Web 服务

JMS vs Webservices

提问by Martin K.

What are the big advantages from JMS over Webservices or vice versa?

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

(Are webservices bloated? Is JMS overall better for providing interfaces?)

（网络服务是否臃肿？JMS 整体上是否更适合提供接口？）

采纳答案by duffymo

EDITED after correction from erickson:

埃里克森更正后编辑：

JMS requires that you have a JMS provider, a Java class that implements the MessageListener interface for processing messages, and a client that knows how to connect to the JMS queue. JMS means asynchronous processing - the client sends the message and doesn't necessarily wait for a response. JMS can be used in a point-to-point queue fashion or publish/subscribe.

JMS 要求您有一个 JMS 提供程序、一个实现 MessageListener 接口以处理消息的 Java 类，以及一个知道如何连接到 JMS 队列的客户端。JMS 意味着异步处理 - 客户端发送消息并且不一定等待响应。JMS 可用于点对点队列方式或发布/订阅。

"Service" is a fluid term. I think of a service as a component that lives out on a network and advertises a contract: "If you send me X I'll perform this task for you and return Y."

“服务”是一个流动的术语。我将服务视为存在于网络中的一个组件，并为合同做广告：“如果你给我发送 X，我会为你完成这项任务并返回 Y。”

Distributed components have been around for a long time. Each one communicated using a different protocol (e.g., COM, Corba, RMI, etc.) and exposed their contract in different ways.

分布式组件已经存在很长时间了。每个人都使用不同的协议（例如，COM、Corba、RMI 等）进行通信，并以不同的方式公开他们的合同。

Web services are the latest trend in distributed services. They use HTTP as their protocol and can interoperate with any client that can connect via TCP/IP and make an HTTP request.

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

You can use SOAP or RPC-XML or REST or "contract first" styles, but the underlying idea of a distributed component using HTTP as its protocol remains.

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

If you accept all this, web services are usually synchronous calls. They need not be bloated, but you can write bad components in any style or language.

如果您接受所有这些，Web 服务通常是同步调用。它们不需要臃肿，但您可以使用任何风格或语言编写不良组件。

You can start designing any distributed component by designing the request and responses first. Given those, you choose JMS or web services based on what kind of clients you want to have and whether or not the communication is synchronous or asynchronous.

您可以通过首先设计请求和响应来开始设计任何分布式组件。鉴于这些，您可以根据想要拥有的客户端类型以及通信是同步还是异步来选择 JMS 或 Web 服务。

回答by BZ.

From the ones I've done here's the differences I've found: JMS - I'm tied to the JMS provider - however I have choices of implementation type (pub/sub, point to point) Web Service - easier to handle/architect - however its more of a direct communication between the boxes. Lots of tools to use to do the development - and a clean interface (WSDL's) so implementor and caller can be independent.

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

Which one to use? Depends on what the problem is.

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

回答by erickson

I'd say the biggest distinction is that JMS is message-oriented, rather than RPC-oriented. Out-of-the-box, most JMS providers support high-level protocols that perform retries, prevent duplicates, and support transactions.

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

There are many applications where these capabilities are unnecessary. But where they are needed, building them yourself on top of an RPC mechanism is complicated, expensive, and error-prone.

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

回答by Richard

Message based systems, including JMS, provide the ability to be "chronologically decoupled" from the other end. A message can be sent without the other end being available.

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

All other common A2A approaches require the partner to be able to respond immediately, requiring them to be able to handle peak loads, with little ability to spread processing.

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

回答by sfitts

Would add this as a comment to dyffymo's post, but don't yet have the rep.

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

Quoting from your answer:

引用你的回答：

"Web services are the latest trend in distributed services. They use HTTP as their protocol and can interoperate with any client that can connect via TCP/IP and make an HTTP request.

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

You can use SOAP or RPC-XML or REST or "contract first" styles, but the underlying idea of a distributed component using HTTP as its protocol remains."

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

---

---

I'm assuming by web services you mean the WS-* set of protocols, WSDL, and SOAP. If so, then none of these require the use of HTTP as the "transport" protocol. The SOA set of protocols was designed to be agnostic as to the tramission protocols used, so you can use HTTP, NamedPipes, raw TCP, and even JMS as the means to transmit messages to and from a web service.

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

So in the case of direct use of JMS vs. use of "web services" I think it mostly boils down to tooling, comfort level, and whether you really need direct access to some JMS specific feature (which using WS-* would hide from you). At this point I would think that only fairly specilized applications would require raw JMS access.

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

回答by ag112

let me talk w.r.t SOAP protocol implementation of web services...which is better JMS vs webservices....JMS provides transport protocol and it is underlying messaging provider which depicts how much good or bad is ur JMS provider for e.g. MQ is a powerful reliable JMS provider where as SOAP protocol can be considered both application level protocol and can also be treated as a transport protocol (in sense of SOAP/HTTP)...the beenfit of SOAP is in support of XML based standard...as an application level protocol, we consider SOAP as a message to be passed from one system to another over any transport protocol where as a transport protocol, SOAP can be considered as a container for transporting a payload(message data)...SOAP/HTTP can also be looked as JMS meesaging provider....but in latter form, HTTP has issue of reliablity, as it invloves errors related to networking, socket connections, bandwidth etc...so keeping long story short, JMS with reliable message provider makes it good standard for interacting with good transport protocol where webservice as an application level protocol makes disparate application to communicate using XML-like-SOAP protocol...hope this clarifies...

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

回答by ag112

It all depends on your requirements, what frameworks will you use and your applications environment and behavior . If you can give an overview about that then you can get a rigid answer.

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

It's now like comparing a truck with a sedan car, You must know what will you use it for and on which road to be able decide which one is better.

现在就像比较一辆卡车和一辆轿车，你必须知道你会用它做什么，在哪条路上才能决定哪一条更好。

回答by Premraj

Web servicesare an implementation of Services Oriented Architectures (SOA). A SOA has three parties: a provider, a broker, and a requester, which are loosely coupled. The provider offers a business service that represents a particular implementation, which is not directly visible to the requester. The requester learns from the broker the information structure that it has to send and receive from the provider and what protocol to use to access that service. The requester has no knowledge of the way the provider implements the business service.

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

Web services are defined as required business interfaces between a requester and a provider, and not as a common pipe for all business requests. There are several variables that can characterize web services, including that:

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

• They can be tightly coupled, and their deployment can be based on the use of invocation frameworks.
• They can perform either in a synchronous request/reply mode or in an asynchronous mode.
• They can be exposed by J2EE or non-J2EE providers.
• They might or might not offer support for transactions and security.

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

---

---

JMSis an asynchronous message-based interface. You can also use JMS to access business logic distributed among heterogeneous systems. Having a message-based interface enables the following functions:

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

Point to point and publish/subscribe mechanisms. Message-based frameworks can push information to other applications without their requesting it explicitly. The same information can be delivered to many subscribers in parallel.

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

Rhythm independence.JMS frameworks function in asynchronous mode but also offer the capability of simulating a synchronous request/response mode. This allows source and target systems to work simultaneously without having to wait for each other.

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

Guaranteed information delivery. JMS frameworks can manage the messages in transactional mode and ensure message delivery (but without any guarantee of timeliness of delivery).

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

Interoperability between heterogeneous frameworks. The source and target applications can operate in heterogeneous environments without having to handle problems of communication and execution related to their respective frameworks.

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

Making exchanges more fluid. The switch to message mode allows finer-grained information exchange.

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

Source

来源

回答by Premraj

JMS and WS both enable distribute applications. The difference is asynchronous(JMS) vs synchronous (Web Services). Web Services can be implemented in SOAP or REST styles. JMS is a api which supports communication in two modes - point-to-point and publish-subscribe. Apache ActiveMQ, RabitMQ are some of the many JMS implementors.

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