What is an Azure Service Bus?

What is an Azure Service Bus?

27 Jan 2025
Intermediate
43.1K Views
20 min read
Learn with an interactive course and practical hands-on labs

Free Azure Online Course with Certificate [For Beginners]

Azure Service Bus

Azure Service Bus is a fully managed messaging service that helps applications communicate with each other seamlessly. It ensures reliable data transfer between services, making it perfect for building scalable and distributed systems. Understanding how it works can simplify your cloud integration tasks.

In this Azure tutorial, I will explain how Azure Service Bus works and how you can use it to connect your applications effectively. Do not worry. We will keep it simple and easy to understand! Ready to explore the power of Azure Service Bus? Let us get started!

What is a Service Bus?

A Service Bus is a communication mechanism that enables software applications to interact with each other efficiently. In modern software systems, different components such as front-end applications, back-end services, and schedulers often need to exchange information to function cohesively. The concept of Service-Oriented Architecture (SOA) supports designing such systems by allowing application components to communicate over a network using a standardized protocol. The Service Bus acts as a bridge for this communication, ensuring smooth and structured message exchange between components.

  • Software applications have various components like front-end apps, backend web services, and schedulers.
  • Service-Oriented Architecture (SOA) enables these components to communicate efficiently.
  • The Service Bus allows communication through a protocol over a network.
  • Applications and services exchange messages via the Service Bus.
  • Messages consist of:
    • Message Properties: A dictionary of values stored as key-value pairs.
    • Message Payload: A binary format containing JSON, XML, or text data.

What is a Service Bus?

Read More: Top 50 Azure Interview Questions and Answers

Why Azure Service Bus

Azure Service Bus offers a fully managed messaging service, providing reliable and secure communication between applications and services. Its integration with other Azure services and advanced features makes it an ideal choice for building scalable and efficient systems.

  • As Azure Service Bus is a fully managed service, scaling and availability are handled by the Azure team.
  • It is integrated with other Azure services like Event Grid, Logic Apps, and Stream Analytics.
  • Azure Service Bus provides a reliable and secure asynchronous message communication platform, including support for delayed events or data processing.
  • It supports advanced security protocols such as Shared Access Signatures (SAS), Role-Based Access Control (RBAC), and Managed Service Identity (MSI).
  • Service Bus also supports client libraries for .NET, Java, JMS.

The Architecture of Azure Service Bus

Azure Service Bus provides three types of communication mechanisms: queues, topics, and relays. These components offer flexibility in designing messaging solutions for various scenarios.

  • Queues and Topics enable one-directional communication, where messages are stored until consumed.
  • Each message in a Queue is delivered to a single recipient.
  • Topics can have multiple subscriptions, allowing multiple receivers to process messages.
  • Subscriptions can filter messages based on specific parameters.
  • Messages from Queues and Topics can be accessed using Service Bus-defined messaging APIs or REST APIs.
  • SDKs are available for multiple programming languages to work seamlessly with these components.
  • Unlike Queues and Topics, Relays provide bi-directional communication and do not store messages.
  • To use these messaging services, you need to create a namespace under your Azure subscription. A namespace acts as a logical container for messaging components, allowing multiple Service Bus entities (Queues, Topics, and Relays) to coexist within it.

Azure Service Bus Architecture

Figure 2: Architecture - System implementation using Azure Service Bus components

Key Concepts of Azure Service Bus

1. Queues

  • The Queues messaging service follows the First In First Out (FIFO) delivery model.
  • It ensures ordered handling of related messages through message sessions.
  • Queues allow storing messages until the receiving application is ready to process them.
  • Messages are timestamped upon arrival and ordered accordingly.
  • Message delivery occurs on request (Pull mode delivery) and is often used for point-to-point communication.
  • Messages can be deleted immediately after reading, but this might result in message loss if the receiver fails during processing.
  • The Peek Lock option prevents message loss:
    • After receiving, the message becomes invisible/locked to other receivers.
    • If processed successfully, the Complete() function removes the message from the queue.
    • If processing fails or the receiver does not respond within a set time, the Abandon() function is invoked, making the message available to other receivers.

Example

Consider an online food ordering system. When a user places an order, the order details are pushed into a queue. The order processing application retrieves and processes these messages one by one to ensure that the food orders are handled sequentially. In this scenario, Queue is an ideal choice.

Key concepts of Azure Service Bus

