Some time ago I started a series of blog posts [1,2] on Ruby and messaging. Most of the series is still in draft format and has to be completed. It’s a topic I’ve been very interested for some time, and have monitored the space quite closely looking for new implementations and collecting presentations and links as I go along. I’ve been a fan of Jabber (XMPP) for some time now, but it has some smells, to me at least…
First, some background. I’m the chief utopian at a South African ISP, inX, and most of my current work focusses on finishing off the fourth generation of our flagship project ISP in a Box. ISP in a Box is essentially a Rails frontend to a variety of services we procure and reprovision to resellers, which in turn sell to their clients. Apart from coping with a lot of models and extremely complex business processes, we also have to cope with procuring and provisioning services.
In this post I’ll aim to give some insight into our provisioning processes, and more specifically how I plan to implement our hosting provisioning over the coming days.
We exclusively use the excellent ruote Worflow Engine by John Mettraux to drive our procurement/provisioning processes, instead of overly complex state machines. As part of this I’ve implemented a Jabber Participant/Listener pair of classes for ruote, allowing any part of the workflow to be shelled out to a Jabber bot for processing, and continuing the workflow when done. This has worked great so far, but the requirements of our hosting services are somewhat more. This made me sit down and think, and I announced today that I’ll be doing a “pen and paper” SWOT on XMPP, AMQP and REST. What I came up with, is not a textbook SWOT, but at least a look at AMQP from an XMPP point of view. And it was interesting indeed, so much so that I’ve made up my mind to move to AMQP from XMPP. Here’s what happened…
The smells of XMPP
For the record, I really love XMPP as a protocol and the possibilities made possible by it. I’ve written a good couple of clients, for fun and for serious production use at our company. In my mind, here is a “SWOT” on XMPP from someone who works with it frequently.
| Strengths | Weaknesses |
|---|---|
|
|
NOTE: I personally feel that most of the times we implement XMPP where we should be implementing a real queueing protocol. This holds especially true, if you like me, counts on ejabberd’s persisting of messages while the client is down.
For me personally the biggest smell in XMPP is the roster, at least for automated clients. This shows in other implementations too, Vertebra implemented a gatekeeper called Herault. I assume that with Herault in place you don’t care about roster management, and all bots will freely accept invitations from each other, and ask Herault whether the commands should be accepted or not. This is a perfectly sound plan, permitted your XMPP server is well secured and doesn’t allow inter-domain communications, ie you’re running inside a wall of trust.
The promised land of AMQP
I’m typing this without ever having written a single piece of AMQP code (be it producer or consumer). The “SWOT” below is what I’ve extracted from various online sources over the last couple of weeks, and especially today. I’ve got a number of requirements that needs to be fulfilled first:
- Peer to peer implementation of “bots” or “agents”
- Identity driven commands -> “Server 1: Create new site”, “Server 2: Suspend site”
- Unrestricted “bot” to “bot” communication
- File transfers (big files)
- No more roster management
Now the scary part is that all the above requirements can be fulfilled with XMPP. The implementation would smell however.
| Requirement | XMPP | AMQP |
|---|---|---|
| Peer to peer communication | Roster management (-1) | Unique named queues (+1) |
| Identity driven commands | Roster management (-1) | Unique named queues (+1) |
| File transfers | File transfer proxy configuration (-1) | Supported on the wire (+1) |
| No roster management | Implement copy of Vertebra’s Herault (-1) | Unique named queues (+1) |
I hope the table above shows how blurred the lines are, and how difficult it can be to make a decision between the two protocols. Below is my non-textbook “SWOT” of AMQP.
| Strengths | Weaknesses |
|---|---|
|
|
In Summary
Both protocols are great, and the differences are not obvious at first. XMPP is easily mistaken as a message queue, especially because of the “offline chat” features in Jabber daemons and the inherently “targetted messages”. AMQP supports all of this, and so much more, without the need for roster management or Heraults. The only thing that I’ll miss from XMPP is the presence features. All my bots currently “talk to me and members of our support team”. I’ll implement this in my AMQP producers/consumers irrespective.
XMPP is built for one-on-one communication, with “broadcasting” supported by a protocol extension called PubSub. AMQP inherently supports one-on-one and one-to-many communication through it’s clever message/exchange system.
Going forward, I’m starting with the excellent nanite project from Ezra. I’ll probably work on bringing AMQP comsumers/producers into ruote this week, as well as implementing a nanite actor/master combo for ruote as well.
A great and timely post on RubyInside higlights RabbitMQ and some presentations to watch.
Please chime in on the comments, admittedly I might have buttered up AMQP due to my recent excitement, but I have a “gut feeling” it will payoff better in the future than XMPP. XMPP still rocks, I’ve just been using it as the wrong tool for the job, and I fear others have done the same.