The Advanced Features Of Azure Service Bus

“Messaging” that’s one of the common requirements for any organization using multiple applications and has the need to transfer data between them. According to me, messaging is the most useful technique providing a lot of benefits to cloud-based applications.

If you ask me to point out one advantage now, the first thing that comes to my mind is “decoupling” which means both the sender and receiver don’t have to be online or available at the same time to carry out a successful message transfer.

So understanding the demand for messaging, Microsoft Azure launched Service Bus in 2011 to serve as a “Message Bus” or “Message Broker”.

Azure Service Bus

As mentioned, Azure Service Bus is an enterprise integration message broker that enables message transfer in a secured and reliable way. By default, Service Bus works in the push-pull model where the sender pushes the message and the receiver pulls it. The message format can be anything among JSON, XML, and Text.

Asynchronous messaging, Decoupling applications, and Load Balancing are some of the important messaging scenarios that Service Bus supports. Apart from that, there are 2 important concepts that you have to know – Service Bus Queues and Topics

How Service Bus Queues and Topics Work?

In the case of a Queue, it will be FIFO (First In, First Out) logic where at one end the sender sends a message which is then retrieved in the same order by the receiver.

Note: you can have only one receiver and the Queues will store messages until the receiver is available to process them i.e., the message will be delivered only when you pull them.

But, do you want to have multiple receivers at the other end? In this scenario, you should opt for the Topic and Subscription model.

Here the message will be first published to a Topic and multiple subscribers can subscribe to that Topic and so whenever a message gets published, these subscribers will be able to get a copy of that message. It’s possible to add filters to the Subscriptions to read-only specific messages.

Note: A single Topic can have multiple Subscriptions, but a Subscription can be associated with only one Topic.

Service Bus also has another rich set of communication features which I will try to elaborate on in this blog.

Advanced Features of Service Bus

Sessions and FIFO

First let’s say, the sender sends a bunch of messages, as shown below the blue ones and the green ones are two different sessions as they have unique session ids. The sender can actually set these as a property on the message that is being sent.

Now on the back end, two virtual Queues are created, one with session-id = 1 and the other with session-id =2. So when the receiver comes in, they no longer can peek-lock a message, rather they set it on the session id. This means that the entire session is blocked by a receiver, and it receives the message one after the other, in the first in and first out order.

This is how sessions in Service Bus works.

Auto Forwarding

With this, you can forward messages from one Queue to another Queue/Topic by chaining Service Bus entities. Auto forwarding is available only in the Standard and Premium Service Bustiers.

It can be used in the following scenarios,

• • Decoupling message senders and receivers
  • Scale-out an individual Topic (if >2000 Subscriptions are needed)
  • Enable duplicate detection on previously crested entities

Scheduled Messages

There are times where the sender wants to control the narrative of how and when the message processing should happen. And that’s when this feature can be of great help.

If a sender schedules a message, it will be sent to Service Bus Queues immediately but will be made visible to the receiver only after a particular time, it could either be a specific date in the future, 5 days or 5 minutes from now.

Deferred Messages

There is this main difference between scheduling and deferring, in scheduling the message is delivered at the specified time but in defer mode, the Service Bus holds on to the message until we it’s ready for further processing.

This is a useful feature in situations where processing a message is tough because a particular resource for handling that message seems temporarily unavailable.

When deferred, Service Bus provides a sequence number to those messages and it’s the only way through which the deferred messages can be accessed.

Dead-letter Queues

If the messages in your Service Bus don’t get processed further for some reason, then it directly goes into something called Dead-lettered Queue, where the messages are stored until you manually remove it later or reprocess it again.

This helps to avoid message loss even if the message does not reach the receiver at the expected time.

Also, there are so many reasons for a message to get dead-lettered, for instance, faulty message, dependent service is not available, etc.

Duplicate Detection

It prevents duplication of messages caused due to application or network failures. When you enable duplicate detection for a particular Queue or Topic, every message that goes in there is provided with a Message-Id where the duplicate copies are identified and discarded using that Id.

So for this, no other parts of the message will be checked other than the Message Ids and currently, the Ids can only be retained for a maximum of 7 days.

Auto-delete on idle

This feature is handy when you don’t want to manually check and clean up the unused Service Bus entities. You can set up the time interval (minimum 5 minutes) and if the entities are idle for that time period, it gets automatically deleted.

Availability Zones

Availability zones are available only in the premium tier of Service Bus and with this enabled, whenever a message is being sent, it will be replicated thrice by default. Those 3 replicas will be there on 3 different data centers within the same region.

So, it easily provides fault tolerance between the same data center regions.

Geo-Disaster Recovery

This feature provides fault tolerance across different data center regions. Here 2 separate premium namespaces (primary and secondary) are provisioned in 2 different regions and then paired using a connection string.

It ensures that all of your metadata including Queues, Topics, Subscriptions, filters, etc., are always in sync with the secondary namespace.

With all these features, messaging between cloud applications or services is no more serious concern. In addition to that, we have also got Service Bus Explorer which makes message processing and Service Bus management a bit easier.

But still, there are a few drawbacks in Service Bus Explorer-like lack of monitoring, does not support repairing and resubmitting dead-lettered messages, etc.

So check out an alternative that you can consider for both managings and monitoring your production level Service Bus namespace.

Serverless360

Here is how Serverless360 differs from Service Bus Explorer,

• Serverless360 provides complete visibility into the Service Bus messages
• Customizable dashboards for data visualization and provide real-time insights on your Service Bus and its messages.
• If your messages are dead-lettered, get to view the detailed description for the reasons for dead lettering.
• It allows to modify the content of the dead-lettered messages and to resubmit it again for a successful transfer.
• If needed, you can also process hundreds and thousands of messages without any manual intervention.
• Out-of-the-box monitoring support for Service Bus Queues and Topics.

Conclusion

Hope the blog would have given you a better understanding of how Service Bus works and some of its advanced features that help in your day-to-day cloud-based message transfer activities. Also, don’t forget to check out Serveress360 to experience an exceptional way of managing and monitoring the Azure Service Bus.

Follow TechWaver for more informative articles.