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.
How will Microsoft's version be incompatible with the others?
Lacking <sarcasm> tags,
While "MS Embraces $STANDARD" is certainly rather unusual news(rather, instances of "MS Embraces $STANDARD" that aren't immediately followed by "and Extends" are), I'm not sure that this is actually a big strategic change for MS.
For a while now, MS has been the big, bad, expensive monopolist, with *nix and FOSS the freedom loving underdogs; but it should be remembered that MS was once the scrappy, cheap alternative to Big Blue and the proprietary Unix club. In most areas that has changed, since MS has largely taken over and started to tighten the screws; but I suspect that crazy expensive corporate middleware is a fairly conservative market.
This looks more like an alliance of the cheapish, freeish underdogs against the old school proprietary iron guys rather than a change of heart at MS.
This is the first that I've heard of this technology. Can anyone post how this is different than XMPP (http://xmpp.org)? XMPP is the updated name of the Jabber protocol.
I know that every project that I get on, I try to dissuade the use of JMS (Java Message Service) and use XMPP instead. Is this more of a competitor to the JMS spec, since it "reliable"? (whatever that means)
I can't even remember it's name, although it's installed here somewhere.
The IBM MQ product is actually OK to use (very simple, lots of platforms supported) and especially double plus good if you have an IBM mainframe somewhere on your network.
TIBCO? Shudder. About three quarters of the money they charge goes towards getting your manager drunk enough to sign the purchase order. The product itself isn't worth a damn.
Perhaps they feel that Microsoft brings recognition to a technology that RedHat is poised to exploit in their products. RedHat is only too happy to compete with Microsoft on an even playing field.
Because most competent middlewares supports transaction handling, synchronous and asynchronous, triggering, queueing and prioritizing of messages.
SOAP and XMLRPC doesn't really cut it when you need proper transaction based messaging. I've seen some bastard solutions for this but they perform poorly.
--- Reality doesn't care about your opinions, it happens anyway and if you are in the way you'll get squished.
Middleware solutions also come with tools for monitoring, configuring, etc., that simpler solutions often do not. This being said, I've had my fair share of problems with middleware in the past. Like any complex piece of software, you get a lot of functionality, but you also get a lot of baggage and hidden pitfalls that can come back to bite you when your usage of that functionality becomes demanding.
Suffice it is to say that AMQP is to high-value, reliable business messaging what SMTP is to e-mail.
So it sort-of works but it's 30 years out of date and every man and his dog has a different opinion as to how to fix its gaping flaws?
Ok, I'll try.
.NET?) of the other application.
Let's imagine that your organization uses a few different applications. For example a core banking, a loan management, credit card management, call center, billing etc..
Now let's say that you would like to be able to do "fun" stuff when something "cool" happens in one of those applications. For example, when someone default on a loan payment you'd like the core banking to flag the account as "dangerous", block his credit card, cancel his vip status in the CRM, the call center will generate an automated call to connect you to a customer service rep from the debt collection department that will menace you with the word foreclosure.
The first way to do that is to create many one-to-one relationship between all those application. "onpaymentdefaultduedate" in the loan management you could call successively each API of each application to "make it" do whatever it is that needs to be done. So the loan management will need to know about the crm, the call center, the billing etc...
Problem is that the next time you add a fancy new application (SMS harassment gateway for example) or upgrade an existing one (API change yeah!) you'll need to upgrade all the applications that have a one-one relationship. Which mean bringing on board the vendors of each and every applications for top dollars. Plus after a few years, everyone will have forgotten how the things even works. The vendor does not provide version 2 customization and you'll have to upgrade everything to version 7.3.56 and retrain your staff because the interface has changed and you can't expect the tellers to figure it out by themselves.
The second option is to add a middleware that will "sit" in the middle of all your other application (hence "middleware") and connect all the applications together using a publisher/subscriber model.
In that architecture, the loan application does not know about any other application than the MQ. Whenever you start defaulting it will simply send a message ("loandefaulted userid=12 amount=345.5") to the message queue and the MQ will in turn dispatch it to whatever other applications has register an interest for it by saying something like "subscribe to event loandefaulted from loanapplication". Many applications can register to the same event. That way the CRM can flag you, the call center can call you, legal can sue you and the SMS reminder volley can begin. All of that without any applications having to care about the brand or specific implementation (J2EE or
Of course this is a bit simplistic but cover 80% of the purpose of an MQ: loose coupling of application via an event based mechanism. Add to that option such as guaranteed reliability, prioritization of message, security and more complexe workflow of messages with multiple "queries" and "answers" and maybe you'll get a rough idea of why a MQ is a better design that "hard coupling" of n-application (sometime).
Of course since once you've chosen a MQ and adapted all your applications to use it you're basically tied forever and ever to your MQ vendor who hold you by the balls and can continuously rape you over and over with astronomical maintenance fee since you now have a single coordinated point of failure that can and will eventually take everything down at some point.
But hey, you're a big bank you can take it.. or at least you could until a month ago but whatever...
Clearer?
Odd this came up just at this moment, though it's hardly little known.
Implementations:
Several here: http://jira.amqp.org/confluence/display/AMQP/AMQP+Products
Matt
Here's a real-world application for AMQP.
Let's say there are two banks, BA and WTF. Every day they have debits and credits flying back and forth.
A protocol like AMQP makes exchanging messages (aka transaction) robust. Bank's IT guy gets mad and pulls the T1 out the wall at BA? Messages do a few things like wait in a queue at BA.
The messages that were sent to WTF before the cable was pulled were processed by WTF and wait in a queue at WTF unti BA comes back online.
That's a simple example. There is lots of information outside of the banking world where robust messaging is required.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
Speaking of standards...
We should establish, as a standard, an enumerated list of the half-dozen or so stock Microsoft whinges that end up as eighty percent or so of the comments to any article that mentions Microsoft.
Instead of typing it fresh each time, or pasting it from a previous message, the poster could just invoke e.g. "#3", instead of "Microsoft will Embrace, Extend, Extinguish" and all its semantic equivalents.
Better yet, since the list will be pretty short, the Slashdot UI could be modified to include a drop-down list of the standard whinges with any article that includes the Microsoft name. Select a whinge, and Slashdot automatically posts a comment for you (correctly spelled). What could be simpler?
The aggregate time savings would be a major boon to the American economy.
I'm a Programmer. That's one level above Software Engineer and one level below Engineer.
Goodness me...
.., and including .NET WCF and C#.
I work on RabbitMQ which is a messaging implementation that provides AMQP and other patterns. I hope my comment here can clear up some misunderstandings in the community.
Here is an introduction to AMQP from the RabbitMQ team - there are two presentations and a video - made at Google a few weeks ago: http://google-ukdev.blogspot.com/2008/09/rabbitmq-tech-talk-at-google-london.html
People who are wondering why AMQP is important compared to MQ, JMS, or whatever, should check out the first presentation. The second presentation includes information about XMPP vs AMQP. The two protocols are strongly complementary and are not alternatives. You can use these today: RabbitMQ as someone mentioned above has clients in lots of languages like Java, Ruby, Python,
Integration with Visual Studio has been done: http://www.rabbitmq.com/dotnet.html
As someone else pointed out there are protocol adaptors including STOMP and XMPP: http://www.lshift.net/blog/2008/07/01/rabbitmq-xmpp-gateway-released
It is open source - we welcome questions on the mailing list which you can find linked to from the home page: http://www.rabbitmq.com/
Cheers,
alexis