"What is AMQP and should I be interested in it?"
Back in October, Microsoft released a press statement announcing that it was joining the "Advanced Message Queuing Protocol Working Group" (an organisation focused on the development of the AMQP specification) at the request of some of its members.
AMQP is a specification for platform-neutral, open standards-based business messaging. Such a specification would, of course, be very useful for a lot of customers - probably in a similar way to how the standardisation on TCP/IP has made networking so much easier. Currently, having to integrate between MSMQ and WebSphere MQ (just for two examples) can be painful for customers and an unnecessary cost too. It will be interesting to see what messaging standard comes out of the group and what it means for existing products on the market.
Bryan Che's blog is very positive about the addition of Microsoft. He goes on to say that "Microsoft is bringing AMQP support to Windows and its ecosystem" and has made a "decision to integrate AMQP into its platforms". This does sound very enthusasitic, maybe too much so, as I can't find any public statement from Microsoft that says anything beyond group membership. I suppose all we can do is "stay tuned".
Looking at the AMQP Working Group membership [[as of 30th November, 2009]] is quite revealing:
Financial sector
Bank of America
Barclays Bank
Credit Suisse
Deutsche Börse Systems
Goldman Sachs
JPMorgan Chase Bank & Co.
Enterprise Linux companies
Messaging companies
29West Inc. (Ultra Messaging, high-performance messaging for financial markets)
Envoy Technologies Inc. (Envoy MQ)
iMatix Corporation (OpenAMQ - first production implementation of the Advanced Message Queueing Protocol (AMQP))
Microsoft Corporation (MSMQ)
Rabbit Technologies (Rabbit MQ)
Solace Systems (hardware-based messaging)
Tervela (hardware-based messaging)
Networking companies
Standards Group
Open source / integration
So no Tibco or IBM representation currently. Jeff Gould has an interesting series of articles titled "Can AMQP break IBM's MOM monopoly?" (MOM meaning "message oriented middleware") which you can read here: Part 1; Part 2; Part 3.
Comments
Anonymous
November 29, 2009
And one tiny detail that really rocks the casbah: since the Mono project finally got an implementation of the System.Messaging namespace that is based on AMQP (e.g. with RabbitMQ), one could dream of applications that talk to each other e.g. from Windows to Mac OSX - using exactly the same .NET code base! If this only came true... [[[sigh]]]Anonymous
November 29, 2009
Hi That's an interesting point. I see that earlier this year (2009), Microsoft put the ECMA 334 (C# Language Specification) and ECMA 335 (Common Language Infrastructure) specifications under their Community Promise. Will have to wait and see what comes up. Cheers John Breakwell (MSFT)Anonymous
December 08, 2009
Hi Hans, I passed your comment to my colleagues in the product group and they provided some feedback: "Microsoft’s implementation of System.Messaging uses MSMQ underneath and is not going to be able to talk to any program which doesn’t use MSMQ. The transport is not selectable like it is with WCF. If somebody ports that chunk of Mono to Windows, and RabbitMQ as well, then it could work. Unfortunately, the AMQP implementation which Microsoft is participating in is Qpid, not RabbitMQ. There is no standard native client API for AMQP, so whatever Mono is doing to interface with RabbitMQ isn’t going to work with Qpid." Reference for Microsoft and Qpid: http://port25.technet.com/archive/2008/11/07/finally-dive-into-the-deep-participation.aspx Cheers John Breakwell (MSFT)Anonymous
February 16, 2010
"There is no standard native client API for AMQP, so whatever Mono is doing to interface with RabbitMQ isn’t going to work with Qpid." That's like saying there is no standard API for HTTP and so .NET won't be able to talk to a Linux web server. It's completely inaccurate. AMQP is a wire level protocol specification (like HTTP), unlike JMS which is an API specification. You can use whatever API you want to talk to AMQP and it will interop with any other AMQP implementation that supports the same version of the protocol. When AMQP hits 1.0 in early 2010, the wire protocol should be backwards compatible, further reducing the need to worry about version differences(http://www.amqp.org/confluence/display/AMQP/AMQP+1-0+Business+Requirements).Anonymous
February 16, 2010
Hi Jesse, I had a chat to my colleague and he has responded as follows: "AMQP is a protocol, as is HTTP. Once you have AMQP packets on the wire, all implementations should be interoperable, but getting there is the trick. If the Mono implementation of System.Messaging is implementing client-side AMQP itself, then it should interoperate any other AMQP implementation. However, the AMQP spec does not specify any API in any language, so if the Mono implementation is relying on the client-side DLLs from an existing AMQP implementations, such as Qpid or RabbitMQ, that’s not going to work unless you have the one it is expecting installed on the client. That is the API I was thinking of when I wrote the previous response, but failed to express clearly enough." Does that help clarify? Cheers John Breakwell (MSFT)Anonymous
February 16, 2010
Mono does build on top of RabbitMQ, but this statement still is wrong. You don't need a special client installed on the machine. Mono does build on top of RabbitMQ, but that's just another assembly you need to have in your folder (or GAC'd), not a full blown client. There is a service similar to the MSMQ service that you will usually have running when you are using AMQP. However, there is no coupling between the client DLL that is sending messages and the service that you install on the machine. For instance, you could add a reference to the RabbitMQ dll and then talk directly to the OpenAMQ service... or, you could talk directly to a service running on a remote machine without needed to install anything on the client.