Service Bus ¶

Tldr

Azure Service Bus is a fully-managed enterprise message broker with message queues and publish-subscribe topics (in a namespace).
Azure Service Bus' primary protocol is AMQP 1.0 and it can be used from any AMQP 1.0 compliant protocol client.
JMS 2.0 compliant
Polyglot Azure SDK and cross-platform client support

Demo's¶

Adding message to the queue 🎥¶

Architecture 🏛️¶

Authorization 🔐¶

Concepts¶

Messages ✉️¶

Data is transferred between different applications and services using messages. Messages can be in JSON, XML, Apache Avro, Plain Text format.

Queues ䷄¶

Messages are sent to and received from queues.
Queues store messages until the receiving application is available to receive and process them.
Once the broker accepts the message, the message is always held durably in triple-redundant storage, spread across availability zones if the namespace is zone-enabled.
Messages are delivered in pull mode, only delivering messages when requested.

Dead letter queue and rejected queues are shown below

Topics 📋¶

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

Subscriptions ✅¶

Subscriptions are named entities. Subscriptions are durable by default, but can be configured to expire and then be automatically deleted.

Define Filters and rules

You can define rules on a subscription. A subscription rule has a filter to define a condition for the message to be copied into the subscription and an optional action that can modify message metadata.

Subscribers can define which messages they want to receive from a topic. These messages are specified in the form of one or more named subscription rules. Each rule consists of a filter condition that selects particular messages, and optionally contains an action that annotates the selected message.

Namespaces 🪐¶

A Service Bus namespace is your own capacity slice of a large cluster made up of dozens of all-active virtual machines.
Multiple queues and topics can be in a single namespace, and namespaces often serve as application containers.

Partitioned 🗂️¶

Service Bus partitions enable queues and topics, or messaging entities, to be partitioned across multiple message brokers and messaging stores. Partitioning means that the overall throughput of a partitioned entity is no longer limited by the performance of a single message broker or messaging store. In addition, a temporary outage of a messaging store does not render a partitioned queue or topic unavailable

Message sessions 📨¶

To realize a first-in, first-out (FIFO) guarantee in processing messages in Service Bus queue or subscriptions, use sessions. Sessions can also be used in implementing request-response patterns. The request-response pattern enables the sender application to send a request and provides a way for the receiver to correctly send a response back to the sender application.

Auto-forwarding 📤¶

The Auto-forwarding feature enables you to chain a queue or subscription to another queue or topic that is part of the same namespace. When auto-forwarding is enabled, Service Bus automatically removes messages that are placed in the first queue or subscription (source) and puts them in the second queue or topic (destination).

Dead-lettering 💀¶

Service Bus queues and topic subscriptions provide a secondary subqueue, called a dead-letter queue (DLQ). The dead letter queue holds messages that can't be delivered to any receiver, or messages that can't be processed. You can then remove messages from the DLQ and inspect them.

Auto-delete on idle ❌¶

Auto-delete on idle enables you to specify an idle interval after which the queue is automatically deleted. The interval is reset when there's traffic on the queue. The minimum duration is 5 minutes.

Scheduled delivery 🚚¶

You can submit messages to a queue or topic for delayed processing; for example, to schedule a job to become available for processing by a system at a certain time