JMS 和 ESB - 它们是如何相关的？答案

【问题标题】：JMS and ESB - how they are related?JMS 和 ESB - 它们是如何相关的？
【发布时间】：2011-07-16 09:54:10
【问题描述】：

对我来说，JMS 和 ESB 似乎是非常相关的东西，我正试图了解它们究竟是如何相关的。

我看到过一句话，JMS 可以用作 ESB 的传输 - 那么除了传输之外还应该存在于这样的 ESB 中吗？ JMS 是一个简单的 ESB，或者如果不是，那么它与真正的 ESB 相比缺少什么？

【问题讨论】：

有些愤世嫉俗的人会说 JMS 是一个特定的 Java API，其中“ESB”是一个营销术语，涵盖了众多相关技术和设计方法，意义不大。
@skaffman 即使是一些聪明的乐观主义者也可能同意你的观点；-)

标签： jms esb

【解决方案1】：

JMS 提供了一组用于消息传递的 API：将消息放在队列中，其他人在稍后的某个时间，可能在地理上很远的地方将消息从队列中取出并处理它。我们在时间和位置上解耦了消息提供者和消费者。即使消息消费者碰巧宕机了一段时间，我们也可以继续生产消息。

JMS 还提供发布/订阅功能，生产者将消息放入“主题”，任何感兴趣的各方都可以订阅该主题，在消息产生时接收消息，但目前只关注队列能力。

我们已经解耦了提供者和消费者之间关系的某些方面。然而，一些耦合仍然存在。首先，就目前情况而言，每条消息都以相同的方式处理。假设我们要为不同种类的消息引入不同种类的处理：

 if ( message.customer.type == Platinum )
      do something special

显然我们可以编写这样的代码，但另一种方法是拥有一个可以将不同消息发送到不同位置的消息传递系统，我们设置了三个队列：

 Request Queue, the producer(s) puts their requests here
 Platinum Queue, platinum consumer processing reads from here
 Standard Queue, a standard consumer reads messages from here

然后我们需要的只是队列系统本身的一点点聪明，以便将消息从请求队列转移到白金队列或标准队列。

所以这是基于内容的路由功能，并且是 ESB 提供的东西。请注意，ESB 使用 JMS 提供的基本队列功能。

第二种耦合是消费者和生产者必须就消息格式达成一致。在简单的情况下，这很好。但是，当您开始让许多生产者都将消息放入同一个队列时，您就会开始遇到版本控制问题。引入了新的消息格式，但您不想更改所有现有的提供程序。

  Request Version 1 Queue  Existing providers write here
  Request Version 2 Queue  New provider write here, New Consumer Reads here

然后 ESB 拾取版本 1 队列消息并将它们转换为版本 2 消息并将它们放入版本 2 队列中。

消息转换是另一种可能的 ESB 功能。

看看 ESB 产品，看看它们能做什么。在 IBM 工作时，我最熟悉 WebSphere ESB

【讨论】：

所以JMS只带来了基本的排队能力。 ESB 提供了更多功能来管理这些队列、它们的订阅者和提供者，并且可以基于 JMS 的低级别？还是 ESB 中除此之外还有其他东西？
关于“在总线中”应该做什么以及应该在 ESB 之外做什么，存在一个完整的争论领域。不同的供应商有不同的答案。我认为最好从 ESB 作为一套架构模式开始，然后看看你正在考虑的比特产品可能会为你做什么。

【解决方案2】：

我会说 ESB 就像是许多协议的外观......JMS 就是其中之一。

【讨论】：

【解决方案3】：

除了上述列表之外，还有最新的开源 ESB - UltraESB

JMS 不太适合集成 REST 服务、文件系统、S/FTP、电子邮件、Hessian、SOAP 等，这些服务最好使用原生支持这些类型的 ESB 来处理。例如，如果您有一个进程在午夜转储一个 500MB 的 CSV 文件，并且您希望另一个系统提取该文件、解析 CSV 并导入数据库，这可以通过 ESB 轻松完成 - 而只有JMS 会很糟糕。同样，使用原生支持 HTTP/S 的 ESB 可以更好地集成 REST 服务，以及到多个后端实例的负载平衡/故障转移。

【讨论】：

转储 CSV 并提取以进行处理可以通过其他几种方式完成。不需要昂贵的 ESB 解决方案。 ESB 可以处理的任何更好和更复杂的用例都将是它的理想选择。

【解决方案4】：

这种转换不会自动发生。您需要配置映射或编写转换服务

看https://access.redhat.com/knowledge/docs/en-US/JBoss_Enterprise_SOA_Platform/4.2/html/SOA_ESB_Message_Transformation_Guide/ch02s03.html

问候，拉贾·纳根德拉·库马尔， C.T.O www.tejasoft.com

【讨论】：

【解决方案5】：

除了 JMS，ESB 还提供与许多不同协议的集成。
大多数在幕后使用 JMS 来传输、存储和移动消息。一种这样的解决方案 OpenESB，使用 XML 格式的消息。

有一些开源 ESB，您可以签出 -

像 ActiveMQ 这样的 JMS 实现内置了 Camel。

【讨论】：

【解决方案6】：

JMS 是一种用于与底层消息传递层进行通信的协议。 ESB 在更高级别上运行，以统一的方式提供与多种技术和协议（其中之一是 JMS）的集成，从而使复杂流的管理更加简单。

【讨论】：

【解决方案7】：

有 JMS 消息代理，您可以使用 ESB 轻松配置它们。 https://docs.wso2.com/display/ESB470/JMS+Transport

【讨论】：

【解决方案8】：

JMS 和 ESB 都提供了不同应用程序之间的通信方式。 但是 JMS 和 ESB 的上下文不同。 JMS 是为了满足简单的需要。 JMS 由 JMS Provider 实现。它是 Java 特定的。

JMS 提供程序的示例有：Apache Active MQ、IBM MQ、HornetQ 等。

ESB 用于复杂的需求。 ESB 是 EAI 中的一个组件，为各种应用程序提供通信设施。 它是通用的而不是 Java 特有的。 JMS 是受支持的协议之一。

ESB 提供者的示例有：MuleESB、Apache Camel、OpenESB

用例：如果我们所有的通信应用程序都使用 Java 并且使用相同的消息格式，那么使用 ESB 可能会产生开销。这里 JMS 可能就足够了。

【讨论】：