Slashdot Mirror
Microsoft Embraces AMQP Open Middleware Standard
AlexGr writes to tell us that Microsoft apparently has plans to embrace a little known messaging standard called AMQP (Advanced Message Queuing Protocol). Red Hat, a founding member of the AMQP working group, was very excited about the news and wrote to welcome Microsoft to the party. "Suffice it is to say that AMQP is to high-value, reliable business messaging what SMTP is to e-mail. The proprietary message oriented middleware (MOM) products on the market today like IBM's MQ or Tibco's Rendezvous fulfill the same function as AMQP. But they operate exclusively in single-vendor fashion and utterly fail to interoperate with each other. They are also — perhaps not by coincidence — burdensomely expensive. As a result their use is mostly limited to wealthy organizations such as Wall Street banks (at least the ones who are still in business) that need to exchange huge volumes of business messages very reliably and very quickly. But AMQP's supporters feel the market for such reliable messaging could be much larger if a less expensive and truly open solution became available."
Hmm.. Microsoft Embracing a new technology... I wonder what their two next steps are.
<IT-EXECUTIVE>
Silly. Microsoft's is the standard implementation. All those other people are incompatible with Microsoft, not the other way around.
</IT-EXECUTIVE>
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
I try to dissuade the use of JMS (Java Message Service) and use XMPP instead.
Why? JMS is just an API. This is sort of like protesting against POSIX or something. JMS implementations can be open source, commercial, free, expensive, whatever. I'm not sure I see your point, especially since messaging is not a core part of your app, and any sizable business will have an investment in a messaging platform already, in the form of tools, monitoring, expertise, etc.
Is this more of a competitor to the JMS spec, since it "reliable"? (whatever that means)
If you don't know what reliable messaging is, maybe you shouldn't be offering your advice?
While XMPP and AMQP do have some similarities, they were developed to solve quite different problems.
XMPP is better for human-to-human or human-to-machine interaction. It is better for federated networks (user@jabber.someserver.com can communicate with user@jabber.someotherserver.com). It has authentication built in. It's more "Internet ready", with modules for BOSH and IRC.
AMQP is geared more towards traditional machine-to-machine message queuing. It offers more control over the type of message delivery ("exactly once", "pubsub", "at least once"). It's aiming to just be a message queue.
RabbitMQ is an open-source implementation of AMQP built in Erlang. They seem to be quite fond of XMPP, realizing the different natures of the protocols, and even created a module for ejabberd (also written in Erlang).
Another interesting mashup between RabbitMQ and ejabberd is is a project I stumbled across called Rabbiter, which looks like some sort of implementation of a Twitter-link setup. They're looking to bring CouchDB (also Erlang) in the mix for persistence.
I'm expecting to see quite a bit of interaction between RabbitMQ, ejabberd, and CouchDB over the next few months.
Ruby AMQP Client
Python AMQP Client
Performance wise, XMPP bills itself as high performance messaging, but the developers are focused on the WAN. AMQP comparatively is ultra-high performance messaging with optimisations for the LAN.
This is confusing as for many projects there is limited need for ultra-high performance data rates. Numbers of the range 100,000 messages per second with latency under one millisecond. At this rate special engineering methods are required, XML, SSL, compression are too slow, focus is upon zero-copy processing, i.e. accessing and updating data in place, because the memory-bus is too slow to perform copies.
There is a discussion between one AMQP and one XMPP developer that sums this up:
http://www.mail-archive.com/jdev@jabber.org/msg19403.html
Another major advantage for AMQP is message routing. You can define which messages are routed to different sites by their content. Again this is an unusual requirement for many projects as they do not exist on such a scale for this to normally be an issue. The closest equivalent is SMTP routing by domain, you can find more discussion on this InfoQ article:
http://www.infoq.com/news/2008/08/amqp-progress
The main focus on AMQP is to appear a qualified messaging protocol for certified or guaranteed messaging with the necessary tools and support from vendors to promote its usage. XMPP can do a lot of the AMQP functionality already, but most of it is optional functionality rather than a primary design goal. If AMQP support appears in the Visual Studio Development System together with MMC modules for monitoring and administration, for example, its adoption could rapidly grow.