
AMQP – the enchanted corner of SOA - timf
http://blog.thestateofme.com/2011/09/18/amqp-the-enchanted-corner-of-soa/
======
rwmj
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.

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

~~~
rwmj
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.

------
Spoutingshite
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.

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

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

~~~
rwmj
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.

~~~
cwp
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.

------
mattlong
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.

------
democracy
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.

