问题描述
长话短说，我正在开展一个项目，出于所有常见原因，我们正在重写一个大型 Web 应用程序.重写的主要目的是将这个运行在单个服务器上的大型单一应用程序分成许多较小的解耦应用程序，这些应用程序可以在多个服务器上运行.
To cut a long story short, I am working on a project where we are rewriting a large web application for all the usual reasons. The main aim of the rewrite is to separate this large single application running on single server into many smaller decoupled applications, which can be run on many servers.
好的，这就是我想要的:
Ok here's what I would like:
我希望 HTTP 成为主要的传输机制.当一个应用程序(例如 CMS)已更新时，它将通过 http 联系代理并说 我已更改"，然后代理将发送回一个 200 OK 说 谢谢我收到消息".
I would like HTTP to be the main transport mechanism. When one application for example the CMS has been updated it will contact the broker via http and say "I've changed", then the broker will send back a 200 OK to say "thanks I got the message".
然后，代理将查看其希望了解 CMS 更改的其他应用程序列表，并将消息传递到应用程序在告诉代理它想听到消息时留下的 url.
The broker will then look on its list of other applications who wanted to hear about CMS changes and pass the message to the url that the application left when it told the broker it wanted to hear about the message.
其他应用程序在收到消息时将返回 200 OK，否则代理会保留该消息并将其排队等待下次有人尝试联系该应用程序.
The other applications will return 200 OK when they receive the message, if not the broker keeps the message and queues it up for the next time someone tries to contact that application.
问题是我什至不知道从哪里开始，也不知道我需要做什么.我一直在查看 XMPP、ActiveMQ、RabbitMQ、Mule ESB 等，可以看到我可以花明年在这些东西上绕圈子.
The problem is I don't even know where to start or what I need to make it happen. I've been looking at XMPP, ActiveMQ, RabbitMQ, Mule ESB etc. and can see I could spend the next year going around in circles with this stuff.
任何人都可以根据个人经验提供任何建议，因为我很想避免以艰难的方式学习课程.
Could anyone offer any advice from personal experience as I would quite like to avoid learning lessons the hard way.
推荐答案
首先，不要担心 ESB.您所描述的情况完全在简单的面向消息的中间件的范围内.如果你正在做诸如中介、基于内容的路由、协议转换之类的事情，你只需要"一个 ESB；除了将消息路由到正确的位置之外，中间件处理消息的事情.
First of all, don't worry about ESBs. The situation you've described lies well within the bounds of straightforward message-oriented middleware. You only "need" an ESB if you're doing things like mediations, content-based routing, protocol transformations; things where the middleware does stuff to the message, on top of routing it to the right place.
如果您有一组不同的目标应用程序需要相互通信 - 听起来确实如此 - 您是对的，通过与语言无关的协议(如 XMPP，STOMP 或 HTTP)是一个很好的解决方案.这基本上意味着您不必编写和运行大量 Java 守护程序即可将消息转换为您最喜欢的 JMS 风格.
If you have a diverse set of destination applications that need to speak to each other - and it sounds like you do - you're right that messaging over a language agnostic protocol (like XMPP, STOMP or HTTP) is a neat solution. It basically means you don't have to write and run loads of Java daemons to translate messages into your favourite flavour of JMS.
STOMP 越来越受到消息代理的支持，尤其是开源代理，并且有许多不同的客户端库.它是一种轻量级协议，专为消息传递而设计，因此您可以获得比 HTTP 更丰富的开箱即用功能.
STOMP is increasingly supported by message brokers, especially by the open-source ones, and there's a number of different client libraries. It is a lightweight protocol, specifically designed for messaging so you get a much richer feature set out of the box than you would with HTTP.
对我来说，XMPP 有点弱，因为它在服务器端没有得到很好的支持，尽管能够通过 IM 向你的代理发送消息很有趣 :)
For me, XMPP is a bit of a weak option as it's not so well supported on the server side, although it is fun to be able to IM your broker :)
如果你设置在 HTTP 上，OpenMQ 非常好，我已经个人使用它的 通用消息服务 - 基本上是围绕 JMS 的 webapp 包装器目的地.它提供了一个 REST-ful 接口，具有一组与 STOMP 提供的相似的动词.
If you are set on HTTP, OpenMQ is very good, and I've personally used its Universal Message Service - basically a webapp wrapper around JMS destinations. It provides a REST-ful interface, with a similar set of verbs as STOMP provides.
这篇关于消息、队列和 ESB - 我知道我想去哪里，但不知道如何到达那里的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，WP2