长话短说，我正在开展一个项目，出于所有常见原因，我们正在重写一个大型 Web 应用程序。重写的主要目的是将运行在单个服务器上的大型单个应用程序分成许多较小的解耦应用程序，这些应用程序可以在许多服务器上运行。
好的，这就是我想要的：
我想HTTP成为主要的传输机制。当一个应用程序（例如 CMS）已更新时，它将通过 http 联系代理并说"I've changed"，然后代理将发回一个200 OK说"thanks I got the message"。
然后，代理将查看其想要了解 CMS 更改的其他应用程序列表，并将消息传递到应用程序在告诉代理它想听到消息时留下的 url。
其他应用程序将200 OK在收到消息时返回，如果没有，代理会保留该消息并将其排队等待下次有人尝试联系该应用程序。
问题是我什至不知道从哪里开始或者我需要什么来实现它。我一直在看XMPP、ActiveMQ、等RabbitMQ，Mule ESB并且可以看到我可以在接下来的一年里用这些东西绕圈子。
任何人都可以从个人经验中提供任何建议，因为我很想避免以艰难的方式学习课程。
首先，不要担心 ESB。您所描述的情况完全在简单的面向消息的中间件的范围内。如果你正在做诸如中介、基于内容的路由、协议转换之类的事情，你只“需要”一个 ESB；除了将消息路由到正确的位置之外，中间件对消息进行处理的事情。
如果你有一组不同的目标应用程序需要相互通信——听起来你确实是这样——你是对的，通过与语言无关的协议（如 XMPP、STOMP或 HTTP）进行消息传递是一个很好的解决方案。这基本上意味着您不必编写和运行大量 Java 守护程序即可将消息转换为您最喜欢的 JMS 风格。
STOMP 越来越受到消息代理的支持，尤其是开源代理，并且有许多不同的客户端库。它是一种轻量级协议，专为消息传递而设计，因此您可以获得比 HTTP 更丰富的开箱即用功能。
对我来说，XMPP 有点弱，因为它在服务器端没有得到很好的支持，尽管能够 IM 给你的经纪人很有趣 :)
如果您设置在 HTTP 上，OpenMQ非常好，而且我个人使用过它的通用消息服务- 基本上是一个围绕 JMS 目标的 webapp 包装器。它提供了一个 REST-ful 接口，具有一组与 STOMP 提供的相似的动词。
自 2003 年左右以来，我一直在各种软件系统中使用 JMS 消息传递。我有一个 Web 应用程序，其中客户端实际上是 JMS 主题订阅者。仅仅通过将消息发布到主题中的行为，消息就会被服务器推送到所有订阅的 Web 客户端。
Web 客户端是基于 Flex 的。我们的中间层堆栈包括：
BlazeDS 能够配置为连接 JMS 的桥梁。它是一个 Tomcat servlet，它响应 Flex 客户端远程调用，但也可以在其配置的 JMS 主题中出现新消息时向客户端推送消息。
BlazeDS 实现了 Comet 模式来进行服务器端消息推送：
异步 HTTP 和 Comet 架构介绍异步、非阻塞 HTTP 编程
Farata Systems 宣布他们已修改 BlazeDS 以使用 Jetty 延续方法来实施彗星模式。这可以针对单个物理服务器扩展到数千个 Comet 连接。
Farata Systems 借助 Adobe BlazeDS 实现性能突破
我们正在等待 Adobe 自己在 BlazeDS 中实现对 Servlet 3.0 的支持，因为基本上我们非常热衷于组合使用 Tomcat 和 Spring。
实现大规模可扩展 Comet 模式的技术的关键是将 Java NIO HTTP 侦听器与线程池结合使用（例如 Java 5 并发库中的 Executor 类）。Servlet 3.0 是一个异步事件驱动的 servlet 模型，可以与这样的 HTTP 侦听器绑定在一起。然后可以针对单个物理服务器维持数千个（数字如 10,000 到 20,000 个）并发 Comet 连接。
尽管在我们的案例中，我们使用 Adobe Flex 技术将 Web 客户端转变为事件驱动的消息订阅者，但对于任何通用 AJAX Web 应用程序都可以这样做。在 AJAX 圈子中，进行服务器端消息推送的技术通常被称为Reverse AJAX。您可能已经发现 Comet 是文字游戏，就像 Ajax 的对应物（都是家庭清洁工）。不过，对我们来说，好事是我们只需将我们的部分连接在一起，然后我们就可以走了。通用 AJAX 网络编码器将有更多的编程工作要做。（不过，即使是通用的网络应用程序也可以与 BlazeDS 一起使用 - 它对 BlazeDS 能够执行的 AMF 编组没有任何用处。）
最后，Adobe 和 SpringSource 正在合作建立 BlazeDS 与 Spring-Framework 的更顺畅、开箱即用的集成：
正如有人已经说过的，您所描述的基本上是发布者/订阅模型。这很容易使用 ESB 或消息队列来实现。我对 RabbitMQ 有一些经验。这很好。什么都不会丢失，它很好地处理了发布订阅模型。过去，我曾在小型系统上使用基于 http 的定制协议开发自己的消息代理。我不建议这样做，原因是当您开始开发它时，您会一直在思考如何扩展它的方法。
RabbitMQ 是用 Erlang 开发的，但它有 java、net、python 等客户端，可以很容易地连接到它。我用过 .net 和 python 客户端，效果很好。我选择它是因为 Erlang 在创建可以同时处理多件事情的可靠系统方面享有盛誉，非常好。我会称它们为线程，但我认为它比线程更智能，我想我记得 Actor 模型和邮箱的喃喃自语，我记得它们非常整洁。
我的处境与您相似，但在其他消息传递系统（Biztalk 等人）方面的经历非常糟糕，这些系统过于恰当，将您束缚在解决方案中。如果您可以将消息与传输和传递机制分开，那么您可以开发您的系统以满足您的需求。最后我使用了 JSON，因为数据包很小。你可以使用任何你喜欢的东西，有些选择 SOAP 消息，但我觉得这些对于大多数东西来说太重了，尽管它确实允许你很好地将 XSD 模式提供给外部人员，以便他们可以/可以开发与你的互操作的系统未来的系统。
http://www.rabbitmq.com/tutorials/tutorial-three-java.html，这是发布/订阅模型教程的链接，以及如何使用消息队列系统实现它。它适用于 rabbitMQ，但老实说，它可以与 ESB 和任何其他消息队列系统一起使用。
ESB（企业串行总线）- 当您的应用程序与两个或多个外部/单独的应用程序有很多交互时考虑这一点，其中每个应用程序都不会以相似的数据格式进行通信。例如：某些系统可能接受对象、XML、JSON、SMTP、TCP/IP、HTTP、HTTPS 等。
ESB 具有许多特性，例如：路由、寻址、消息传递样式、传输协议、服务消息传递模型。
如果生产者 - 消费者应用程序遵循相同类型的数据格式，请考虑队列系统。
如果一个应用程序需要另一个应用程序来完成工作流程，Web 服务（SOAP / REST）是最好的。如果应用程序需要异步数据传输，请使用队列。
您实际上是在谈论确保交付的发布和订阅。大多数 MOM 软件应该很容易支持您的用例。
正如前面已经说过的那样，在我看来，为您当前的情况使用 ESB 就像用锤子砸苍蝇一样。
ESB 软件本身会很耗时并且需要维护。如果您使用开源解决方案，它可能比使用许可解决方案（IBM、ORACLE 等）更耗时。
当然，ESB 可以完成这项工作，而且开发解决方案非常容易，但设置 ESB 比开发解决方案本身要困难得多。
如果您的问题仅限于所描述的情况，我强烈建议您在 OpenMQ（或类似的）上构建一个简单的架构，并通过 JMS 使用它