- Periodic Table of Realtime
- AMQP 1.0
Advanced Message Queuing Protocol (or AMQP, currently version 1.0) is a messaging protocol created at JP Morgan Chase to directly address business requirements of efficient exchange of information within and between enterprises. From the start it was meant to be interoperable, and an open standard among organizations, platforms, operating systems, and various broker implementations. RabbitMQ is a message broker written in Erlang that originally sprang from version 0-9-0. With time, a working group composed of major technology vendors and user firms came together to enshrine the ideas behind AMQP into an official ISO standard (19464), called version 1.0.
This “version” is a misnomer of sorts: it ultimately became an entirely distinct protocol addressing different needs than 0-9-0 and subsequent 0-9-1. While RabbitMQ happily continues employing the ubiquitous 0-9-1 protocol, Microsoft Azure Service Bus is an example of a real-world implementation of 1.0. This introduction is a basic overview of AMQP 1.0 (ISO 19464). See our Intro to AMQP 0-9-1 to read more about the other protocol.
The AMQP standard provides guidance for building cross-platform apps using heterogenous brokers, libraries, and frameworks, all vendor-independent. Part of the concept is the message being a "unit of work", placing business interactions above technical details. AMQP primarily targets message-oriented middleware to help exchange unambiguous, reliable, asynchronous messages between applications. Features include:
Efficiency — a binary, connection-oriented protocol (on the wire)
Reliability — includes settlement (acknowledgement) of delivery
Portable data representation — a cross-platform message encoding standard
Flexibility — various topologies, from peer-peer to client-broker and broker-broker
Broker-model independence — does not mandate brokers' internal implementations
Scalability — designed for scale by working group of large enterprises
Future-proofing — long-lived information-processing ISO standard positioned as springboard for other ISO standards
AMQP is conceived with autonomous computing, cloud portability, and a secure IoT in mind, based on the idea that messaging is a more general idiom than the invocation of object methods, and thus should exist under the transport layer, not on top of it. The standard includes queuing, routing (both p2p and pub/sub), QoS and delivery guarantees. It also supports for SASL/TLS to offer secure transport (SASL/TLS) to value-bearing messages among organizations, platforms, and cloud services.
The protocol is vendor- and platform-agnostic, eliminating vendor lock-in. It defines message formatting rather than mandating specific application behavior. That is, instead of defining functions and creating libraries, it focuses instead on the definition of the byte sequences sent across the network.
Definition vs. implementation
AMQP is meant to exist as a complementary technology to HTTP, with the latter devoted to request/response, and the former to pub/sub and transactions. In that sense, AMQP could be thought of as HTTP for middleware — not a software product per se, but a general, broadly applicable protocol definition — with the implementation left up to others.
Comparison table of AMQP and HTTP features.
AMQP is a superset of the semantics needed to implement APIs like JMS (the de-facto Java API standard for store-and-forward and pub-sub messaging), as well as any other such implementations in any other language on any OS and on any platform. By design, any AMQP-compliant implementation can talk to any other, with support for the following core messaging patterns:
asynchronous directed messaging
store and forward
The original motivation behind the creation of AMQP was to resolve several common financial system messaging issues, but it has much broader messaging middleware applicability. The 1.0 spec consists of the following layer of functionalities useful in autonomous/IoT/cloud computing domains:
system of typed data with annotations
protocol for symmetric but asynchronous message transport between two processes on the network
message format that allows for extended metadata and encoding
a standardized but extensible set of messaging capabilities, such as grouping interactions into atomic transactions
definition of security layers
AMQP can easily integrate into this example technology stack:
Service resolution: DNS
Connectivity: TCP and SCTP
Encrypted transport: TLS
Directory and authorization: LDAP
Reliable messaging and routing: AMQP 1.0
Data interchange format: XML
Commercial financial languages: FPML, FIXML, XBRL
Positioning: local intranet and at-scale internet
The history of WebSockets
Learn how WebSocket came to be, and how it's an improvement on earlier HTTP-based techniques for delivering realtime apps.
What is WebSocket?
We cover the WebSocket protocol and API, how WebSockets work, WebSocket use cases, pros and cons, WebSocket alternatives, WebSocket scalability, and more.
Scaling realtime apps with Golang and WebSockets
Learn how to build dependable realtime apps that scale with Golang and WebSockets, and the associated engineering challenges.