The RabbitMQ messaging server is an open source implementation of the AMQP 0-9-1 protocol (Advanced Message Queuing Protocol) that defines how messages should be queued, routed, and delivered in a reliable and secure manner. AMQP 1.0, which is an OASIS (Organization for the Advancement of Structured Information Standards), is not directly supported in the message broker; however, RabbitMQ provides a plugin for AMQP 1.0 (as it is not backward-compatible with AMQP 0-9-1). OASIS is a non-profit organization that works for the development of a number of technology standards. As an open standard, AMQP promotes interoperability among the messaging brokers that implement the protocol. It also defines the delivery semantics for a message, which dictates how many times that message can be sent from one endpoint to another—zero or once, exactly once or multiple times. As a wire protocol, AMQP provides better performance in regard to other messaging protocols such as XMPP (Extensible Messaging and Presence Protocol).
Before we discuss more about RabbitMQ as a message broker, we will introduce some terminologies from the RabbitMQ world that we will use frequently throughout the book:
exchanges: These are the RabbitMQ server endpoints to which the clients will connect and send messages. Each endpoint is identified by a unique key.
queues: These are the RabbitMQ server components that buffer messages coming from one or more exchanges and send them to the corresponding message receivers. The messages in a queue can also be offloaded to a persistent storage (such queues are also called durable queues) that provides a higher degree of reliability in case of a failed messaging server; once the server is running again, the messages from persistent storage are placed back in the corresponding queues for transfer to recipients. Each queue is identified by a unique key.
bindings: These are the logical link between exchanges and queues. Each binding is a rule that specifies how the exchanges should route messages to queues. A binding may have a routing key that can be used by clients in order to specify the routing semantics of a message.
virtual hosts: The logical units that divide RabbitMQ server components (such as exchanges, queues, and users) into separate groups for better administration and access control. Each AMQP client connection is bound to a concrete virtual host.
The AMQP protocol allows a client to establish a one-way logical link to send messages for exchange. Each logical link is a separate AMQP channel that may provide additional options for the reliable transfer of messages. In this regard, a single-client TCP connection to the RabbitMQ server allows multiple AMQP channels of communication. Since AMQP does not provide the capability to retrieve the list of queues, exchanges, or bindings that are defined in the RabbitMQ message broker, client applications must specify the exchange name, queue names, and, optionally, routing information by means of routing keys for particular bindings. AMQP is a programmatic protocol that allows its clients to create and delete exchanges, queues, and bindings when necessary. RabbitMQ addresses some limitations of AMQP by providing custom extensions apart from the fact that the AMQP protocol itself is extensible. In order to simply application development, RabbitMQ provides several exchange types out of the box, as follows:
direct exchange: This delivers a message based on a routing key that is provided in the message header (bindings should already be defined between the direct exchange and the queue). There is a pre-created direct exchange with the name .amq.direct. A specialized type of a direct exchange called default exchange with the empty string as the exchange name is also pre-created in the message broker. It has the special property where the binding key that is specified by the client should match the name of the queue to which a message is routed.
fanout exchange: This delivers a message to all the queues that are bound to the exchange; it can be used to establish a broadcast mechanism for the delivery of messages to the queues. There is a pre-created fanout exchange with name .amq.fanout.
topic exchange: This delivers the message to queues based on a routing filter specified between the topic exchange and queues; it can be used to establish a multicast mechanism for the delivery of messages. There is a pre-created topic exchange with the name .amq.topic.
headers exchange: This can be used to deliver messages to queues based on other message header attributes (and not the routing key). There are two pre-created headers exchanges with names .amq.headers and .amq.match.
Receivers can either subscribe to a queue in order to receive messages (also called push-style communication) or request messages on demand from a queue (also called pull-style communication).
The RabbitMQ message broker provides a number of features and tools that support production-level deployment, management, and configuration of the RabbitMQ server instances as shown in the following:
support for multiple protocols: Apart from AMQP, RabbitMQ provides support for the STOMP, MQTT, and HTTP protocols by the means of RabbitMQ plug-ins.
routing capabilities: As we already saw, we can implement rules to route messages between exchanges and queues by means of bindings, moreover, more custom exchange types can be defined that can provide additional routing capabilities.
support for multiple programming languages: There are a variety of supported clients for a great variety of programming languages.
reliable delivery: This is a mechanism that guarantees successful message delivery by the means of acknowledgements. It can be enabled between the producer and the broker as well as the broker and the consumer.
clustering: This provides a mechanism to implement scalable applications in terms of the RabbitMQ message broker.
federation: This is an alternative mechanism to implement scalable applications with RabbitMQ by the means of transferring messages between exchanges and queues in different broker instances without the need to create a RabbitMQ cluster.
high availability: This ensures that if a broker fails, communication will be redirected to a different broker instance. It is implemented by the means of mirroring queues; messages from a queue on a master broker instance are copied to a queue on a slave broker instance and, once the message is acknowledge, the messages are discarded from both the master and slave instances.
management and monitoring: A number of utilities are built around the RabbitMQ broker server that provide these capabilities.
Authentication and access control.
pluggable architecture: RabbitMQ provides a mechanism to extend its functionality by the means of RabbitMQ plug-ins.
All of these features will be covered in detail in the next chapters.
As RabbitMQ is not the only player in the world of enterprise messaging solutions, it is good to see what makes RabbitMQ different compared to other messaging systems. A short list of alternative solutions (some of them also implementing the AMQP protocol) may include systems such as Apache ActiveMQ, Apache Kafka, Apache Qpid, JBoss Messaging, Microsoft BizTalk Server, and WebSphere Message Broker. There are different benchmarks that can be found throughout the internet that show us the relative results in comparison to the different types of brokers in terms of message sending (from publisher to broker) and message delivery (from broker to consumer). In case you need to compare RabbitMQ with the previously mentioned or other messaging solutions, you can apply the following strategy:
Select a subset of technologies that are suitable for your use case based on the variety of factors that are listed at the beginning of this chapter
Perform different types of benchmark based on the variations of size and number of messages that will be sent for the purpose of processing by each solution in the comparison group, based on the format of messages for the particular use case
You can download a RabbitMQ distribution package for the operating system of your choice from http://www.rabbitmq.com/Windows.
For Windows operating systems, you have the ability to use the provided RabbitMQ installer (the simpler alternative) or manually install the broker using the provided zip distribution archive (requires additional setup of Windows system paths). We will provide an overview of the installation process for Windows 7 using the installer for Rabbit 3.3.5 (rabbitmq-server-3.3.5.exe) that is quite straight-forward. Initially, the installer checks whether Erlang is installed on the target Windows system and, if it cannot find it, a dialog prompts you to install it, as shown in the following image:
If you click Yes, the dialog redirects you to the official Erlang website. There, you will find the appropriate binaries for your 32-bit/64-bit Windows operating system. Download and install the Erlang 17.3 distribution (compatible with RabbitMQ 3.3.5) for 64-bit Windows (otp_win64_17.3.exe):
File associations can be established and the Erlang documentation can be installed as a part of the Erlang installation process:
The next step is to specify the location to install Erlang:
Finally, you have the option to place an Erlang shortcut in the Start menu folder. After the installation is finished, you can run the RabbitMQ 3.3.5 server installer again:
You can specify in addition that Start menu items and a Windows service should be added along with RabbitMQ server installation. Adding a Windows service for RabbitMQ server is usually recommended as it provides a convenient mechanism to manage a RabbitMQ server instance:
The final step is to specify the location to install the RabbitMQ server. Once the installation is complete, the installer tries to start the RabbitMQ server and, if your Windows firewall is turned on, you might be prompted to allow access to the RabbitMQ server in order to open a port on the target machine (the default port is 5672 for a RabbitMQ server node instance). In order to check whether the RabbitMQ service is running, you can open services.msc from the Windows Run menu and check whether the RabbitMQ service has started. Additionally, you can check whether the RabbitMQ instance node is initiated, by default on port 5672, by executing from the command prompt:
netstat –a
RabbitMQ installation also provides a number of command-line utilities that you can use in order to manage the RabbitMQ instance, which is located under the rabbitmq_server-3.3.5\sbin folder in the RabbitMQ installation directory. You can use the rabbitmqctl utility to check the status of a broker, start, or stop it:
rabbitmqctl.bat status rabbitmqctl.bat stop rabbitmqctl.bat start
In addition to this, rabbitmqctl provides a number of other commands that can be used to manage the RabbitMQ broker. There is a RabbitMQ management plugin that provides the ability to manage a RabbitMQ broker from a web-based interface and in particular to do the following:
Manage broker objects such as message queues, users, and permissions
Send messages to the broker
Receive messages from the broker
Monitor and manage connections to the broker
Monitor broker workload
Monitor resource usage such as memory, processes, and file descriptors that are used by the broker
These are included in the set of plugins that are installed by default; however, it must be enabled by executing the rabbitmq-plugins utility that is located under the rabbitmq_server-3.3.5\sbin folder in the RabbitMQ installation directory from the following command prompt:
rabbitmq-plugins.bat enable rabbitmq_management
After the management plugin is enabled, you have to restart the RabbitMQ server:
rabbitmq-server.bat restart
The management plugin starts an http server, on port 15672, by default in order to verify that the plugin is trying to open http://localhost:15672/ from a browser. You will be prompted to provide a Username and Password in order to login:
By default, RabbitMQ installs with a user with a guest name and guest password that are only available from local host connections to the broker. In the next chapter, we will see how to manage users for a RabbitMQ server.
For various Linux distributions, there are out-of-the-box packages provided for the RabbitMQ server. Some Linux distributions also provide you with the ability to install the broker directly from a package repository. We will provide an overview of the installation process for Ubuntu 12.04 Desktop edition based on a package repository that we can also download and install directly, a RabbitMQ Debian package for the purpose. To install the broker and enable the management plugin, open a terminal and execute the following command:
echo "deb http://www.rabbitmq.com/debian/ testing main" | sudo tee /etc/apt/sources.list.d/rabbitmq.list > /dev/null sudo wget http://www.rabbitmq.com/rabbitmq-signing-key-public.asc sudo apt-key add rabbitmq-signing-key-public.asc sudo apt-get update sudo apt-get install rabbitmq-server –y sudo rabbitmq-plugins enable rabbitmq_management sudo service rabbitmq-server restart
Tip
Downloading the example code
You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
The server installation also installs utilities for the management of the RabbitMQ server—used in the same way as in the Windows installation of RabbitMQ.