What is Azure Service Bus?

Microsoft Azure Service Bus is a fully managed enterprise message broker with message queues and publish-subscribe topics. Service Bus is used to decouple applications and services from each other, providing the following benefits:

• Load-balancing work across competing workers
• Safely routing and transferring data and control across service and application boundaries
• Coordinating transactional work that requires a high-degree of reliability

Overview

Data is transferred between different applications and services using messages. A messageВ is aВ container decorated with metadata, and contains data. The data can be any kind of information, including structured data encoded with the common formats such as the following ones: JSON, XML, Apache Avro, Plain Text.

Some common messaging scenarios are:

Messaging. Transfer business data, such as sales or purchase orders, journals, or inventory movements.

Decouple applications. Improve reliability and scalability of applications and services. Producer and consumer don’t have to be online or readily available at the same time. The load is leveled such that traffic spikes don’t overtax a service.

Load Balancing. Allow for multiple competing consumers to read from a queue at the same time, each safely obtaining exclusive ownership to specific messages.

Topics and subscriptions. Enable 1:n relationships between publishers and subscribers, allowing subscribers to select particular messages from a published message stream.

Transactions. Allows you to do several operations, all in the scope of an atomic transaction. For example, the following operations can be done in the scope of a transaction.

1. Obtain a message from one queue.
2. Post results of processing to one or more different queues.
3. Move the input message from the original queue.

The results become visible to downstream consumers only upon success, including the successful settlement of input message, allowing for once-only processing semantics. This transaction model is a robust foundation for the compensating transactions pattern in the greater solution context.

Message sessions. Implement high-scale coordination of workflows and multiplexed transfers that require strict message ordering or message deferral.

If you’re familiar with other message brokers like Apache ActiveMQ, Service Bus concepts are similar to what you know. As Service Bus is a platform-as-a-service (PaaS) offering, a key difference is that you don’t need to worry about the following actions. Azure takes care of those chores for you.

• Placing logs and managing disk space
• Handling backups
• Keeping the operating systems or the products patched
• Worrying about hardware failures
• Failing over to a reserve machine

Compliance with standards and protocols

The primary wire protocol for Service Bus is Advanced Messaging Queueing Protocol (AMQP) 1.0, an open ISO/IEC standard. It allows customers to write applications that work against Service Bus and on-premises brokers such as ActiveMQ or RabbitMQ. The AMQP protocol guide provides detailed information in case you want to build such an abstraction.

Service Bus Premium is fully compliant with the Java/Jakarta EE Java Message Service (JMS) 2.0 API. And, Service Bus Standard supports the JMS 1.1 subset focused on queues. JMS is a common abstraction for message brokers and integrates with many applications and frameworks, including the popular Spring framework. To switch from other brokers to Azure Service Bus, you just need to recreate the topology of queues and topics, and change the client provider dependencies and configuration. For an example, see the ActiveMQ migration guide.

Concepts and terminology

This section discusses concepts and terminology of Service Bus.

Namespaces

A namespace is a container for all messaging components. Multiple queues and topics can be in a single namespace, and namespaces often serve as application containers.

A namespace can be compared to a «server» in the terminology of other brokers, but the concepts aren’t directly equivalent. A Service Bus namespace is your own capacity slice of a large cluster made up of dozens of all-active virtual machines. It may optionally span three Azure availability zones. So, you get all the availability and robustness benefits of running the message broker at enormous scale. And, you don’t need to worry about underlying complexities. Service Bus is «serverless» messaging.

Queues

Messages are sent to and received from queues. Queues store messages until the receiving application is available to receive and process them.

Messages in queues are ordered and timestamped on arrival. Once accepted by the broker, the message is always held durably in triple-redundant storage, spread across availability zones if the namespace is zone-enabled. Service Bus never leaves messages in memory or volatile storage after they’ve been reported to the client as accepted.

Messages are delivered in pull mode, only delivering messages when requested. Unlike the busy-polling model of some other cloud queues, the pull operation can be long-lived and only complete once a message is available.