Figure 3: Food delivery app architecture using Service Bus Queue

2. Topics

  • Topics operate as single input queues with multiple output queues, known as Subscriptions.
  • Receiving applications create subscriptions to receive messages from a Topic.
  • Subscriptions can filter messages based on rules applied to message properties.
  • Publish/Subscribe scenarios are implemented using Topics.

Example

Let us use the same example discussed above.

  • Now, we require high throughput while processing incoming orders.
  • To achieve this, we can add multiple order-processing applications to read the same message queue.
  • However, multiple receivers for a Queue are not allowed.
  • Therefore, we create different subscriptions based on restaurant-specific orders and process them separately.
  • Subscriptions filter messages from the Topic by restaurant name. Each order-processing application reads messages from its respective subscription.

Food delivery app architecture using Service Bus Topic and Subscriptions

Figure 4: Food delivery app architecture using Service Bus Topic and Subscriptions

3. Relays

  • Queues and Topics support unidirectional messaging.
  • To enable bi-directional communication, Azure provides a Relay messaging service.
  • Unlike Queues or Topics, Relays establish an explicit connection between sender and receiver.
  • Applications create outbound TCP connections to the Service Bus for communication via Relays.
  • All communication is conducted using WCF (Windows Communication Foundation).
  • Relays do not need to be explicitly created; they are established when an application connects to the Service Bus.
  • Relays simplify connecting applications deployed in diverse environments, including on-premises data centers.
  • They enable direct communication between applications with minimal development and configuration effort.
  • For applications in different data centers, Relays are an effective solution for seamless communication.

Relays

Figure 5: System block diagram using Service Bus Relay

4. Namespaces

  • All the messaging elements are stored in namespaces, which include queues and topics.
  • A namespace can house queues and topics, serving as a hub for applications.
  • In comparison to brokers, a namespace can be likened to a server.
  • They do not directly align in terms of concepts.
  • Within a Service Bus namespace, you have your designated portion within a cluster comprising numerous active virtual machines.
  • This setup can extend across three Azure availability zones if needed.
  • This configuration offers the advantages of availability and resilience,
  • That comes with operating the message broker on a scale without the need to manage intricate underlying details.
  • Essentially, Service Bus provides serverless messaging capabilities.

Service Bus Queues vs Storage Queues

Azure supports two types of queue mechanisms: Storage queues and Service Bus queues. Storage queues are part of the Azure Storage, and Service Bus queues are part of the Azure Messaging infrastructure.

Similarities

  • Both guarantee at least one delivery of the message.

  • We can receive messages in batches from both services.

  • Both support in-place updates of messages.

Differences

  • Service Bus queues guarantee ordered delivery of messages (timestamp-based) using message session.

  • The Service Bus Queue allows batched messages to be sent.

  • The state can be managed in Service Bus Queue messaging.

  • You can create an unlimited number of Storage Queues, but only 10k Service Bus queues per namespace.

  • Service Bus Queue supports automatic dead lettering for messages that cannot be processed or delivered.

  • In Storage Queues, lock timeout can be applied at the message level; in Service Bus, it is applied at the queue level.

Service Bus Queues vs Topics

Similarities

  • Supports unidirectional communication.
  • Supports FIFO message delivery.

Differences

  • Queues are used for one-to-one communication, but Topics are used for one-to-many communication scenarios.
  • Receivers need to subscribe for Topics and optionally specify rules.

Advanced Features of Azure Service Bus

1. Messaging Sessions

Messaging sessions are utilized to ensure FIFO (First-In, First-Out) processing of messages. They enable the organized handling of interconnected message sequences without limits.

2. Auto-forwarding

Auto-forwarding links a queue or subscription to another within the namespace. When enabled, Service Bus automatically transfers messages from the source queue or topic to the destination queue or topic.

3. Dead Letter Queues

Service Bus supports Dead Letter Queues (DLQs) for storing messages that cannot be delivered or processed. Messages in the DLQ can later be reviewed and deleted if necessary.

4. Scheduled Delivery

Scheduled delivery allows you to enqueue messages for processing at a specific time, facilitating task scheduling.

5. Message Deferral

If specific conditions prevent a message from being processed, you can use Message Deferral. The message remains in the queue or subscription for later retrieval.

6. Transactions

Transactions enable grouping two or more operations into a single execution scope. Operations can include sending, receiving, or deleting messages.

7. Filtering and Actions

