This guide explains typical messaging patterns and use cases. It only covers the most common scenarios. For a comprehensive list of messaging patterns, consult books on this subject, for example, Enterprise Integration Patterns.
This work is licensed under a Creative Commons Attribution 3.0 Unported License (including images and stylesheets). The source is available on Github.
This guide covers Ruby amqp gem 1.0.×.
Messaging patterns are a lot like object-oriented design patterns in that they are generalized reusable solutions to specific problems. They are not recipes, however, and their exact implementation may vary from application to application. Just like OO design patterns, they too can be classified:
Request/Reply is a simple way of integration when one application issues a request and another application responds to it. This pattern is often referred to as “Remote Procedure Call”, even when it is not entirely correct. The Request/Reply pattern is a 1:1 communication pattern.
Some examples of the Request/Reply pattern are:
Implementation of Request/Reply pattern on top of AMQP 0.9.1 involves two messages: a request (Req) and a response (Res). A client app generates a request identifier and sets the :message_id attribute on Req. The client also uses a server-named exclusive queue to receive replies and thus sets the :reply_to Req attribute to the name of that queue.
A server app uses a well-known queue name to receive requests and sets the :correlation_id to the :message_id of the original request message (Req) to make it possible for the client to identify which request a reply is for.
Request/Reply demonstrates two common techniques that are sometimes referred to as messaging patterns of its own:
Other related patterns are
The Command pattern is very similar to Request/Reply, except that there is no reply and messages are typed. For example, most modern Web applications have at least one “background task processor” that carries out a number of operations asynchronously, without sending any responses back. The Command pattern usually assumes 1:1 communication.
Some specific examples of the Command pattern are:
Implementation of the Command pattern on top of AMQP 0.9.1 involves well-known durable queues. The application that issues the command then can use the default exchange to publish messages to well-known services directly. The Request message :type attribute then indicates the command type and the message body (or body and headers) carry any additional information that the consumer needs to carry out the command.
The Event pattern is a version of the Command pattern, but with one or more receivers (1:N communication). The world we live in is full of events, so applications of this pattern are endless.
Some specific use cases of the Event pattern are
The Event pattern is very similar to the Command pattern, however, there are typically certain differences between the two:
Because the Event pattern is a 1:N communication pattern, it typically uses a fanout exchange. Event listeners then use server-named exclusive queues all bound to that exchange. Event messages use the :type message attribute to indicate the event type and the message body (plus, possibly, message headers) to pass event context information.
Due to misconfiguration or different upgrade time/policy, applications may receive events that they do not know how to handle. It is important for developers to handle such cases, otherwise it is likely that consumers will crash.
More on fanout exchange type in the Working With Exchanges guide.
The Document Message pattern is very similar to the Command and Event patterns. The difference is in the intent. A Command message tells the receiver to invoke certain behavior, whereas a Document Message just passes data and lets the receiver decide what to do with the data.
The message payload is a single logical entity, for example, one (or a group of closely related) database rows or documents.
Use cases for the Document Message pattern often have something to do with processing of documents:
Competing Consumers are multiple consumers that process messages from a shared queue.
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
TBD
Please take a moment to tell us what you think about this guide on Twitter or the Ruby AMQP mailing list
Let us know what was unclear or what has not been covered. Maybe you do not like the guide style or grammar or discover spelling mistakes. Reader feedback is key to making the documentation better.
If, for some reason, you cannot use the communication channels mentioned above, you can contact the author of the guides directly