The code files of this chapter can be found on GitHub at https://github.com/PacktPublishing/RabbitMQ-Essentials-Second-Edition/tree/master/Chapter01.

Smoke signals, couriers, carrier pigeons, and semaphores: if this was a riddle, the word messages would immediately spring to mind. Humanity has always had the need to connect, finding new ways to defy challenges posed by the distance between the different groups of people needing to communicate. Humankind has come a long way with modern technologies, but essentially, the basics remain. Senders, recipients, and messages are at the core of all our communication infrastructures.

Software applications have the same needs; systems need to communicate and send messages between each other. They sometimes need to be sure that the message that's been sent has reached its destination, and sometimes they need to receive an immediate response. In some cases, they may even need to receive more than one response. Based on these different needs, different styles of communication between systems have emerged.

AMQP, RabbitMQ's default protocol, is explained in the...

Message queuing is a one-way communication style that provides asynchronous interaction between systems. As this chapter continues to describe how message queues work, the benefits will become clear. Some background on the request-response message exchange pattern will shed light on how RabbitMQ works.

The request-response message exchange pattern

There are many types of message exchange patterns, but the request-response style is the most common. A system, acting as a client, interacts with another remote system, which is acting as a server. The client sends a request for data, and the server responds to the request, as shown in the following diagram:

The request-response style is used when the client must have an immediate response or wants the service to complete a task without delay, such as being placed on hold when calling a restaurant to reserve a table:

The most common use case for RabbitMQ is a single producer, single consumer queue. Think of it as a pipe where one application puts messages into one end of the pipe and another application reads the messages that come out the other end. Messages are delivered in first in, first out order. These messages may be commands or contain important data. This sounds easy, but where could this type of architecture be applied? It's time to understand when and why message queuing shines!

Message queues between microservices

Message queues are often used in between microservices, but what does that mean?

Microservice architectural style divides the application into small services, with the finished application being the sum of its microservices. The services are not strictly connected to each other. Instead, they use, for example, message queues to keep in touch. One service asynchronously pushes messages to a queue and those messages are delivered to the correct...

Communication between various applications plays an important role in distributed systems. There are many examples of when a message queue can be used, so let's highlight some features and benefits of message queuing in microservice architectures:

• Development and maintenance made easier: Dividing an application across multiple services allows separate responsibilities and gives developers the freedom to write code for a specific service in any chosen language. It will be easier to maintain written code and make changes to the system; when updating a single authentication scheme, only the authentication module must have code added for testing, without it disrupting any other functions.
• Fault isolation: A fault can be isolated to a single module and will thereby not affect other services. For example, an application with a reporting service temporarily out of function will not affect the authenticate or payment services. As another example...

CC is a new taxi agency with huge potential. Today, the company has just two taxi drivers and two developers, but they want to expand a lot in the upcoming year. CC has already built a website in Ruby and started out with a backend, also written in Ruby, that stores CC trips in a database. CC also has some scripts, written in Python, that generate route reports.

So far, CC's system runs as follows:

• The company's website and blog runs on Ruby.
• The Rich Internet Application that stores route data, such as the starting point and the endpoint of the trip, is written in Ruby.
• There's a back-office that sends route updates to drivers and is written in Ruby.
• Multiple ad hoc Python scripts are used to extract and message data to generate route reports.
• Taxi applications are written in Python.

The old architecture is illustrated as follows:

Why is CC looking at adding RabbitMQ to an already busy environment? The main reason...

To get started, the following three installation and configuration steps need to be completed:

• Installing the RabbitMQ broker
• Installing the management plugin (Web UI)
• Configuring the vhost and user

Let's start by installing the broker!

Installing the broker

CC runs its production servers on Ubuntu Linux. One developer has macOS and Linux, while the other one is all Windows. This heterogeneity is not a concern for RabbitMQ, which can run natively on all these operating systems.

RabbitMQ provides complete online installation guides for all the supported operating systems, and they can be found here: http://www.rabbitmq.com/download.html. This book contains instructions for Debian/Ubuntu, where RabbitMQ is installed from the apt repository. It also contains instructions for Docker further down in this chapter.

RabbitMQ installation on Ubuntu

There are relatively few steps required to install RabbitMQ. They are as follows:

1. Update Ubuntu.
2. Download and install...

This chapter explored the architectural and design promises of messaging, including how AMQP and RabbitMQ deliver on these promises. In addition, the reason why the taxi agency Complete Car decided to introduce RabbitMQ in its software landscape was discovered. Finally, a RabbitMQ broker was installed and a user and various vhosts were configured for it. Armed with a basic understanding of message queues and RabbitMQ, the next chapter builds on these concepts and explores the architecture behind the Complete Car taxi application.

It's time to hit the ground running and write some code. Turn to the next chapter to start building a RabbitMQ-powered application!