Filters and actions allow subscribers to define rules to specify which messages they wish to receive. Matching rules generate message copies that can be annotated.

8. Auto-delete on Idle

Auto-delete on idle removes a queue or topic automatically if there is no activity for a specified interval. The minimum idle interval is five minutes.

9. Duplicate Detection

Duplicate detection ensures that no duplicate messages are processed. If an error occurs during transmission, the queue or topic discards duplicate messages.

10. Shared Access Signature (SAS)

Shared Access Signature (SAS) offers role-based access control and security for messaging operations. It integrates with Azure-managed identities and role-based access control.

11. Geo-disaster Recovery

Geo-disaster recovery ensures seamless data processing in case of a disaster, allowing operations to continue in another Azure region or data center.

12. Security

Service Bus supports Standard HTTP/REST and Advanced Message Queuing Protocol (AMQP) 1.0, ensuring secure and reliable communication.

Pricing of Azure Service Bus

Pricing of Service Bus is available in two tiers; Premium and Standard.

1. Standard tier

  • It can be used for initial development and QA environment deployments.
  • Latency and throughput in the Standard tier are variable; hence, performance is not predictable.
  • In-built scaling is also not available, and the maximum message size is up to 256 kb.

2. Premium tier

  • It can be used for Production deployments.
  • It provides high throughput and auto-scaling for variable workloads.
  • Maximum message size can be up to 1 MB.
  • Premium namespaces provide CPU and memory level isolation for resources.
  • The performance of Premium tier resources at peak load is much faster than Standard ones.

Summary

Azure Service Bus is a powerful messaging service that simplifies building loosely coupled software components. It ensures high scalability, reliable communication, and minimal deployment effort, making it an excellent choice for modern applications. While we can’t cover everything it offers in one go, it provides robust features to help you create efficient and highly available solutions.Want to dive deeper and gain hands-on Azure skills? Check out Azure Cloud Engineer Certification Training. It’s perfect for mastering Azure in real-world scenarios and earning a valuable certification.

Looking to start for free? ScholarHat also offers Azure Fundamentals and Docker courses. Explore these resources and begin your cloud journey today!

Similar Articles of Azure
An Introduction to Azure App Services
Top 15 Amazing Azure Components
Migrate data with Azure data factory
What's the Difference Between AWS vs. Azure vs. Google Cloud?
Interview Articles of Azure
Top 50 Azure Interview Questions and Answers
Top 50 Azure Administrator Interview Questions and Answers

Test Your Knowledge of Azure Service Bus!

Q 1: What is Azure Service Bus used for?

  • (a) To manage virtual machines
  • (b) To send and receive messages between different applications
  • (c) To host web applications
  • (d) To store data in databases

Q 2: What type of messaging patterns does Azure Service Bus support?

  • (a) Point-to-point messaging
  • (b) Publish/Subscribe
  • (c) Both Point-to-point and Publish/Subscribe
  • (d) None of the above

Q 3: What is a topic in Azure Service Bus?

  • (a) A queue for sending messages
  • (b) A service for monitoring applications
  • (c) A publish/subscribe mechanism
  • (d) A message-routing service

Q 4: What is the maximum size of a message in Azure Service Bus?

  • (a) 1 MB
  • (b) 5 MB
  • (c) 256 KB
  • (d) 100 MB

Q 5: How does Azure Service Bus guarantee message delivery?

  • (a) By using pull-based message delivery
  • (b) By using retries and dead-letter queues
  • (c) By using time-to-live (TTL) for messages
  • (d) By requiring manual acknowledgment from the receiver

FAQs

A message broker being a broader concept contain many middleware technologies that help in communication between different systems whereas a service bus focuses more on message delivery and queuing between application and the user.

The several messaging patterns supported in Azure Service Bus include:
  1. Point-to-Point
  2. Publish-Subscribe
  3. Request-Reply
  4. Scheduled
  5. Session-Based

Other messaging middleware alternatives for Azure Service Bus include services like Amazon Web Services, Google Cloud Platform, IBM Cloud, etc

Azure Service Bus is a messaging service managed by Microsoft Azure while Apache Kafka is a distributed streaming platform used for real time analytics and event sourcing.

Take our Azure skill challenge to evaluate yourself!

In less than 5 minutes, with our skill challenge, you can identify your knowledge gaps and strengths in a given skill.

GET FREE CHALLENGE

Accept cookies & close this