JMS和ESB-它们之间的关系如何? [英] JMS and ESB - how they are related?
问题描述
对我来说，JMS和ESB似乎是非常相关的东西，我正试图了解它们之间的确切关系.
我已经看到一个句子，即JMS可用作ESB的传输-那么在这种ESB中应该存在除传输之外的其他内容? JMS是简单的ESB还是不是，那么真正的ESB缺少什么?
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
For me JMS and ESB seem to be very related things and I'm trying to understand how exactly they are related.
I've seen a sentence that JMS can be used as a transport for ESB - then what else except the transport should be present in such an ESB? Is JMS a simple ESB or if not, then what it lacks from the real 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
这篇关于JMS和ESB-它们之间的关系如何?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
