Saturday, October 13, 2007

AMQP in 10 mins : Part4 - Standard Exchange Types And Supporting Common Messaging Use Cases

AMQP defines four standard exchange types (routing algorithms) that covers most of the common messaging use cases. All AMQP brokers are required to support each of these exchange types and pre declare an instance of it identified by a standard name. The idea is to provide a simple out-of-the-box solution to most users. Users are free to create more instances of these exchange types with their own names. Also as mentioned in the previous post, users can create different exchange types and instances of them.

It is important to note that with any exchange type, a message can be matched with more than one queue if two or more queues are bound with the same routing criteria.

Direct Exchange
The exchange does a direct match between the routing key provided in the message and the routing criteria used when a queue is bound to this exchange.






(Click on image)

The most common use case is to bind the queue to the exchange using the queue name. However it is important to note that you could use any value for the binding.

A broker is required to provide an instance of this exchange named "amq.direct". The Nameless Exchange is a special instance of the above exchange type where all queues are bound to this exchange automatically using the queue name as the routing criteria. This exchange instance has no public name, hence messages sent without specifying an exchange name are directed to this exchange.

Topic Exchange
The exchange does a wildcard match between the routing key and the routing pattern specified in the binding. The routing key is treated as zero or more more words, delimited by '.' and supports special wildcard characters. "*" matches a single word and '#' matches zero or more words.






(Click on image)

A broker is required to provide an instance of this exchange named "amq.topic".

Fanout Exchange
Queues are bound to this exchange with no arguments. Hence any message sent to this exchange will be forwarded to all queues bound to this exchange.


(Click on image)
  • One use case, is to use exchange chaining in a tree like hierarchy that can be used to push messages to a large number of subscribers.
  • Another use case is where a direct exchange or a topic exchange can do the initial filtering which then forwards the message to a fannout exchange which will push the messages to all it's queues.
A broker is required to provide an instance of this exchange named "amq.fanout".

Headers Exchange
Queues are bound to this exchange with a table of arguments containing headers and values (optional). A special argument named "x-match" determines the matching algorithm, where "all" implies an AND (all pairs must match) and "any" implies OR (at least one pair must match).


(Click on image)

A broker is required to provide an instance of this exchange named "amq.match".

How AMQP Supports Common Messaging Use Cases
The most common messaging use cases are point-to-point (or store and forward) and publisher/subscriber models. These models can be easily built on top of AMQP.

Point-to-Point
routing_key == queue_name

Pub/Sub
routing_key == topic_heirarchy_value

Next Part : Part5 - Lets look at some code - Python examples

Prev Part : Part3 - Flexible Routing Model

2 comments:

moe said...

awesome, thank you so much for the insight!

i can't wait for the next part of the series because that's exactly where i'm stuck right now: figuring out the qpid python client library.

unfortunately there is zero documentation for that and while the api *looks* simple at first glance, the semantics most certainly are not.

Rajith Attapattu said...

Sorry for the delay in putting out the python examples.
The python code is still being worked out. As soon as the API settles down, I will write the next part