Topics

You can also use topics to send and receive messages. While a queue is often used for point-to-point communication, topics are useful in publish/subscribe scenarios.

Topics can have multiple, independent subscriptions, which attach to the topic and otherwise work exactly like queues from the receiver side. A subscriber to a topic can receive a copy of each message sent to that topic. Subscriptions are named entities. Subscriptions are durable by default, but can be configured to expire and then be automatically deleted. Via the JMS API, Service Bus Premium also allows you to create volatile subscriptions that exist for the duration of the connection.

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. For more information, see Topic filters and actions. This feature is useful in the following scenarios:

• You don’t want a subscription to receive all messages sent to a topic.
• You want to mark up messages with extra metadata when they pass through a subscription.

Advanced features

Service Bus includes advanced features that enable you to solve more complex messaging problems. The following sections describe several of these features.

Message sessions

To create a first-in, first-out (FIFO) guarantee in Service Bus, use sessions. Message sessions enable exclusive, ordered handling of unbounded sequences of related messages. To allow for handling sessions in high-scale, high-availability systems, the session feature also allows for storing session state, which allows sessions to safely move between handlers. For more information, see Message sessions: first in, first out (FIFO).

Autoforwarding

The autoforwarding feature chains a queue or subscription to another queue or topic inside the same namespace. When you use this feature, Service Bus automatically moves messages from a queue or subscription to a target queue or topic. All such moves are done transactionally. For more information, see Chaining Service Bus entities with autoforwarding.

Dead-letter queue

All Service Bus queues and topic subscriptions have an associated dead-letter queue (DLQ). A DLQ holds messages that meet the following criteria:

• They can’t be delivered successfully to any receiver.
• They timed out.
• They’re explicitly sidelined by the receiving application.

Messages in the dead-letter queue are annotated with the reason why they’ve been placed there. The dead-letter queue has a special endpoint, but otherwise acts like any regular queue. An application or tool can browse a DLQ or dequeue from it. You can also autoforward out of a dead-letter queue. For more information, see Overview of Service Bus dead-letter queues.

Scheduled delivery

You can submit messages to a queue or topic for delayed processing, setting a time when the message will become available for consumption. Scheduled messages can also be canceled. For more information, see Scheduled messages.

Message deferral

A queue or subscription client can defer retrieval of a received message until a later time. The message may have been posted out of an expected order and the client wants to wait until it receives another message. Deferred messages remain in the queue or subscription and must be reactivated explicitly using their service-assigned sequence number. For more information, see Message deferral.

Batching

Client-side batching enables a queue or topic client to accumulate a set of messages and transfer them together. It’s often done to either save bandwidth or to increase throughput. For more information, see Client-side batching.

Transactions

A transaction groups two or more operations together into an execution scope. Service Bus allows you to group operations against multiple messaging entities within the scope of a single transaction. A message entity can be a queue, topic, or subscription. For more information, see Overview of Service Bus transaction processing.

Autodelete on idle

Autodelete on idle enables you to specify an idle interval after which a queue or topic subscription is automatically deleted. The minimum duration is 5 minutes.

Duplicate detection

The duplicate detection feature enables the sender to resend the same message again and for the broker to drop a potential duplicate. For more information, see Duplicate detection.

Geo-disaster recovery

When an Azure region experiences downtime, the disaster recovery feature enables data processing to continue operating in a different region or data center. The feature keeps a structural mirror of a namespace available in the secondary region and allows the namespace identity to switch to the secondary namespace. Already posted messages remain in the former primary namespace for recovery once the availability episode subsides. For more information, see Azure Service Bus Geo-disaster recovery.

Security

Service Bus supports standard AMQP 1.0 and HTTP or REST protocols and their respective security facilities, including transport-level security (TLS). Clients can be authorized for access using Shared Access Signature or Azure Active Directory role-based security.

For protection against unwanted traffic, Service Bus provides security features such as IP firewall and integration with virtual networks.

