concept exchange in category rabbitmq

This is an excerpt from Manning's book RabbitMQ in Depth. Login to get full access to this book.

Exchanges are one of three components defined by the AMQ model. An exchange receives messages sent into RabbitMQ and determines where to send them. Exchanges define the routing behaviors that are applied to messages, usually by examining data attributes passed along with the message or that are contained within the message’s properties.

RabbitMQ has multiple exchange types, each with different routing behaviors. In addition, it offers a plugin-based architecture for custom exchanges. Figure 1.9 shows a logical view of a publisher sending a message to RabbitMQ, routing a message through an exchange.

Figure 1.9. When a publisher sends a message into RabbitMQ, it first goes to an exchange.

Message was returned by RabbitMQ: (312) NO_ROUTE for exchange chapter2-example

copy

Perhaps RabbitMQ’s greatest strength is the flexibility it offers for routing messages to different queues based upon routing information provided by the publisher. Whether it’s sending messages to a single queue, multiple queues, exchanges, or another external source provided by an exchange plugin, RabbitMQ’s routing engine is both extremely fast and highly flexible. Although your initial application may not need complex routing logic, starting with the right type of exchange can have a dramatic impact on your application architecture.

In this chapter, we’ll take a look at four basic types of exchanges and the types of architectures that can benefit from them:

6.6. Going meta: exchange-to-exchange routing

If you don’t think you’ve been presented with enough message-routing flexibility and find that your application needs a little of one exchange type and a little of another for the exact same message, you’re in luck. The RabbitMQ team added a very flexible mechanism in RabbitMQ that’s not in the AMQP specification, allowing you to route messages through any combination of exchanges. The mechanism for exchange-to-exchange binding is very similar to queue binding, but instead of binding a queue to an exchange, you bind an exchange to another exchange using the Exchange.Bind RPC method.

When using exchange-to-exchange binding, the routing logic that’s applied to a bound exchange is the same as it would be if the bound object were a queue. Any exchange can be bound to another exchange, including all of the built-in exchange types. This functionality allows you to chain exchanges in all sorts of imaginative ways. Do you want to route messages using namespaced keys through a topic exchange and then distribute them based upon the properties header table? If so, an exchange-to-exchange binding is the tool for you (figure 6.14).

Figure 6.14. A small example of the flexibility that exchange-to-exchange binding offers

As illustrated in figure 6.2, the request process begins when a mobile client application uploads the image and your application receives the content. The application then creates a message with a unique ID that identifies the remote request. When publishing the image to the exchange, the response queue name will be set in the reply-to field in the message’s properties and the request ID will be placed in the correlation-id field. The body of the message will contain only the opaque binary data of the image.