Welcome from AMQP

Welcome to ØMQ for AMQP users

If you've been using AMQP/0.8 or AMQP/0.9.1, here is a short guide to help you understand ØMQ.

We'll summarize the two technologies and mark the essential differences as we go along.

Gross Generalizations

To paraphrase James Dennis, ØMQ is like Git (essentially distributed) whereas AMQP is like SVN (essentially centralized). Often, AMQP provides pre-packaged solutions to common problems whereas ØMQ provides tools that let you solve these problems easily in user-space. Thus AMQP solutions tend towards one-size-fits-all whereas ØMQ solutions tend towards roll-your-own.

Nature

AMQP is a family of messaging protocols, while ØMQ is a library of messaging functionality. You do not use AMQP directly but rather download and use a specific AMQP implementation such as OpenAMQ or RabbitMQ.

Theoretical Basis

AMQP is roughly an evolution of semantics taken from the Java Messaging Service (JMS). This itself was based on long experience of enterprise messaging (topic-based publish-subscribe, and persistent queues). The theoretical basis of AMQP is described in Background to AMQP by Pieter Hintjens.

ØMQ is a ground-up redesign of messaging based on specific principles of uniformity, scalability, and interjection, and inspired by the Internet Protocol (IP). The theoretical basis of ØMQ is described in ØMQ: The Theoretical Foundation by Martin Sústrik.

AMQP and ØMQ have quite different goals. AMQP aims to commoditize existing enterprise messaging patterns, while ØMQ aims to create messaging patterns that can succeed at Internet scale.

Use Cases

AMQP aims to solve the problem of how to connect some dozens of pieces doing perhaps a hundred thousand messages per second, in total. It covers two main use cases: transient pubsub distribution and reliable request-reply. As a broker-based product it emphasizes messaging as a first-class entity on the network. Applications using AMQP are architected around the broker. It competes with JMS, WebSphere MQ, and similar.

ØMQ aims to solve the problem of how to connect hundreds or thousands of pieces perhaps doing hundreds of millions of messages per second, in total. It covers transient pubsub, unreliable request-reply, pipeline, and peer-to-peer. It merges messaging with the network. Applications using ØMQ are architected around natural message flows, as distributed event-driven components. It competes with Tibco RDV, WebSphere LL, 29West, DDS, and TCP sockets.

AMQP and ØMQ cover some of the same ground but they take very different approaches. ØMQ acts more like low-latency products while AMQP acts more like JMS.

Network Topology

An AMQP network consists of a broker and applications connected in a star. Brokers can be duplicated for redundancy, and sometimes connected in federations. AMQP adopts the HTTP view of the Internet as a set of large hubs serving many users.

A ØMQ network consists of applications and brokers that interconnect in a distributed fashion. ØMQ adopts the TCP/IP view of the Internet as a dumb elastic fabric serving a massive number of users.

ØMQ does not come with a predefined broker. It is a library of broker-like functionality that you include into every application and use to build custom brokers (aka. 'devices') where you need them.

Addressing

In an AMQP network, applications address the broker, which is the only "stable" piece of the network. This means the only IP address or domain name that you have to manage is the broker address.

In a ØMQ network, applications address each other. There can be many stable pieces, i.e. pieces with known addresses. This means there are more IP addresses or domain names that you have to manage overall.

ØMQ networks have more stable pieces than AMQP networks, which can mean they are more work to manage.

Resources

AMQP defines these main resources: exchange, queue, and binding. The user takes these to create messaging patterns such as the request-reply and pubsub messaging patterns. To do pubsub you declare an exchange, create queues, bind the queues to the exchange, consume on the queues, and then publish to the exchange. Using the AMQP resource model you can in fact create about 50 messaging patterns, only 3-4 of them being useful and used.

ØMQ has no abstract resources, and defines messaging patterns as primary concepts. To do pubsub, you create a pub socket, create a sub socket, connect one to the other, and publish. ØMQ provides four messaging patterns literally.

