What is AMQP? and the architecture

What is AMQP? (Advanced Message Queuing Protocol)

When two applications need to communicate there are a lot of solutions like IPC, if these applications are remote we can use RPC. When two or more applications communicate with each other we can use ESB. And there are many more solutions. But when more than two applications communicate and the systems need to be scalable the problem is a bit more complicated. In fact, when we need to send a call to a remote process or distribute object processing among different servers we start to think about queues.

Typical examples are rendering farms, massive mail sending, publish/subscriptions solutions like news systems. At that time we start to consider a queue-based solution. In my case the first approach to these types of solutions was Gearman; that is a very simple queue system where workers connect to a central service where producers have to call the methods published by workers; the messages are queued and delivered to workers in a simple queue.

Another interesting solution can be use Redis like a queue service using their features like publish/subscribe. Anyway always you can develop your own queue system. Maybe there a lot of solutions like that but when you are interested in develop in standard way and want a long-run solution with scalability and high availability then you need to think in use AMQP-based solutions.

The most simple definition of AMQP is: “message-oriented middleware”. Behind this simple definition there are a lot of features available. Before AMQP there was some message-oriented middlewares, for example, JMS. But AMQP is the standard protocol to keep when you choice a queue-based solution.

AMQP have features like queuing, routing, reliability and security. And most of the implementations of AMQP have a really scalable architectures and high availability solutions.

The architecture

The basic architecture is simple, there are a client applications called producers that create messages and deliver it to a AMQP server also called broker. Inside the broker the messages are routed and filtered until arrive to queues where another applications called consumers are connected and get the messages to be processed.

When we have understood this maybe is the time to deep inside the broker where there are AMQP magic. The broker has three parts:

1. Exchange: where the producer applications delivers the messages,  messages have a routing key and exchange uses it to route messages.
2. Queues: where messages are stored and then consumers get the messages from queues.
3. Bindings: makes relations between exchanges and queues.

When exchange have a message uses their routing key and three different exchange methods to choose where the message goes:

1. Direct Exchange:  routing key matches the queue name.
2. Fanout Exchange: the message is cloned and sent to all queues connected to this exchange.
3. Topic Exchange: using wildcards the message can be routed to some of connected queues.

This is the internal schema of a broker:

AMQP and RabbitMQ [TOC]

After reading the book ‘RabbitMQ in action‘ I’m working on series of posts  that will include the following subjects:

1. What is AMQP? and the architecure
2. Deep inside AMQP
3. RabbitMQ CLI quick reference
4. Hello World using ‘kombu’ library and python
5. Parallel programming
6. Events example
7. RPC
8. Clustering fundamentals
9. Managing RabbitMQ from administration web interface
10. Managing RabbitMQ from REST API

Please let me know if you are interested in this series of posts. Because in my opinion this is very interesting and it always comes in handy to know if someone has been working on those subjects.