消息传递，队列和ESB-我知道我想去哪里，但不知道如何到达那里 [英] Messaging, Queues and ESB's - I know where I want to be but not how to get there

问题描述

总而言之，我正在一个项目中，出于所有通常的原因，我们正在重写一个大型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.

好，这就是我想要的:

我希望HTTP是主要的运输机制.当一个应用程序(例如CMS)已更新时，它将通过http与经纪人联系并说 "I've changed" ，然后经纪人将发回 200 OK 说 "thanks I got the message" .

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，

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是一个较弱的选择，因为它在服务器端不受很好的支持，尽管能够与您的经纪人进行即时通讯很有趣:)

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风格的界面，并具有与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-我知道我想去哪里，但不知道如何到达那里的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！