ØMQ gives you messaging patterns directly. With AMQP you construct these yourself at runtime from more abstract resources.

Wiring Process

AMQP is really two protocols combined together:

  • A synchronous wiring protocol for working with server-based resources (e.g. Queue.Declare, Queue.Declare-Ok)
  • An asynchronous data protocol for transferring messages to and from these resources (Basic.Publish, Basic.Deliver)

ØMQ has no wiring protocol and is thus an asynchronous data protocol for transferring messages between application peers.

ØMQ is a pure message transfer protocol, there is no (need for a) command protocol.

Queueing

AMQP lets you manage queues explicitly on the broker. Shared queues and private queues exist in one space. This is essentially the same model as other enterprise messaging products. The advantage is you can manage queues explicitly. The cost is that you must.

ØMQ does not expose private queues at all, they are hidden and treated as transport buffers. You can set high-water marks to prevent queue overflow. If you want shared queues, you plug "queue devices" between clients and services.

AMQP treats queues as first class concepts. ØMQ treats them as invisible and automatic network buffers.

Reliability

AMQP aims for centralized reliability. That is, applications publish messages reliably to the broker, which queues them, and which then delivers then to other applications. This requires explicit and non-trvial support in the protocol and overall semantics.

ØMQ aims for distributed reliability along the TCP/IP model. That is, applications talk to each other using request-reply patterns where data is resent if lost. This requires no explicit protocol support and has no impact on ØMQ semantics since it operates above ØMQ.

AMQP aims to offer reliability built-in to the messaging. ØMQ aims to support reliability built on top of the messaging.

State Distribution

AMQP state is centralized in the broker. This means the broker is a single point of failure. AMQP has been significantly changed from 0.9.1 to try to make broker failover work better but it remains a complex problem.

ØMQ state is distributed. This means there is no single point of failure (unless you explicitly create it). It also means the protocol and API can be much simpler.

Much of AMQP is concerned with reliably centralized state, which ironically makes AMQP easy to break. ØMQ does not do this and thus is significantly simpler and has no single point of failure.

Message Routing

In AMQP all messages flow through the broker, which does sophisticated routing on them, via the abstracted resource model. AMQP's routing is capable of service-oriented architectures.

ØMQ build-in routing is much simpler and does not attempt to offer SOA functionality. You can build SOA networks on top of ØMQ.

ØMQ's message routing is simpler and faster, whereas AMQP's message flow is slower and more complex, but also more powerful.

To give two concrete examples:

  • To do market data distribution, an AMQP publisher connects to a broker and publishes data to it. Subscribers also connect to the broker and receive data from it. A ØMQ publisher binds to an endpoint and subscribers connect to that endpoint. For multicast, the endpoint is a switch.
  • To do request-reply, an AMQP client sends a request to a broker, which forwards it to a service application. The reply goes back via the broker to the client. A ØMQ client sends a request either directly to a service, or via a "queue" device that effectively acts as a microbroker.

Network Transports

AMQP depends on TCP (it can work with SCTP as a kind of TCP++ but that is exotic). AMQP's messaging patterns depend on connections between applications and the broker.

ØMQ does not require connected TCP, and its patterns work over multicast and disconnected TCP (i.e. where clients connect before services arrive). ØMQ also works with interprocess and interthread transports.

ØMQ is compatible with arbitrary network transports including reliable multicast. AMQP is strictly tied to TCP.

API

AMQP has no API standard but some APIs map directly to the protocol, which was designed with this in mind. The various AMQP APIs are concerned both with control of broker resources (Queue.Declare, Queue.Bind, etc.) and data delivery (publishing and deliver).

ØMQ uses the standard BSD socket API (connect, bind, send, recv), which covers wiring as well as message transport. The API is familiar to network developers. The API is not significantly simpler than AMQP's but it is more focussed on actual patterns and not the broker-based resource abstraction.

AMQP has no standard API which means AMQP applications are not consistent. ØMQ has essentially the same socket-style API in all languages.

