Making Connections Azure Service Bus Making Connections With Azure Service Bus

In the life of every IT consultant comes a time to integrate one system with another. Finding the best way to integrate between two different services is very complicated and can generate many worries even before you start.

But you don’t have to be alone in this process. There is a great tool out there that serves exactly that purpose. Today, I would like to introduce Azure Service Bus. In this article, I will describe what it is and how it works.

What is Azure Service Bus?

First, I would like to explain the term “service bus”. It is a layer which propagates data to other systems or applications, with the use of messages.

Ok, but what is this “message” then? Let’s refer to Microsoft documentation:

You can see how service bus interacts with other services on the diagram below.

Figure 1. Service Bus concept diagram

Microsoft has implemented this tool on its Azure platform and named it – quite appropriately – Azure Service Bus. It is a highly scalable service which can handle asynchronous messaging and sending raw data to decoupled systems. Because it’s available in a Platform as a Service (PaaS) model, you don’t have to worry about servers and configuration.

You can manage your service via the Azure Portal, where you can create everything you need to work with it.

Figure 2. Azure Service Bus in Azure Portal

Now that we know what the main concept of Azure Service Bus is, we can move on to entities and messaging types.

Messaging types

Azure Service Bus uses two kinds of messaging functionalities. The first and most popular is Brokered Messaging.

Brokered Messaging supports the scenario of truly temporal, decoupled systems where it is not necessary for the producer (sender) and consumer (receiver) to be online all the time. All messages are sent when the producer is online and delivered to the consumer when they are online. It is the asynchronous messaging approach.

What is most important about this feature? This setup guarantees that each message will be delivered or marked as dead-letter and stored in the service bus.

The second messaging kind is Relay. It is a centralized service that supports a variety of different transport protocols and web service standards. This means that you can build a communication layer between the service bus and other applications, and decide how messages should be delivered to them.

Relay supports traditional one-way messaging, request/response messaging and peer-to-peer messaging. Consequently, using it you can build a bridge between Azure and on-premise solutions. The next big advantage is that you can create a “bounce-back” message or send it back to the service bus.

Types of entities

Now we can move on to describing particular features. The key functions I will focus on are Queue and Topics with Subscriptions, which are related to Brokered Messaging.

Queue

If we are implementing one-way messaging and we want to ensure that only one consumer can read the message, or we want to push data to another system without any magic, we should use the Queue function.

Queue assumes that the message will only be sent to one consumer (receiver).

Figure 3. Architecture of the Queue function

However, if we want to distribute one message many times to different applications, the best way for that will be using Topics and Subscriptions. Ok, but what are they?

Topic and Subscriptions

Topics and Subscriptions constitute a publish-subscribe pattern allowing the same message to be processed by many subscriptions. More information about the publish-subscribe pattern you can find under this link.

Subscription is somewhat similar to Queue. When the topic gets the message, it copies it to each subscription separately and distributes to other systems.

Let’s stay on Subscriptions a little longer because they have an incredibly useful feature called Rule. But what are Rules?

A Rule is a set of conditions that decide which message to enter into a subscription. We can manipulate the message once it meets those conditions. It can be very helpful to make your messaging flow more precise.

Figure 4. Topic and Subscriptions Architecture

Summary

Microsoft did very good work with adding Azure Service Bus to their offering. The result is a highly scalable service where you don’t have to care about infrastructure, it just works. It sends the messages asynchronously, which ensures greater reliability.

As a consultant, you can select from different approaches to using service bus, because you can choose between Relay, Queue or Topics with Subscriptions to send the messages. Consequently, you can implement the solution that you want.

You should now have a better idea of what a service bus is, how Azure Service Bus works and what are its components. However, this is only the beginning! There is lots more to know about use cases, additional features and pricing, which I will cover in the future.
Can’t wait? Get in touch now!