Last month the AMQP working group, which includes big hitters such as Bank of America, Credit Suisse, JPMorgan Chase, Barclays, Goldman Sachs, Microsoft, Cisco, VMWare, Redhat, and Informatica finalised version 1.0 of the AMQP standard. It has been 5 years in the making, the market for messaging has changed a lot in that time.
What is AMQP?
“The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. The defining features of AMQP are message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability and security.” – Wikipedia
The specifications are available on-line and several broker implementations exist, like the popular RabbitMQ and Apache Qpid. AMQP is built around a few easy to grasp concepts:
- Clients connect via channels to AMQP brokers in order to send or receive messages,
- They can publish messages to exchanges, (now queues in the 1.0 spec)
- Messages published to exchanges a routed to destinations where they get accumulated for later consuming.
- The queue that will constitute the final destination of a message is not known by the message publisher: it is determined by the type of the exchange and a piece of meta information known as the “routing key”.
- It is possible for a message to end-up nowhere if no queue has been bound to the targeted exchange or if no routing rules haven’t matched any existing queue.
- There are four main types of exchanges: direct, fanout, topic and headers.
- Clients interested in consuming messages must create queues and link to exchanges.
- Queue and exchange declaration is an idempotent operation hence it is common practice to declare them on each client startup.
When I first saw the AMQP proposal I was pretty excited. I’m a messaging geek and the idea that messaging could break out of the WebsphereMQ/JMS chokehold was appealing. Like others, I saw AMQP had the potential to explode on the web into its own category much like MySQL did as the web app database. The web needs messaging, AMQP could be it.
The enchanted corner of SOA
Chris Swan draws an elegant quadrant of where AMQP fits in the grand landscape of protocols. We have been missing a credible player for the most important part of the quadrant if we want the web to become a a truly reliable platform: Async/ Reliable. We have been overcompensating with things like WS-Deathstar and all sorts of other layers on top of HTTP to mimic reliability, compensation and asynchronous communication. What was needed is a standard dedicated to delivering Async / Reliable.
First impression
When I looked at the first draft of the spec (I was a reviewer), I saw a massive improvement over the current offerings, cleaner interface and a much better architecture where the notion of exchanges we introduced (very similar to email servers). Exchanges meant that you could build less rigid architectures, federate destinations, and provide a much simpler client interface. The wire protocol approach meant that the servers and clients could be written in any language – very important if you want to achieve ubiquity.
Fast forward
Five years later, and the world has changed. The web grew up as a platform and there are now lots of solutions for messaging. While there is still a gap for for Reliable/Async, it may not be what many applications need. The newer kids on the block are Comet, PubNub, Pusher, MQTT, Amazon SQS, PubSubHubbub, and even data servers like Redis have messaging capabilities. For those following, most of these are publish-subscribe. Coming from the enterprise none of these have the quality of Service (QoS) that I have traditionally expected from messaging but all of them have a place on the web.
AMQP challenges
There are some challenges that AMQP must manage or overcome. The top being that the wire protocol is brittle, early adopters of AMQP brokers such as Rabbit or Apache QPid have battled with minor version bumps of the spec. The knock on effect is that managing clients of of these brokers is just painful because you are always tied to the lowest client version or risk breaking your clients. Finally, messaging is a concept that hasn’t really crossed over, this may be the biggest hurdle since many developers don’t think about messaging to decouple and scale their applications. As such the messaging standard to win on the web might well not be messaging but something like Redis with messaging capabilities, its not clear to me that messaging looks like messaging on the web. A good example of this is mobile notifications, I can see this style of messaging becoming the de facto with developers working within the confines of Apple Push or Android’s notification Service.
Land grab
The real potential for AMQP is queuing on the web, there hasn’t been a strong play for this yet but I believe queuing will become a fundamental part of orchestrating services on the web as applications start to decompose into different services. AMQP on the web will need to take lessons learned for content delivery and use CDNs to move data as close as possible to the recipient to reduce latency; security and federation could get messy.
From this point forward the AMQP protocol will need to remain backward compatible, without this promise it will be harder to achieve any kind of mass adoption. The HTTP protocol is a good example of stability, the AMQP working group need to follow suit.
Follow: @rossmason, @mulejockey