Architecture

To use AMQP you link your applications with a client stack which can talk to an AMQP broker. All messages are sent over TCP/IP to the broker, and then on to other applications. AMQP therefore connects processes distributed across a LAN, where the scale of the architecture is limited by the capacity of the broker.

To use ØMQ, you link your applications with the ØMQ stack, which includes all queuing and message distribution functionality directly. You can thus use ØMQ to connect threads in one process, processes on one box, or processes across a LAN, using appropriate transports in each case. ØMQ thus provides a generic concurrency model that scales to any size.

While AMQP nicely solves the traditional message queuing problem, ØMQ goes further in making messaging fast and cheap enough to use more widely.

Layering & Extensions

There is no process or practice of layering extensions on AMQP. The enterprise vision of AMQP has been "one document that defines the whole stack", and the protocol has no formal extension points. (These were present in earlier versions but were removed.) Every AMQP vendor thus extends the protocol in different ways, presumably to add value to their product.

ØMQ being in effect a smart transport layer makes it easy to layer extensions ('unprotocols') on top to implement specific patterns. There are a number of these documented at http://rfc.zeromq.org, such as the Majordomo Protocol for service-oriented messaging, or the Titanic protocol for reliable messaging.

AMQP does not encourage layering of other standards on top of AMQP. ØMQ makes this trivial, and there are several efforts to build standard layers on top of the ØMQ protocol.

Complexity

AMQP/0.9.1 is significantly simpler than any previous or future version. However it is still complex to implement, as a protocol. This comes from the mixture of synchronous and asynchronous flows in one protocol and the use of binary for everything.

ØMQ is internally more complex than AMQP but hides this from users and implementors, who see a conventional socket-style API. Interoperability between languages is guaranteed because it is the same code running on each box.

AMQP's complexity results in weak interoperability, the main reason for writing a protocol. ØMQ is perfectly interoperable but only with itself.

Language Support

AMQP client stacks are large and expensive to build, since AMQP is a large and complex mix of two quite different protocols. In practice each language has recreated this stack from scratch. Further, each version of AMQP is incompatible with past and previous versions. This has limited your language choice and interoperability.

ØMQ is a complete client stack, and languages implement ØMQ by wrapping the C API in their own layer. This has made it a weekend project to implement ØMQ in a new language. The ØMQ wiki lists 20 supported languages.

AMQP support is expensive to build and thus its language support is limited. ØMQ is cheap to port to a new language and thus it supports a much wider range of languages.

Community

AMQP is developed by a workgroup that mostly represents investment banks, with some technology firms. Some AMQP products have developed a good community but AMQP as a core remains inaccessible to new contributors. The authorship of AMQP is one or two people for any version.

ØMQ is an open source project since the start, and mostly driven by expert users from small-to-medium trading firms, supercomputing teams, and more recently, open source developers. The mailing list and IRC channels are active and there are many projects building on and on top of ØMQ. There are dozens of active contributors to ØMQ.

ØMQ has a rapidly growing expert community that steers the product. AMQP is steered by a select committee of large firms, of which Microsoft is an enthusiastic member.

Ownership

AMQP is owned by the AMQP working group participants and licensed under a custom AMQP License. The license grants free use of the protocol but does not allow remixing of it. AMQP implementations are owned by their respective communities and companies.

ØMQ is owned by iMatix Corporation together with contributors and is licensed under LGPL. ØMQ's protocols are owned by their authors and licensed under the GPL using the Digistan COSS framework. Remixing of the protocols is encouraged.

AMQP is open but not free. You cannot fork AMQP and make a better version. The protocol is thus fully captured by the working group. ØMQ's protocols and software may be freely remixed.

Security and Robustness

AMQP has not been hardened for Internet use but it does offer various levels of security up to full encrytion.

ØMQ has no security layers, and is not considered hardened enough for Internet use.

ØMQ offers no more security than TCP. AMQP offers security comparable to HTTP though much less tested.

Protocol