Client libraries

Fully supported Service Bus client libraries are available via the Azure SDK.

Azure Service Bus’ primary protocol is AMQP 1.0 and it can be used from any AMQP 1.0 compliant protocol client. Several open-source AMQP clients have samples that explicitly demonstrate Service Bus interoperability. Review the AMQP 1.0 protocol guide to understand how to use Service Bus’ features with AMQP 1.0 clients directly.

Language	Library
Java	Apache Qpid Proton-J
C/C++	Azure uAMQP C, Apache Qpid Proton-C
Python	Azure uAMQP for Python, Apache Qpid Proton Python
PHP	Azure uAMQP for PHP
Ruby	Apache Qpid Proton Ruby
Go	Azure Go AMQP, Apache Qpid Proton Go
C#/F#/VB	AMQP .NET Lite, Apache NMS AMQP
JavaScript/Node	Rhea

Integration

Service Bus fully integrates with many Microsoft and Azure services, for instance:

Next steps

To get started using Service Bus messaging, see the following articles:

• To compare Azure messaging services, see Comparison of services.
• Try the quickstarts for .NET, Java, or JMS.
• To manage Service Bus resources, see Service Bus Explorer.
• To learn more about Standard and Premium tiers and their pricing, see Service Bus pricing.
• To learn about performance and latency for the Premium tier, see Premium Messaging.

—>

Azure Service Bus — Frequently asked questions (FAQ)

This article discusses some frequently asked questions about Microsoft Azure Service Bus. You can also visit the Azure Support FAQs for general Azure pricing and support information.

General questions about Azure Service Bus

What is Azure Service Bus?

Azure Service Bus is an asynchronous messaging cloud platform that enables you to send data between decoupled systems. Microsoft offers this feature as a service, which means that you don’t need to host your own hardware to use it.

What is a Service Bus namespace?

A namespace provides a scoping container for addressing Service Bus resources within your application. Creating a namespace is necessary to use Service Bus and is one of the first steps in getting started.

What is an Azure Service Bus queue?

A Service Bus queue is an entity in which messages are stored. Queues are useful when you have multiple applications, or multiple parts of a distributed application that need to communicate with each other. The queue is similar to a distribution center in that multiple products (messages) are received and then sent from that location.

What are Azure Service Bus topics and subscriptions?

A topic can be visualized as a queue and when using multiple subscriptions, it becomes a richer messaging model; essentially a one-to-many communication tool. This publish/subscribe model (or pub/sub) enables an application that sends a message to a topic with multiple subscriptions to have that message received by multiple applications.

What is a partitioned entity?

A conventional queue or topic is handled by a single message broker and stored in one messaging store. Supported only in the Basic and Standard messaging tiers, a partitioned queue, or topic is handled by multiple message brokers and stored in multiple messaging stores. This feature means that the overall throughput of a partitioned queue or topic is no longer limited by the performance of a single message broker or messaging store. Also, a temporary outage of a messaging store doesn’t render a partitioned queue or topic unavailable.

Ordering isn’t ensured when using partitioned entities. In the event that a partition is unavailable, you can still send and receive messages from the other partitions.

Partitioned entities are no longer supported in the Premium SKU.

Where does Azure Service Bus store data?

Azure Service Bus standard tier utilizes Azure SQL Database for its backend storage layer. For all regions except Brazil South and Southeast Asia, the database backup is hosted in a different region (usually the Azure paired region). For the Brazil south and Southeast Asia regions, database backups are stored in the same region to accommodate data-residency requirements for these regions.

Azure Service Bus premium tier stores metadata and data in regions that you select. When geo-disaster recovery is set up for an Azure Service Bus premium namespace, the metadata is copied over to the secondary region that you select.

What ports do I need to open on the firewall?

You can use the following protocols with Azure Service Bus to send and receive messages:

• Advanced Message Queuing Protocol 1.0 (AMQP)
• Hypertext Transfer Protocol 1.1 with TLS (HTTPS)

