Looking at AMQP

If you spend a large part of your day reading and writing XML-related specs and artifacts, what do you do in the evening for a change? You read a non-XML spec. That’s what I did tonight, with the newly-released AMQP specification.

The clear aim of AMQP is to open up and commoditize the message queuing middleware space. Some customers in the financial services industry and smaller software vendors are fed up with, respectively, IBM/Tibco fees and IBM/Tibco market dominance. And this is how they plan to bring change. Definitely something to watch. And not just if you’re in banking, many other domains have demanding messaging needs, including IT management. So they have my attention.

I am not a messaging guru, so my comments are not about the core content of the spec (it seems very well thought-through though) but mostly around the interconnection between this spec and the domain I focus on. Basically, how this would fit in the landscape of standards-based management integration for increased automation and flexibility.

So how would this map to WS-Eventing, which is the basis for the eventing part of the ongoing Web services management convergence? To a large extent, they are orthogonal and complementary. WS-Eventing is about creating and managing subscriptions, not how the notifications get delivered. As long as you can create an EPR that indicates that AMQP is the delivery mechanism, WS-Eventing will be ok with that protocol. And conversely, AMQP has limited support for the function of subscribing. The closest thing is the ability, defined by AMQP, for a consumer application to create message queues and then to pass bindings to the server to drive messages into these queues. But in AMQP there is no concept of notifying the publisher application that there is now interest from a consumer for some type of message. So, in the general case, a mapping of a WS-Eventing subscribe call to AMQP would require two steps, one to create the appropriate queue and binding on the server and another (if applicable to the system), to notify (through a mechanism not specified by AMQP) the publisher application that there is interest for a specific type of messages. In some systems the publisher app always sends the same notifications and lets the messaging infrastructure deal with dropping those that no-one cares to get. But in other use case (including some in the management space), the system that plays the role of publisher application is able to vary the amount of notification it sends depending on its configuration. This is not addressed by AMQP.

Another interesting aspect is to look at how something like WS-Topics can be used with AMQP. AMQP does have a built-in “Topic” exchange type just for this. But it specifies that “the routing key used for a topic exchange MUST consist of words delimited by dots. Each word may contain the letters A-Z and a-z and digits 0-9”. This wouldn’t allow a direct mapping from WS-Topics since the topics in WS-Topics are XML elements, therefore their names are of type NCName, which includes the “dot” character.

What I find more puzzling is the claim (not in the spec but in the announcement) that “The AMQProtocol can be used with most of the current messaging and Web Service Specifications such as JMS, SOAP, WS-Security, WS-Transactions, and many more, complimenting (sic) the existing work in the industry.” I can easily see how AMQP can be used with JMS and as I described above it can also be used with the WS specs that manage subscriptions. But I don’t understand how it relates to things like WS-Security and WS-Transaction. AMQP defines a binary protocol that doesn’t conform to the SOAP model, so how does it compose with SOAP-based specifications? This is especially important because AMQP is very light on security. And when it comes to transactionality and reliability it just says that “there are no confirmations in AMQP. Success is silent, and failure is noisy. When applications need explicit tracking of success and failure, they should use transactions.” And leaves it at that.

The AMQP announcement is covered in this eWeek story. BTW, unless he is quoted out of context ZapThink’s Jason Bloomberg seems to miss the point when he compares AMQP with JMS and its “vendor-specific implementations”. The fact that JMS is not a on-the-wire protocol and has therefore vendor-specific implementations is actually the very reason why something like AMQP is needed. AMQP asserts that the protocol can be mapped to JMS and indeed I didn’t see anything in the spec that would prevent this from being true.

I also wonder if it’s for the irony or as a Freudian slip that the topic example they use in the spec happens to be STOCK.USD.IBM.

[UPDATED 2008/10/27: Microsoft announced that they will join the group.]

[UPDATED 2009/3/17: There is some debate around RedHat patents related to AMQP. Kirk is not happy. Matt is not worried. RedHat says it’s pure.]