Messaging

Just as messages are used by people every day to transfer information, the concept of computers exchanging data in a predefined format is called Messaging in the field of Computer Science. While Messaging has many aspects, this documentation covers the following points:

• Asynchronous vs. Synchronous Communication
• Messaging Providers and Queues
• Publish/Subscribe Pattern
• APIs vs. Messaging

Asynchronous vs. Synchronous Communication

The primary distinction between asynchronous and synchronous communication lies in the actions taken by the sender after dispatching a message to the recipient. In synchronous communication, the sender establishes a connection with the recipient, transmits the message, and then awaits a response. During this time, no additional tasks are undertaken until the communication concludes and the connection is terminated.

This can be compared to the ordering process in a fast food restaurant: When customers order their favorite burger menu, they are not supposed to go to the bathroom after placing their drink order, letting everyone else wait before ordering their meal. The whole ordering process is done in synchronous communication, and customers and workers stop any other tasks and activities until all the orders are placed. Find a diagram of the meal order in synchronous communication below:

With asynchronous communication, the necessity of waiting for a response is eliminated. After the transmission of the message, both the sender and the recipient are free to proceed with other tasks.

In the fast food restaurant example, the way the orders are processed in the kitchen is a good example of asynchronous communication. In this asynchronous process, the order is queued and the worker in the kitchen picks it up as soon as he has at least one thread (or arm) available. Depending on the workload, the worker may process the order immediately or after a few minutes. How exactly the processing of orders is organized might be different from restaurant to restaurant, but the basic elements of asynchronous communication are the same.

Messaging Providers and Queues

While synchronous communication takes place in a direct exchange between two parties, asynchronous communication requires two key components: Queues and the messaging provider.

The motivation for using queues is that the sender can continue with other tasks. To do this, the message (e.g. order number 5) must be held in the system until it is collected. The solution is a component that temporarily stores messages between sender and receiver, called Queue.

Like a queue of customers waiting for the cashier to take their order, a Messaging Queue is an ordered list of messages waiting to be processed. The concept of queues is especially relevant for Point-to-Point Messaging, where messages from the sender have exactly one message consumer.

In the example of the burger restaurant, the recipients of the message are the employees in the kitchen who take orders from the queue. If someone has to do a shift alone in the kitchen, then that person is the recipient in the point-to-point messaging. This is the visual representation of the queue in the fast food restaurant:

The entire messaging system, including all queues and the logic for processing messages, is managed by a special software component. This is where the Messaging Provider comes into play, which is responsible for storing, queuing and forwarding messages. It also ensures that the message is delivered to the recipient only once and in the correct order.

In our fast food restaurant example, the messaging provider is a dedicated piece of software that stores all orders and ensures that each order is processed only once and in the correct order. The cashier could act as a messaging provider and note down the orders on a piece of paper so that the kitchen staff can pick them up.

Publish/Subscribe Pattern

There is an alternative to the Point-to-Point Messaging called the Publish/Subscribe Pattern. In this pattern, the sender doesn't send the message directly to the recipient, but rather to a topic. The recipient subscribes to the topic and receives all messages sent to this topic. This pattern is especially useful when the sender does not know the recipient or when the sender wants to send the message to multiple recipients.

Imagine the burger restaurant decides to open a second section, say a café which processes all orders related to coffee. In this case, certain workers in the kitchen are responsible for all orders related to the topic called coffee. Other workers still handle the regular burger orders and don’t care about the coffee orders. In this example, we are in the realm of „Publish/Subscribe" messaging with the topics of burger and coffee. The message consumers are the workers in the kitchen handling orders from their topic. There is still an aspect of queueing order involved, since the coffee order placed first should be processed first. However, it could be that the burger is ordered after the coffee, but it's ready before the coffee is. This processing time depends on the workload and the current number of workers in the kitchen of both the burger and the café section.

APIs vs. Messaging

APIs (Application Programming Interfaces) and Messaging are two different ways of communication between systems. The differences between these concepts can be described as follows: APIs are synchronous and point-to-point, while messaging is asynchronous and can be point-to-point or publish-subscribe. Furthermore, APIs are used when the sender needs an immediate response from the recipient. Messaging is used when the sender doesn’t need an immediate response or when the recipient is not available at the time of sending the message.

In the example of the burger restaurant, the API could be the beverage vending machine in the restaurant, where the customer can order a drink and immediately receive it. The messaging system would be implemented in the self-service terminal, which stores your order until the worker in the kitchen picks it up.

Conclusion

In summary, there are many different concepts to implement communication between components and none of them is universally superior. The choice between asynchronous or synchronous, point-to-point or publish-subscribe messaging depends upon the specific use case at hand. Ultimately, the highest objective remains to ensure the timely delivery of the service to the customer.