See the following table for the outbound TCP ports you need to open to use these protocols to communicate with Azure Service Bus:

Protocol	Port	Details
AMQP	5671	AMQP with TLS. See AMQP protocol guide
HTTPS	443	This port is used for the HTTP/REST API and for AMQP-over-WebSockets

The HTTPS port is generally required for outbound communication also when AMQP is used over port 5671, because several management operations performed by the client SDKs and the acquisition of tokens from Azure Active Directory (when used) run over HTTPS.

The official Azure SDKs generally use the AMQP protocol for sending and receiving messages from Service Bus.

The AMQP-over-WebSockets protocol option runs over port TCP 443 just like the HTTP/REST API, but is otherwise functionally identical with plain AMQP. This option has higher initial connection latency because of extra handshake roundtrips and slightly more overhead as tradeoff for sharing the HTTPS port. If this mode is selected, TCP port 443 is sufficient for communication. The following options allow selecting the AMQP WebSockets mode.

Language	Option
.NET (Azure.Messaging.ServiceBus)	Create ServiceBusClient using a constructor that takes ServiceBusClientOptions as a parameter. Set ServiceBusClientOptions.TransportType to ServiceBusTransportType.AmqpWebSockets
.NET (Microsoft.Azure.ServiceBus)	When creating client objects, use constructors that take TransportType, ServiceBusConnection, or ServiceBusConnectionStringBuilder as parameters. For the construction that takes transportType as a parameter, set the parameter to TransportType.AmqpWebSockets. For the constructor that takes ServiceBusConnection as a parameter, set the ServiceBusConnection.TransportType to TransportType.AmqpWebSockets. If you use ServiceBusConnectionStringBuilder , use constructors that give you an option to specify the transportType .
Java (com.azure.messaging.servicebus)	When creating clients, set ServiceBusClientBuilder.transportType to AmqpTransportType.AMQP.AMQP_WEB_SOCKETS
Java (com.microsoft.azure.servicebus)	When creating clients, set transportType in com.microsoft.azure.servicebus.ClientSettings to com.microsoft.azure.servicebus.primitives.TransportType.AMQP_WEB_SOCKETS
JavaScript	When creating Service Bus client objects, use the webSocketOptions property in ServiceBusClientOptions.
Python	When creating Service Bus clients, set ServiceBusClient.transport_type to TransportType.AmqpOverWebSocket

The older WindowsAzure.ServiceBus package for the .NET Framework has an option to use the legacy «Service Bus Messaging Protocol» (SBMP), also referred to as «NetMessaging». This protocol uses TCP ports 9350-9354. The default mode for this package is to automatically detect whether those ports are available for communication and will switch to WebSockets with TLS over port 443 if that is not the case. You can override this setting and force this mode by setting the Https ConnectivityMode on the ServiceBusEnvironment.SystemConnectivity setting, which applies globally to the application.

What IP addresses do I need to add to allow list?

To find the right IP addresses to add to allow list for your connections, follow these steps:

Run the following command from a command prompt:

Note down the IP address returned in Non-authoritative answer .

If you use the zone redundancy for your namespace, you need to do a few additional steps:

First, you run nslookup on the namespace.

Note down the name in the non-authoritative answer section, which is in one of the following formats:

Run nslookup for each one with suffixes s1, s2, and s3 to get the IP addresses of all three instances running in three availability zones,

The IP address returned by the nslookup command isn’t a static IP address. However, it remains constant until the underlying deployment is deleted or moved to a different cluster.

Where can I find the IP address of the client sending/receiving messages to/from a namespace?

We don’t log the IP addresses of clients sending or receiving messages to/from your namespace. Regenerate keys so that all existing clients will fail to authenticate and review Azure role-based access control (Azure RBAC)) settings to ensure that only allowed users or applications have access to the namespace.

If you’re using a premium namespace, use IP filtering, virtual network service endpoints, and private endpoints to limit access to the namespace.

