当前位置：文江博客话题详情

JMS 和 ESB - 它们有何关系？

发布于 2024-10-21 22:52:34 字数 144 浏览 1 评论 0原文

对我来说，JMS 和 ESB 似乎是非常相关的东西，我正在尝试了解它们到底是如何相关的。

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

爱*していゐ 2024-10-28 22:52:34

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 offers a set of APIs for messaging: put a message on a queue, someone else, sometime later, perhaps geographically far away takes the message off the queue and processes it. We have decoupled in time and location of the message provider and consumer. Even if the message consumer happens to be down for a time we can keep producing messages.

JMS also offers a publish/subscribe capability where the producer puts the message to a "topic" and any interested parties can subscribe to that topic, receiving messages as and when they are produced, but for the moment focus just on the queue capabilty.

We have decoupled some aspects of the relationship between provider and consumer. However some coupling remains. First, as things stand every message is processed in the same way. Suppose we want to introduce different kinds of processing for different kinds of messages:

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

Obviously we can write code like that, but an alternative would be to have a messaging system that can send different messages to different places we set up three queues:

 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

And then all we need is a little bit of cleverness in the queue system itself to transfer then messsage from the Request Queue to the Platinum Queue or Standard Queue.

So this is a Content-Based Routing capability, and is something that an ESB provides. Note that the ESB uses the fundamental Queueing capabilities offered by JMS.

A second kind of couppling is that the consumer and producer must agree about the message format. In simple cases that's fine. But when you start to have many producers all putting message to the same queue you start to hit versioning problems. New message formats are introduced but you don't want to change all the existing providers.

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

And the ESB picks up the Version 1 Queue messages and transforms them into Version 2 messages and puts them onto the Version 2 queue.

Message transformation is another possible ESB capability.

Have a look at ESB products, see what they can do. As I work for IBM, I'm most familiar with WebSphere ESB

回复收藏 0 原文

春风十里 2024-10-28 22:52:34

我想说 ESB 就像许多协议的门面......JMS 就是其中之一。

回复收藏 0 原文

万水千山粽是情ミ 2024-10-28 22:52:34

上述列表中的一个补充是最新的开源 ESB - UltraESB

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

回复收藏 0 原文