AMQP – the enchanted corner of SOA | Hacker News Reader

AMQP – the enchanted corner of SOA

blog.thestateofme.com

32 pointstimf13 comments

AMQP is real interesting. I like to think of it as "email for applications". It lets programs send "email" to each other.

You could do this using regular email, but regular email is hard to wire up to programs and isn't very flexible (eg. it's relatively hard to set up new email accounts).

With these messaging protocols, programs can just create channels for themselves and set up all sorts of interesting communications protocols -- eg. point to point, publish and subscribe, one to many etc. And it's (relatively) reliable so you know the message is going to get delivered.

We used to do that years and years ago on VMS, NETMBX it was called there.

Oh absolutely, I agree. Everything old is new again, including the 'new' fads of virtualization, superscalar and multicore processors, language VMs, cloud computing, RPC, etc.

That doesn't mean this isn't worth bringing to a larger audience.

FWIW, note STOMP as an alternative to AMQP. Apache ActiveMQ and JBoss HornetQ implement it.

I am a member of the AMQP Working Group and the OASIS AMQP Member Section. Last month we released the AMQP 1.0 protocol. This is something that we are really passionate about.

The one thing that has really held back the broad adoption of AMQP is the delay behind the release of the 1.0 version of the protocol. Now that we have this under our belt we need implementers such as RabbitMQ, StormMQ, Microsoft, INETCO etc to add support for AMQP 1.0. Finally, we need native AMQP clients installed by default and widely supported by OS and hardware developers, put simply, we need the full participation of the main operating system stack suppliers such as Microsoft and Redhat.

Luckily enough, both RedHat and Microsoft are members of the AMQP Working Group. I assume that they will release native clients and thus pave the way for broad adoption. It is the growth of pervasive AMQP clients and a strong and healthy developer community that will drive adoption and general acceptance of AMQP.

In what manner is HTTP "unreliable" that IIOP isn't?

I was wondering the complement. In what way is AMPQ more reliable than SMTP?

I don't understand any of those placements, author must have way different definitions than I.

I'll try to answer the grandparent.. But note that I don't really know this topic in great depth so hopefully people who know will jump in and point out my mistakes.

Firstly HTTP is unreliable because there is no guarantee that the website is up at any particular point in time. In other words you couldn't write a reliable program that depended on fetching data from a website because the website might be down when you requested it. You could try to wait and fetch the data later, but that would be effectively building another protocol on top of HTTP to make it more reliable. I have no idea about IIOP/CORBA but perhaps it added more reliability?

AMQP isn't completely reliable. I mean, if you send a message to an AMQP broker and it's committed, that just means it's saved to some presumably reliable resource, eg. to a harddisk. If a plane falls out of the sky and wipes out the broker, then it's not reliable. [You can, if you have enough time and money, set up AMQP so that it would be reliable even against aircraft incidents]

I don't think in this respect that AMQP is more reliable than SMTP. But it's a lot more convenient than SMTP for what it's designed for: ie. messaging for programs. Getting email out of and back into programs is a whole lot more complex than just setting up an AMQP binding.

"if you have enough time and money, set up AMQP so that it would be reliable even against aircraft incidents"

For example, as of RabbitMQ 2.6, there is active-active broker clustering: http://www.rabbitmq.com/ha.html

It's important to distinguish between reliability in the protocol and reliability in the implementation. Spending time and money to be reliable in the face of disasters like falling planes is about the implementation. An example of reliability at the protocol level is TCP vs. raw IP. IP routers will try to get your packets to their destinations, but they'll also happily discard them if that's more convenient. TCP adds some reliability - the other side will let you know if they didn't get everything.

The issue you bring up with HTTP is actually related to HTTP being synchronous rather than unreliable. If you wrote your program to fetch data by sending an email, it would probably work even if the SMTP server that had the data was down: your local SMTP server would store your message and forward it when the destination server came back up.

FWIW, AMQP is the preferred protocol of Celery, the python distributed task library; which we've been using it heavily for the past year at Crocodoc. I have nothing but praise for AMQP and RabbitMQ in particular in terms of performance or reliability.

Though nothing new, I see what they are trying to do: to bring enterprise messaging down to the masses.

Next year HN projects: Nxxxx.js, MxxxxxDB and RabbitMQ.

Reply on news.ycombinator.com