AMQP and one possible future for messaging

Yesterday I attended the AMQP working group's annual convention, and found this tight knitted group incredibly welcoming and quite informative. My off the cuff impression of the individuals involved was "if you are interested in Enterprise Queuing you probably attended a British university at some point". It isn't that surprising from a cultural perspective I suppose, but even I am guilty of that association. But what you can take away from that quip is this group gets queuing so much that AMQP isn't really a Queuing protocol at all, but a message routing and delivery protocol with wire level semantics.

If you are a typical web developer, you are accustomed to the challenge and response of HTTP's synchronous protocol. On a semantic level, we talk about statelessness of the protocol, and treat each connection as an individual transaction with session layering in the application on top. In reality, most HTTP requests are bidirectional stageful affairs running over a tcp session, with payload framing in HTTP, but with connection level framing handled by TCP. TCP itself piggybacks on UDP packets which provide the base link level of framing for individual packets, with IP defining the network layer routing. Ethernet in most cases these days provides the physical layer but you can tunnel IP over many different types of links.

AMQP runs on TCP/IP now, but is looking to change all that.

AMQP 1.0 is designed to be a wire level protocol, capable of being implemented in hardware, and routed globally over existing tcp/ip networks. This low level ambition is at the heart of why financial institutions such as banks and exchanges are so interested in this tech. Being able to define a secure from the ground up, implemented in hardware, open standard for networking that interoperates with the existing Internet but can be run bare metal inside a large corporate environment or private network for financial exchanges is huge. Forget about vendor lockin, with FIX, FAST, and SWIFT running over AMQP, you would finally have a network that is secure and reliable enough for massively distributed data brokering.

Matthew Arrott's work bringing AMQP to the field of global data gathering is particularly interesting to me. Applying this tech designed for managing trading infrastructures to control robots in the oceans around the globe, not only legitimizes to some degree my own work, but also shows how important AMQP in hardware could be to building effective swarms of automated vehicles, smartgrid management, and intelligence gathering. With a wire level secure network and a contract aware routing layer (Arrott's main aim) you could not only solve secure content distribution, but build in Asimov's 3 laws into the fabric of the network. The devil is in the details of the contract itself however, just ask Daniel Webster.

Personally I'm looking forward to driving the most interesting bit of the AMQP 1.0 environment which is the naming of things. The goal of AMQP is that anything with an address can recieve messages. That anything could be a machine, a network, an application, or an object. We have an opportunity to devise a naming scheme that will give every object in the entire world and network and the history thereof a true name. Once in place and discoverable, all one needs to do is send their message and AMQP will make sure it gets there. No matter where there is.

AMQP can become the Internet of things.