RabbitMQ server simply solves messaging problems. But what is the meaning of messaging itself? Sometimes, the term messaging is confused with real-time messaging such as chat messages, SMS messages, and so on. These systems also have the messaging system in their subsystems; however, we are talking about a somewhat different issue.
By the dictionary definition, messaging is a short communication transmitted by words, signals, or other means from one person, station, or group to another. In computer engineering, definition of messaging seems like the dictionary definition. Messaging simply takes the messages from a producer and sends it to the consumers by the computer engineering definition. In messaging systems, we are using some architecture related to messaging and elements. Moreover, we have different functionalities of the elements in the messaging system. So, we will start our most important chapter with the messaging concepts and their roots, and then we'll dive into the details of AMQP that describes the RabbitMQ mechanism. The following list shows the structure of this chapter:
- Messaging and use cases of messaging
- Enterprise messaging
- Messaging related software architectures
- Messaging concepts
- Advanced message queuing protocol (AMQP)
As we discussed in the introduction of this chapter and in the first chapter, messaging is simply defined as communication between the message producer and the consumer of the message. Message broker is defined as a module that controls messaging flow. Controlling action isn't that simple, so message brokers needs lots of skills to accomplish this messaging functionality.
Before talking about the Message Broker functionalities, we need to know the problems that we have with the messaging. The problems change with respect to the domain of the software system; however, most of the problems are the same within the different types of messaging functionalities of the software systems. Let's list all of the common problems of messaging and how we solve these problems using message brokers.
Nowadays, coupling is generally referred to as the expression of dependency between two modules with respect to each other. Coupling, or more specifically tangling code, is bad because it makes it harder to maintain software. Any change on dependent component may result in changes, bugs, version upgrades, and so on. Tight coupling can be at the code level, and at the service/architecture level. For both code and architectural coupling, solutions exist. Code level coupling can be solved with dependency injection. Architectural coupling can be solved with message brokers. We need to create an abstraction between modules for messaging issue. The following screenshot shows us the coupled messaging modules that interact with the other modules without using Message Broker. Whenever you change one method of the module, you have to propagate this change to the other modules:
Coupling of messaging modules
Message Broker is an awesome solution for the well-known problem of high-coupled software systems that is communicated between modules. Message Broker creates an abstraction between modules, so that messaging functionality is controlled and managed by the Message Broker itself. Modules are not aware of the sending or receiving of messages; they only send their messages to the right receiver via Message Broker. Message Broker routes these messages to the right module and transforms them to the appropriate messaging format.
As a consequence, Message Broker is defined as messaging middleware that simply makes a transition of high-coupled messaging modules to the low-coupled messaging modules by creating the intermediate layer between modules. As shown in the following screenshot, modules are sending and receiving messages from each other without knowing the functionality of the intermediate layer, which sends the messages to Message Broker and routes them to the right module:
Decoupling of messaging modules using message broker
Nowadays, every software systems are using different types of technologies, such as Java Platform, .Net Framework, Mainframes, and so on. Also, the mobility and web gives us the opportunity to add new clients to our software systems. Therefore, we have to merge these technology stacks in software architecture and connect them to each other; for instance, connecting Java Platform to .Net Framework. Then, we have another problem in our software system: Heterogeneous Integration.
We have great web service solutions to guarantee the Heterogeneous Integration between technology stack and different types of clients; however, all of them have bottlenecks; so we have another great solution: Message Broker. Message Broker has a capability to send and receive messages without analyzing the details of the sender and receiver. Message Broker just sends the messages in a given format to the right module. The receiver module just needs to parse the message into their format. Thus, Message Broker just gives us the combination of different stacks into one architecture, and it gives us another solution for well-known software engineering problem: Interoperability. The following screenshot will show you how Message Broker communicates between different programming languages:
Heterogeneous Integration
As a consequence, not only Message Broker sends the messages to right receiver, but it also satisfies the Heterogeneous Integration to combine different types of technologies in our stack.
In dictionary definition, Scalability simply means that the software or network system can adapt to increased demands. Scalability is our modern software engineering problem; lots of academic papers have aimed to solve this well-known issue. Scalability is not an easy problem and doesn't have a single solution. Although scalability differs from financial software systems to real time web applications, they have a similar problem: communicating between modules or processes. Then it comes to Message Brokers, which solve this scalability problem.
We all know that Message Brokers can address part of the scalability problem, but we need to know how it addresses this. Message Brokers gives us these items in its muscle:
- It increases the overall throughput of the system, which reduces the response time of the software system
- Multiple message receiver and sender capability of Message Broker gives us an opportunity to cope with concurrent messages
- It allows us to create an Asynchronous System, so we have an opportunity to control messaging in our modules in an event-driven manner
Consequently, Message Broker eases well-known problem scalability by delivering high throughput, less response time, and highly concurrent system.
So, we showed the three different problems that we aim to solve using Message Brokers. Message Brokers not only solve these well-known problems, but also aim to solve all of the messaging problems between applications, modules, and processes. Note that messaging itself can become single point of failure. Scaling messaging is where brokers are expected to be effective.