Azure Service Bus

Azure Service Bus

Azure Service Bus is a robust cloud messaging service built to enhance communication between applications and services within an organization.

It decouples applications and services, allowing message producers and consumers to operate independently without needing to be online simultaneously, thereby improving system resilience and scalability.

Being a Paas (Platform As A Service), users don`t need to worry about the infrastructure as the Azure takes care of it. For instance:

  • Hardware failures
  • Updating the OS
  • Managing the disk space
  • Handling backups

This solution enables businesses to exchange messages seamlessly, ensuring reliable and asynchronous communication across different system components. With features like message queues, topics, and subscriptions, Azure Service Bus facilitates efficient message routing and load balancing, supporting more scalable and streamlined application architectures.

Data and Messages

Data is exchanged between various applications and services through messages.

A message serves as a container that includes both metadata and the data itself. Data can be of any format - encoded , pdf, text, XML,Json etc.,

ASB covers the following messaging scenarios

  • Messaging. Transfer business data, such as sales or purchase orders, journals, or inventory movements.
  • Decouple applications.Sender and Receiver need not be online during the message transmission
  • Load balancing. Multiple consumers can read the message from queue or topic simultaneously, retaining the ownership of the messages.
  • Transactions. Allows to consolidate all the operations in one transaction - Picking the message, moving to another queue, retrying the message etc can be in one transaction. The end response will be visible only when the E2E process is success.
  • Message sessions. Strict message ordering or message deferral.


Service Bus Concepts:

Queues:

  • First In, First Out (FIFO) message delivery to one or more consumers
  • Receivers typically receive and process messages in the order in which they were added to the queue.
  • One message consumer receives and processes each message
  • Producers (senders) and Consumers (receivers) don't have to send and receive messages at the same time, because messages are stored durably in the queue. Furthermore, the producer doesn't have to wait for a reply from the consumer to continue to process and send messages.
  • Messages are sent based on the timestamp arrival
  • They are held durably on the storage if the zone redundancy is enabled.

Article content
Queue FIFO

Topics

While a queue is used for one to one communication, topics are useful in publish-subscribe scenarios.

One Topic can have multiple subscriptions . Subscription can be thought of a virtual queue . They hold the messges until the expiry limit is set.

A subscription can also have a filter to define the condition of the message it should receive.


Article content
TOPICS and SUBSCRIPTIONS


Namespaces

Container for all the Service Bus entities.

It can have multiple queues and multiple topics.

Advanced features:

Message sessions:

Using Sessions, FIFO is guaranteed for Queues and Topics. This also helps to implement request-response pattern.

Auto-forwarding:

When enabled, the message in the queue is automatically forwarded to another queue using FIFO order. The queues are in the same namespace and not from another namespace.

Dead-Lettering Queue or Topic:

Secondary subqueue,

DLQ holds messages that can't be delivered to any receiver, or messages that can't be processed. These can be later removed to investigate.

Scheduled delivery:

Submit messages to a queue or topic for delayed processing.

Message deferral:

If the message need not be processed due to special circumstances in the application, it can be deferred to a later stage. So the message remains in the queue or topic but set aside for later processing.

Transactions:

Grouping one or more operations in a single transaction together in a scope.

Filters and actions:

Subscriptions in the topic can define which message they wanted to receive from the topic. This is implemented using the Filter - 2 types SQL and Correlation Filter.

Auto-delete on idle:

The queue will be deleted after specific idle time. This is useful when there is a traffic on the queue.

Duplicate detection:

If the same message is sent again during retry, this feature discards the duplicate message ensuring the consumer doesnt receive the same message.

Batch delete of Messages:

Delete the expired messages in batch.

Security:

Saas, RBAC and managed identities.

Geo-disaster recovery:

During the downtime of azure datacenter, this feature enables the data processing to continue

in a different region.



To view or add a comment, sign in

Others also viewed

Explore topics