Will the Ultra Messaging guys wake up AMQP?

Originated in 2003 by John O'Hara at JPMorgan Chase in London, the Advanced Message Queuing Protocol - which aims to be the wire-level standard specification for messaging interoperability (vs. API-level standardization like JMS) - is catching on rather slowly in the contemporary landscape.

To be honest, before yesterday I was very skeptical about the future of AMQP as a standard. Now, I'm still not enthusiastic, but a little bit less skeptical ;-) Reasons why:

With a version 1.0 less than more adopted by the various broker-based projects (see here for details), the new things for AMQP would probably come through a broker-less (and daemon-less) product: Informatica Ultra Messaging (a.k.a. IUM & formerly known as 29West).

Why a broker-less & daemon-less solution decided to implement AMQP?

Started few years from now as the fastest "low latency" messaging solution for finance, Ultra Messaging is now covering all the standard use cases of Message Oriented Messaging (MOM) year after year. Adding persistence, HA-support, load balancing (with stickiness!) and even once and once only guaranteed delivery.

From a "nothing in the middle" overall design approach allowing us to pick the transport we need on a per-use case basis (i.e. Reliable Multicast, Reliable Unicast, TCP, RDMA, IPC, SMX, ...), Ultra Messaging was familiar with the concept of adding components aside their peer-to-peers architecture. Not in the middle like we have in a broker-based architecture. A-side the critical path of the data distribution.

A full AMQP 1.0 solution

With its upcoming version 6.8 that will be release December 10th 2014, IUM will now support both a new AMQP transport, and a fully compliant AMQP 1.0 broker. That won't change the core & existing transports of Ultra Messaging, but simply provide a new feature (AMQP) if needed.

In fact, Ultra Messaging should deliver the first AMQP broker-based solution supporting High Availability (HA) with full automated fail-over mechanism.

No NIH syndrome

Initially started to work on their own queue-based architecture & component a few years from now (i.e.: UMQ), the Ultra Messaging guys were asked by their customers to support interoperability scenarii with existing market or open source solutions. You know, the kind of solutions already deployed for the guaranteed delivery use cases: TIBCO EMS, Apache ActiveMQ, IBM WebSphereMQ, Pivotal RabbitMQ, etc.

Instead of continuing to implement their own UMQ solution, the Informatica guys wisely decided to leverage on an existing one: Apache ActiveMQ, and to improve it. In fact they've forked it in order to provide the product expected by their customer (including HA). To do so, they have added a part that is currently missing in the AMQP space & standard: the broker-to-broker interactions.

At the end of the day, it's a nice occasion for the Ultra Messaging team:

1. To provide their customers a full HA compliant AMQP broker (relatively mature) solution
2. To provide their customers a new AMQP transport within the IUM toolset,allowing interoperability scenarii with other AMQP 1.0 brokers (for AMQP idealistic people?)
3. To contribute back to the Apache ActiveMQ project (with their pull requests)
4. To wake up the AMQP standardization initiative by suggesting something for the broker-to-broker interactions part

The truth about AMQP...

I would like to end this post with an anecdote. While I was in React Conf last April in London thanks to my Adaptive friends, I had the opportunity to dine with the speakers. During the last night, I was located right next to Peter Hintjens, creator of  ZeroMQ.

I had a few drinks that night (London, you know... ;-) but I can clearly remember Peter saying to me that AMQP was originally his idea... but also the trigger for him few months after, to create ZeroMQ (when he saw that AMQP was leaded into a political nest). Fortunately, I recently found this old post confirming that I wasn't drunk when Peter was explaining that to me. Extract:

"the AMQP spec which Red Hat read in 2007 was largely my invention: I dreamed up exchanges and bindings, hammered them into shape with my team and the guys at JPMorganChase, explained how they should work, explained how to extend AMQP with custom exchanges, wrote thousands of pages of design notes, RFCs, and diagrams that finally condensed — by my hand and over three years — into the AMQP spec that Red Hat read in 2007."

I never seen any mention to Peter's contribution within the AMQP site or standard, but I thought it was important here to Render unto Caesar the things that are Caesar's.