Comments on: To AMQP or to XMPP, that is the question

By: Kenneth Kalmer

Kenneth Kalmer — Sun, 13 Dec 2009 20:06:18 +0000

Love affair has persisted. AMQP is part of my everyday work and has really nestled itself quite deeply into my toolbox. I still have my eyes on XMPP though, libraries like Blather makes XMPP a dream to work with. But like the post stresses, best tool for the job.

By: Rj

Rj — Fri, 06 Nov 2009 11:40:55 +0000

So, how have you gone with AMQP? Has your love affair persisted or are you back with XMPP?

By: Driving Business Processes in Ruby | Open Sourcery

Driving Business Processes in Ruby | Open Sourcery — Mon, 06 Jul 2009 07:45:23 +0000

[...] tough, and the impact of the next decisions are even bigger. I recently tackled the issue of choosing between AMQP and XMPP (and I’m honestly still on the bench, even when I’m using both in production), and [...]

By: Stephen Paul Weber

Stephen Paul Weber — Tue, 05 May 2009 18:55:57 +0000

I think stpeter’s point was that you don’t even need a concept of friend requests in XMPP. You should be able to safely ignore those packets, or just in general not use them.

XMPP is a stateful messaging protocol that happens to be really good at IM… it is not IM specific (although some XEP’s are)

By: Kyle Schaffrick

Kyle Schaffrick — Fri, 01 May 2009 18:22:34 +0000

@Scott I think the secret sauce AMQP has that SMTP/NNTP lack is that the routing is configurable “on the wire,” in the sense that clients declare what exchanges, queues, and bindings they intend to use and how they relate to each other, as part of the ordinary course of using the broker’s services. These meta-level features are defined by the AMQP spec, both in protocol and semantics.

On the other hand, a message queueing system implemented in SMTP/NNTP would have to A) define these meta-level features in an ad-hoc way and then implement them itself, separately from or as an extension to the actual broker/MTA, or B) give up this dynamic configurability, in which case the broker would have to know a priori (via configuration) what the distribution patterns should be.

The fact that (for instance) RabbitMQ had essentially *no* static configuration files to edit (in stark contrast with most MTAs, to be sure) baffled me for a time until I realized that it worked this way. After some consideration, I believe it is one of the great strengths of AMQP’s approach.

By: jay

jay — Mon, 27 Apr 2009 23:23:53 +0000

Good thoughts, and good luck. I read this article yesterday that maybe helpful with AMQP. It’s python but I don’t think that should stall anyone;

http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/comment-page-19/#comment-2376

By: Scott Stults

Scott Stults — Sat, 25 Apr 2009 13:14:28 +0000

Whenever I see a new message queuing system, I always wonder why nobody chooses SMTP and NNTP. Those protocols have been around forever. They have solid, scalable implementations, support guaranteed delivery, and together support one-to-one and one-to-many transmission. The writers of SOAP realized this, but I’ve yet to see anyone use SMTP to deliver SOAP calls (and nobody wants to do SOAP nowadays anyway.)

That said, I agree that ruote and XMPP are excellent, and I look forward to seeing how your AMQP implementation works out.

By: John Mettraux

John Mettraux — Wed, 22 Apr 2009 01:33:29 +0000

@Chris

the MVC model is fine, but sometimes the ‘work’ can’t simply be contained in a request/response cycle (generating a big pdf for instance). Pushing the work towards workers via a queue and replying immediately (“we’re working on it”) is a common scenario.

Now a worker may be a workflow engine orchestrating more complex units of work among specialized workers (and it can leverage a queue system to communicate with those sub-workers).

Ilya wrote someting related at http://www.igvita.com/2009/04/06/henry-ford-event-driven-architecture/ worth a read.

Best regards,

By: Kenneth Kalmer

Kenneth Kalmer — Tue, 21 Apr 2009 08:39:56 +0000

@Pieter

Great input, thanks!

As far as I can tell nanite implements “presence”, I still have to dissect how they do it. I *assume* they use other queues where the agents push “pings” back to the “masters”… RestMS also looks promising, just gimme time to build up my AMQP skills from the ground up first

In my environment I just require the broker to persist messages until the consumer comes back up again, so on the short term it isn’t a problem. But I can conjure up a few scenarios where presence does become important.

As for “XMPP on top of AMQP”, I actually suggested to friend that they look into using a queuing protocol for building a “facebook chat” for another social network, instead of wrapping XMPP up in an overly complex BOSH/Comet scenario. This was several weeks ago, and now that you mention it, it might be a great way to implement chat…

By: Pieter Hintjens

Pieter Hintjens — Tue, 21 Apr 2009 08:15:54 +0000

@Kenneth,

A very interesting thread, the first I’ve seen that dissects the different ways XMPP and AMQP work. One of the keys to AMQP is precisely that a publisher does not know (or care) who is at the other end of the routing & queuing system. The recipients for a message are abstracted into an address (routing key, headers).

We’ve found in practice is that this works very nicely.

But there are some cases where presence matters. For example, when requesting a particular service, it’s important to know if the service is absent (i.e. no subscribers for that particular address). AMQP does this using the same hack as email does (“if the message cannot be routed, send it back to me”).

RestMS does it by equating a feed with a service, and letting clients test the presence / absence of a feed. Like AMQP, it hides recipients from senders behind an address abstraction.

I suspect that XMPP is actually a higher-level protocol, which if we rolled the clock back some years, might be implementable on top of a generic messaging protocol like AMQP or RestMS.