Simplifying IT, Empowering Businesses

Are you looking to link two or more applications, services, or devices on the cloud? Microsoft Azure Service Bus is your solution. Service Bus is used for temporarily storing messages or data.

It will keep the message or data until it is consumed by someone else. Service Bus is mainly connected with two types of applications; the producer and the consumer. The producer (Sender) sends the messages or data into the service bus. And the consumer consumes those messages or data stored in the service bus.

The service bus messages are consumed in the FIFO order, which means the first inserted message will be consumed first. The notes automatically get deleted once their respective consumer consumes them.

Type of Service Bus

There are two types of service buses in Microsoft Azure:

Queue Service Bus and Topic Service Bus. We shall discuss both types in detail.

1. Queue Service Bus:

Queue service bus has only one consumer. So, the data sent by the producer is consumed by only one consumer, and once it is received, the message gets deleted from the service bus.

2. Topic Service Bus:

The topic service bus can have many consumers. So, the producer’s data gets consumed by several consumers, and once all the subscribed consumers consume it, the message gets deleted from that topic.

So, the topic service bus can have multiple subscriptions, and each subscription has its consumer (Receiver.) Once there is data inside the topic, it will be sent to respective subscribers automatically. Once it is read or processed by all, the subscriber messages will get deleted automatically.

You can also apply some rules on subscriptions and filter the data if you want.

Use: 

When the client wants to communicate between two applications devoid of any dependency, this service can be beneficial. Suppose you have two isolated services or applications and you want to exchange the data between these two for further data processing; you may leverage the service bus for the same.

Here is a typical scenario that describes two standalone applications communicating with each other via service bus.

By making this, application A and application B can work separately without any dependency on each other. This way, we can build functionalities wherein the microservices are independent, and the service bus topic or queue can conduct all the communication between them.

It can also help if you wish to carry some heavy processing tasks in the APIs. One can separate those tasks by creating one application that will help conduct the studies independently by subscribing to the relevant service bus topic or queue to avoid load on the main application and perform faster.

Supported Languages:

Almost all the enterprise-level languages are supported by the service bus by which you can send or receive the messages.

The Following are lists of the languages that are supported by the service bus.

Java, C#, F#, VB, C/C++, JavaScript, Node, Python, Ruby, PHP, GO.

Integration Platform:

Followings are the supported integration platforms to send or receive messages on the service bus.

• Azure Function App
• Event Grid
• Logic App
• Dynamic 365
• Azure Stream Analysis
• Power Platform

When to use Event Hub and Event Grid?

Event Hub

Azure Event Hub is a messaging solution for processing big data where millions of records are generated per second and serve minimum latency time.

The figure shows that the Event Hub has a large number of producers and consumers, and all the data is stored in the partition and consumed by the consumers according to the cell and consumer Types.

Event Hub is used when anyone wants to have a big-data streaming platform to fulfill the high-volume request and streaming-related stuff with lower latency. The typical use of the Event Hub is Telemetry and other distributed data streaming services.

Event Gird

Azure Event Grid is a messaging solution used to trigger processes when certain events occur without prioritizing the sequence.

For example, when you have inserted an image into the blog storage and wish to start processing the same, you can send an event containing the information that some new image has been uploaded on blog storage. The consumer will begin processing the image.

We can conclude that if anyone wants to implement a messaging solution to communicate between two applications with proper message ordering, one may use Service Bus as the solution.

One may leverage the Event Hub if the data is in massive amounts and one wishes to process the same in minimum latency. You may leverage the Event Grid when you want to communicate that an event has occurred without prioritizing the order of events with different services or projects.