Best practices

What are some Azure Service Bus best practices?

See Best practices for performance improvements using Service Bus – this article describes how to optimize performance when exchanging messages.

What should I know before creating entities?

The following properties of a queue and topic are immutable. Consider this limitation when you provision your entities, as these properties can’t be modified without creating a new replacement entity.

• Partitioning
• Sessions
• Duplicate detection
• Express entity

Pricing

This section answers some frequently asked questions about the Service Bus pricing structure.

The Service Bus pricing and billing article explains the billing meters in Service Bus. For specific information about Service Bus pricing options, see Service Bus pricing details.

You can also visit the Azure Support FAQs for general Azure pricing information.

How do you charge for Service Bus?

For complete information about Service Bus pricing, see Service Bus pricing details. In addition to the prices noted, you are charged for associated data transfers for egress outside of the data center in which your application is provisioned.

What usage of Service Bus is subject to data transfer? What isn’t?

Any data transfer within a given Azure region is provided at no charge, as well as any inbound data transfer. Data transfer outside a region is subject to egress charges, which can be found here.

Does Service Bus charge for storage?

No. Service Bus doesn’t charge for storage. However, there’s a quota limiting the maximum amount of data that can be persisted per queue/topic. See the next FAQ.

I have a Service Bus Standard namespace. Why do I see charges under resource group ‘$system’?

Azure Service Bus recently upgraded the billing components. Because of this change, if you have a Service Bus Standard namespace, you may see line items for the resource ‘/subscriptions//resourceGroups/$system/providers/Microsoft.ServiceBus/namespaces/$system’ under resource group ‘$system’.

These charges represent the base charge per Azure subscription that has provisioned a Service Bus Standard namespace.

It’s important to note that these charges aren’t new, that is, they existed in the previous billing model too. The only change is that they’re now listed under ‘$system’. It’s done because of constraints in the new billing system that groups subscription level charges, not tied to a specific resource, under the ‘$system’ resource ID.

Quotas

For a list of Service Bus limits and quotas, see the Service Bus quotas overview.

How to handle messages of size > 1 MB?

Service Bus messaging services (queues and topics/subscriptions) allow application to send messages of size up to 256 KB (standard tier) or 1 MB (premium tier). If you’re dealing with messages of size greater than 1 MB, use the claim check pattern described in this blog post.

Troubleshooting

Why am I not able to create a namespace after deleting it from another subscription?

When you delete a namespace from a subscription, wait for 4 hours before recreating it with the same name in another subscription. Otherwise, you may receive the following error message: Namespace already exists .

What are some of the exceptions generated by Azure Service Bus APIs and their suggested actions?

For a list of possible Service Bus exceptions, see Exceptions overview.

What is a Shared Access Signature and which languages support generating a signature?

Shared Access Signatures are an authentication mechanism based on SHA-256 secure hashes or URIs. For information about how to generate your own signatures in Node.js, PHP, Java, Python, and C#, see the Shared Access Signatures article.

Subscription and namespace management

How do I migrate a namespace to another Azure subscription?

You can move a namespace from one Azure subscription to another, using either the Azure portal or PowerShell commands. To execute the operation, the namespace must already be active. The user executing the commands must be an administrator on both the source and target subscriptions.

Portal

To use the Azure portal to migrate Service Bus namespaces to another subscription, follow the directions here.

PowerShell

The following sequence of PowerShell commands moves a namespace from one Azure subscription to another. To execute this operation, the namespace must already be active, and the user running the PowerShell commands must be an administrator on both the source and target subscriptions.

Is it possible to disable TLS 1.0 or 1.1 on Service Bus namespaces?

No. It’s not possible to disable TLS 1.0 or 1.1 on Service Bus namespaces. In your client applications connecting to Service Bus, use TLS 1.2 or above. For more information, see Enforcing TLS 1.2 use with Azure Service Bus — Microsoft Tech Community.

Next steps

To learn more about Service Bus, see the following articles: