AZURE SERVICE BUS

Azure Service Bus is a cloud messaging service to connect applications, services, and devices running on cloud to connect with other applications or services. It is developed and managed by Microsoft. Its main agenda is to make communication easier, by being the communication facilitator between two or more parties when they want to exchange information with one another. It is a fully-managed service that eliminates the burden of server management and licensing. It also supports client libraries for .NET, Java, JMS, etc. Service Bus can be created using Microsoft Azure Portal or directly through C# code. A message is transmitted in binary format and can contain JSON, XML or plain text.

The key features of Azure Service Bus are:

Multi-tenant
Highly reliable
Asynchronous
Flexible
Brokered messaging between client and server
Structured FIFO messaging
Publish/Subscribe capability

Multi-Tenant Service Bus environment:

A developer creates a namespace that would be the container for Service Bus artifacts in the cloud and defines the communication mechanisms needed within the namespace. This service can then be shared among multiple users.

Highly-reliable:

It is highly reliable as it would wait to deliver the messages, even when the other party is offline.

Asynchronous & Flexible:

We can send messages to multiple users at a time, schedule them or send a bunch of messages in a single batch at a selected interval.

Brokered messaging:

It acts as a broker as it stores the messages until they are received by the recipient.

Structured FIFO messaging:

We can implement the messaging service as FIFO by using sessions, which enable ordered handling of related messages.

Publish/Subscribe capability:

We can publish a message to a topic and other applications/services can act as subscribers which can subscribe and receive a copy of the messages being published.

The service bus can be implemented by different communication mechanisms, Queues, and Topics. Namespace, an application container is also the container for all the messaging components. We can have multiple queues and topics in a single namespace.

Queues:
Messages are sent to and retrieved from a queue in a first-in, first-out manner. Queues store messages until being received by the receiving application and are processed. The messages are delivered in pull mode, that is they are delivered only when requested by the recipient and are time-stamped at the time of arrival. Queues allow only unidirectional communication and all the messages are received by a single recipient. It is used for point-to-point communication. Every individual message has two parts, a set of properties and the message payload. A receiver can read the message in two different ways, Receive & delete (receiving a message from the queue and deleting it immediately), and Peek Lock (removing the message from the queue, and locking it so that making it invisible for others).
azure service bus 1

Topics:
They help in one-way communication but through the publish/subscribe scenario. They also help to filter the messages to match specific criteria of subscribers or can receive a copy of all the messages being published to the topic. Topics can have multiple independent subscriptions and also imply the function of expiring or autodelete after a certain period of time.
azure service bus 2

Some of the advanced features of Azure Service Bus are:

Auto Forwarding
If multiple queues and/or topics are part of a single namespace they can be chained to another queue or topic. The service bus automatically removes the messages from the first queue or subscription and adds them to the second chained queue or topic.
Messaging Sessions
Message sessions enable us to implement the messaging service as structured first in, first out service which helps in ordered handling of related messages which are otherwise in unbounded sequences.
Dead-Letter Queue
Service Bus supports a dead-letter queue (DLQ), which is a sub-queue provided by queues or topics. The dead-letter queue is created by itself and cannot be deleted or also cannot be managed separately as an independent identity. It holds the messages that are not delivered or are not processed. These messages can be removed from DLQ and be inspected. These messages can then be resubmitted after resolving the error or can be processed as required.
When a message is moved to DLQ by the broker, two properties are added to the message, DeadLetterReason, and DeadLetterErrorDescription.
Batching
This enables a queue or topic to delay the sending of a message for a certain period of time. So, if additional messages are being sent within this time period, it transmits all messages in a single batch. It is available only for Asynchronous Send & Complete operations, and can also combine multiple requests into a single request. There is a batch interval of 20ms by default, but can be changed by the BatchFlushInterval property.
Scheduled Delivery
This helps in the delayed submission of messages at a scheduled time. The scheduled messages are not passed on to the queue until the defined time and can be canceled/deleted before that. The messages can only be enqueued once and thus, do not support recurring schedules.
Autodelete on idle
It enables us to specify a timespan after which the queue can be deleted if it is idle. The minimum duration is 5 minutes.
Filtering & Actions
As topics allow subscribers to receive a copy of the subscription message, but not always all the messages should be received, so we can set some rules and filters which are in the form of named subscription rules. Each rule consists of a condition that selects a particular message and action related to it. If the rule condition is matched, a copy of the message is produced by the subscription. Service Bus supports three filter conditions:
- Boolean Filters
- SQL Filters
- Correlation Filters
These filters just evaluate the message properties and not the message body.
Message Deferral
When the message is not able to be processed due to some special circumstances, it is deferred to a later point. The message still remains inside the queue or topic but is set aside until the broker is able to process it.
Transactions
A transaction groups all the operations into a single transaction, but this ensures that all operations in a group would have a result jointly, that is they succeed or fail jointly. This makes them as atomic transactions as they are tightly bound with one another inside a transaction.
Duplicate Detection
If the application fails after sending a message due to a fatal error, then the restarted instance might try to resend the previous message, as it did not receive any acknowledgment from the client. Hence, the application will resend the same message with the same message ID again and ensure that previous duplicates of this message are removed from the queue or topics, and if already received then seeing the same ID is not being processed again.
Security Protocols
Azure Service Bus supports standard AMQP 1.0 and HTTP/REST protocols and also security protocols such as Shared Access Signatures (SAS), Role-Based Access Control (RBAC) and Managed identities for Azure resources.
Geo-disaster recovery
If a datacenter experiences downtime, then it enables the data to be processed continuously without any interruption at a different location or datacenter. It only works in the case of disasters, and not small outages. Geo-disaster recovery is supported at the namespace level.