AMQP is essentially a family of protocols (AMQP/0.8, AMQP/0.9, AMQP/0.9.1, AMQP/0.10, AMQP/1.0) with two or three main implementations that cover different versions. AMQP is not forwards or backwards compatible. As a result none of the AMQP products actually interoperated before they started to standardize on AMQP/0.9.1.

ØMQ is a single product that also has a wire level protocol, called ZMTP. The ØMQ wire level protocol is much simpler than AMQP (about 5 pages), but there are no implementations of it except ØMQ itself.

AMQP interoperability can happen at the protocol level. ØMQ interoperability works above the API, and through bridges and gateways.

Performance

AMQP is faster than its predecessors. It takes great care to be an efficient binary protocol where every byte counts. Its routing semantics were designed for high performance. However every message passes through a single point on the network.

ØMQ is about 50-100x faster than AMQP for a single node. It doesn't even use an efficient binary protocol: just a blob frame format. It doesn't route unless needed and can delegate that to network protocols like multicast.

For the same messaging patterns, ØMQ is much faster than AMQP with less footprint. But ØMQ cannot do as much as AMQP can.

Monitoring and Management

AMQP is managed at the broker level, but there is no agreement between vendors on a standard. E.g. iMatix designed CML and implemented this in OpenAMQ but RedHat later implemented an incompatible binary version of the same protocol. AMQP has no possibility of monitoring and managing client-side components.

ØMQ has no built-in monitoring or management but it is trivial to build using ØMQ itself. Indeed, we've used ØMQ to do distributed monitoring of AMQP-based networks. The Mongrel2 web server is a good example of using ØMQ to remotely manage applications.

AMQP products generally offer remote monitoring and management of the broker (not not clients) but there is no standard. ØMQ lets you build remote monitoring and management into your applications cheaply. And there is also no standard.

Vision and Scope

AMQP (prior to the version 1.0 rewrite) was designed by iMatix (a small boutique software firm with a background in open source) on behalf of JPMorganChase essentially to break the grip of IBM and JMS on the enterprise messaging market. It implements the old and well-tested vision of a large, powerful centralized server, but in a cheap and modern fashion. It focuses on centralized reliable message patterns.

ØMQ was also made by iMatix (an open source house with a recent background in boutique protocol design for large banks) as a new open source project. It implements the old and well-tested vision of smart endpoints connected by a stateless fabric. It focuses on decentralized scalable messaging patterns.

AMQP will become popular with banks because it looks like enterprise messaging but is much cheaper in terms of license costs. ØMQ will become popular with everyone else because it looks like TCP sockets but is much cheaper in terms of lines of code.

The Future

The AMQP community is converging on AMQP/0.9.1, which this author edited in 2008. That is a clean specification but it is a deprecated protocol branch. The forthcoming AMQP/1.0 has no exchanges, no bindings, no queues and a fully incompatible wire level protocol. There is no backwards compatibility.

The ØMQ community rests on the BSD socket API, which was released with 4.2BSD in 1983. Other products like OpenPGM are now also moving to a BSD socket API. ØMQ 3.0 will simplify its API further but keep the same semantics. Future versions of ØMQ's wire level protocol will be backwards compatible.

AMQP is heading for conflict between its community and the workgroup. ØMQ is becoming a 'category killer'.

Conclusions

When you switch to ØMQ you will have to unlearn the AMQP patterns and learn new ones. Essentially, ØMQ gives you intelligent sockets to which you can delegate various messaging patterns. It is like having small brokers all over the network. The lack of a single "stable" point of reference may be disorienting at first.

Both technologies are open, fairly cheap to learn and use, and better than anything else that exists. Where they overlap, ØMQ does it better, with smarter queuing, less management costs, less complexity, and significantly better performance. A smart team would learn them both and possibly use both in parallel, i.e. applications talking to a central broker via AMQP but also to each other via ØMQ. If AMQP/0.9.1 survives its own working group, it may become an IETF standard for messaging.