A Chat with Alexis Richardson about AMQP and RabbitMQ

By Jeff Gould, CEO & Director of Research, Peerstone Research

In this three part series I discuss the emerging open source standard for business messaging, AMQP (Advanced Message Queuing Protocol). Part 1 provided a non-technical introduction to the basic ideas behind the protocol. In Parts 2 and 3, I chat with two leading AMQP developers, Carl Trieloff of Red Hat (Part 2) and Alexis Richardson of RabbitMQ (Part 3).

In addition to being one of the developers of the innovative RabbitMQ implementation of AMQP, Alexis Richardson is also the co-founder of U.S. cloud computing company CohesiveFT.

Interview

Q: Who is going to use AMQP?

A: The market opportunity for AMQP goes way beyond IBM MQ and Tibco Rendezvous. It has the potential to become a ubiquitous Internet protocol that delivers trustable business messaging [for a recent presentation by Richardson on the technology and market potential of AMQP, see this]. Now, what do I mean by business messaging? I mean everything that HTTP and SMTP do badly at present. In a business network you need trust, you need transactional integrity. What goes in has to be the same thing that comes out. You need smart routing and multiple topologies, you need to be able to manage traffic flows and do server-to-server federation. And you need complete interoperability between vendors and implementations. All this is what it takes to do transactional business messaging, and this is what AMQP delivers.

Q: How will AMQP play with ESBs and SOA?

A: AMQP plays very well with ESBs as a transport mechanism. Take the Mule open source ESB for example. There are a lot of Mule users who use IBM MQ as the transport. But there are some smart Mule users who are using RabbitMQ instead. Rabbit is an extremely stable implementation of AMQP, it’s interoperable with other implementations of AMQP such as Apache Qpid, and it’s much cheaper than IBM MQ. Mule talks to the RabbitMQ server using our Mule adapter and Java client. But on the other side you can perfectly well have a .Net client. We have a WCF [Windows Communication Foundation] integration financed by a bank that is using AMQP. This WCF client also interoperates with all the other major AMQP implementations. When you’re working with ESBs and SOA you really need stable interop, it’s an indispensable piece of business messaging and integration.

Q: Why did you choose to implement RabbitMQ on the Ericsson OTP platform?

A: OTP stands for Open Telecom Platform, which was originally developed by Ericsson and has been open sourced. It’s basically a very robust carrier grade platform with a development environment using the Erlang programming language. It has lots of sophisticated management features built in and is extremely scalable.

Q: Who is using RabbitMQ?

A: Of all the AMQP implementations RabbitMQ currently has the largest number of use cases and clients. We have 10 to 15 users in production. We have customers in the financial community, but we have also been very successful with users who are building highly scalable web applications. We even have people who are using it in embedded applications. For example, the National Science Foundation's Ocean Observatory Initiative is using Rabbit to gather data from a global network of sensor networks. We have RabbitMQ users who are building their apps in all kinds of languages, Java, C#, Python, Ruby, Ajax [JavaScript over HTTP], and Adobe Flex. Rabbit also works with other popular messaging protocols, like Stomp, SMTP and XMPP.

Q: Is AMQP going to be a serious threat to IBM or Tibco?

A: Fundamentally we think AMQP will help IBM and Tibco grow the messaging market. The reality is that messaging hasn’t grown much in the past five years. Products like MQ and Rendezvous are extremely expensive to deploy, you need loads of consultants. The failure of messaging to grow out of its expensive high-end MOM niche has created demand for ESBs. The problem is that these ESBs like Mule and so on still need a reliable message transport mechanism underneath, but the customers don’t want to pay for IBM MQ or Tibco. AMQP can add value to the proprietary MOMs by taking messaging where it hasn’t reached before. It can do the lightweight use cases and the web applications where the heavyweights don’t fly so well. AMQP works out of the box, it is very scalable, and it gives you the interoperability that IBM and Tibco don’t have.

Q: What is the relationship between AMQP and Web Services ReliableMessaging (WS-RM)?

A : WS-RM uses a different model for messaging. It doesn’t have queues. But I think it could work very well with AMQP. It’s worth pointing out that Paul Fremantle, who is the chair of the WS-RM committee at Oasis, has joined the AMQP working group.

Q: What is the relationship between AMQP and JMS?

A: AMQP has been designed to work with JMS semantics. But JMS tries to deliver portability via an API, while AMQP does it with a protocol. There is a big difference between those two. History shows that protocols do a better job of enabling multiplatform interoperability. In the long run they win out over the purely API-based approaches. Just look at the famous examples of protocols that have done this: SMTP, HTTP, TCP. AMQP is going to do the same thing for business messaging interop, which means it will drive a significant reduction in costs. Of course JMS is great for Java, but what about everybody else? Rabbit delivers messaging across multiple languages and platforms, and has extremely simple APIs. For example, there’s a really interesting AMQP client implementation for Ruby.