AMQP’s Coming Out Party

I was fortunate enough to participate in the AMQP working group’s 2009 Face-to-Face meeting at the University of California San Diego on April 1. I say fortunate for three reasons: first because it was nice to meet the really smart people that have been driving this exciting technology; second because it was great to be there for the public unveiling of version 1.0 of the specification; and third because San Diego’s weather is just a little nicer than my home town of Ottawa.

I’ll share my thoughts on the meeting and new specification below. As a quick aside, my favorite AMQP news of the week was that the working group formally approved Solace’s request for membership. We’re excited to join the group, and look forward to contributing to the development of the spec. Our goal is to bring to the table our expertise in hardware-based messaging and feedback from our own customers. Several of our customers are watching AMQP with great interest, and several have expressed interest in adopting it whenever it becomes stable and mature.

Perspective and Clarification Straight from the Source

Founding member and Chairman John O’Hara kicked off the meeting with an infectiously enthusiastic explanation of why AMQP came about and what he hopes it will achieve. To paraphrase and put it plainly, AMQP was born out of the frustration architects and developers everywhere have felt dealing with so many different proprietary middleware systems. The working group’s goal is to make AMQP the “Internet Protocol for Business Messaging” and eventually define what a MOM (Message Oriented Middleware) is.

One point to clarify: AMQP is not targeted only at the financial services industry – that’s just where the idea was born. Case in point, AMQP 1.0 was unveiled in front of a standing-room-only crowd full of people from many industries beyond financial services, notably multimedia, supercomputing, and telecommunications. When you have people talking about using AMQP for massive sensor networks and over satellite links, you know the applications are diverse!

Core Requirements and Tenets of AMQP

After John’s presentation, Mark Blair of Credit Suisse, explained the requirements of AMQP from the perspective of those will ultimately make use of the protocol.

• Ubiquitous and pervasive – it must be able to be supported by any programming language, operating system, application environment, something enabled by the definition of a wireline protocol.
• Safety – it must provide adequate security mechanisms such that it will be usable not just within organizations but between business entities.
• Fidelity – it must include well-stated messaging semantics so applications know what they are getting in terms of delivery guarantees
• Unified – it must support various messaging qualities of service (persistent/non-persistent) and message exchange patterns (pub/sub, request/reply) to address all business uses
• Interoperability – it must feature wireline interoperability between client and broker, as well as broker and broker, in a backward compatible manner
• Manageable – it must include integrated management capabilities.

What’s New with AMQP 1.0

Version 1.0 of the AMQP spec includes some major differences from the v0.10 that preceded it, so the focus of the meeting was explaining the new architectural model and the transfer protocol. Here’s a summary of a few changes that I found noteworthy.

• “Exchanges” and “bindings” have been replaced purely with “nodes” and “links”. The authors’ rationale is that this new representation is functionally the same but much simpler. Messages move from a node (which could be a queue, for example) along a link to another node according to the rules of the link. The link can then express routing and filtering requirements, durability, etc.
• Another significant change is the addition of global addressability (modeled after email addresses, i.e. RFC822) for use in communicating between autonomous systems
• Management and subscriptions – handled (how else?) by sending messages over AMQP to logical services that live inside the AMQP broker – they practice what they preach!

After a discussion that clearly could have gone on all day, an informal poll was taken as to whether the audience felt that the AMQP specification was heading in the right direction and would address users’ needs. The audience overwhelmingly agreed that it was.

I for one am very happy to see the increasing interest in a standardized wireline messaging protocol. Messaging is key to distributed applications and the lack of such a standard has hindered the proliferation of innovative new applications for too long. AMQP holds the potential to address wide set of use cases which will be very beneficial to the user community.