Year End Sale: Get Upto 40% OFF on Live Training! Offer Ending in
D
H
M
S
Get Now
What is an Azure Service Bus?

What is an Azure Service Bus?

27 Aug 2024
Intermediate
42.3K Views
19 min read
Learn with an interactive course and practical hands-on labs

Free Azure Course: Best Free Online Microsoft Azure Courses

Azure Service Bus

Azure Service Bus is a fully managed multi-tenant cloud messaging service (MAAS). It is a brokered messaging system.SOA (software-oriented architecture) proposes a design for software implementations where these components can communicate with each other by application components through a communication protocol over a network. These application components can be visualized as Service Bus.

Through this Azure Tutorial, we'll explore more about What is a Service Bus in Azure?, Features, and Services provided by Azure Service Bus.

What is a Service Bus?

  • Software applications have different components like front-end apps, backend web services, schedulers, etc.
  • SOA (software-oriented architecture) proposes a design for software implementations.
  • Where these components can communicate with each other.
  • By application components through a communication protocol over a network.
  • These application components can be visualized as Service Bus.
  • Applications and services can communicate with each other using messages via Service Bus.
  • Message consists of two parts; message properties and message payload.
  • Message properties is a dictionary of values against property keys.
  • Message payload is in binary format, which can contain JSON, XML, or text data.

What is a Service Bus?

Read More: Top 50 Azure Interview Questions and Answers

Why Azure Service Bus

  • As Azure Service Bus is a fully managed service, scaling, and availability will be taken care of by the Azure team.
  • It is integrated with other Azure services like Event Grid, Logic Apps, Stream Analytics etc.
  • Azure Service Bus provides a reliable and secure asynchronous message communication platform along with the facility for delayed processing of events or data.
  • It supports shared access signatures (SAS), role-based access control (RBAC), and managed service identity (MSI) protocols.
  • Service Bus also supports client libraries for .NET, Java, JMS.

Read More: Microsoft Azure Certification

The architecture of Azure Service Bus

Azure Service Bus offers three types of communication mechanisms; queues, topics, and, relays.

  • Queues and Topics facilitate one-directional communication. Messages will be stored until they are consumed.
  • Each message in Queue is received by a single recipient.
  • The topic can have multiple subscriptions for multiple receivers.
  • Subscriptions can choose to receive messages based on parameters.
  • Messages from Queues and Topics can be accessed using Service bus-defined messaging APIs or REST APIs.
  • SDKs are also available for other languages.
  • Unlike Queues and Topics, Relays provide bi-directional communication and do not store messages.
  • To use these messaging services, the user must create a namespace underan Azure subscription. A namespace can be visualized as a logical container for messaging components. Multiple Service Bus components (queues, topics, and relays) can reside within a single namespace.

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

Key concepts of Azure Service Bus

1. Queues

  • As the name suggests, the Queues messaging service offers First In First Out data delivery.
  • It enables ordered handling of unbounded sequences of related messages.
  • Message sessions are used to ensure a first-in, first-out (FIFO).
  • Queues enable us to store messages until the receiving application is available to receive and process them.
  • Messages in queues are timestamped on arrival and ordered according to it.
  • Messages are delivered on request (Pull mode delivery). Queue is often used for point-to-point communication.
  • Messages from a Service Bus queue can be deleted immediately after reading. But if the receiver app fails while processing then that message is lost.
  • To avoid this situation, we can go for the Peek Lock option.
  • After receiving it, the message is invisible/locked for other receivers.
  • If the receiver processes the message successfully, it will invoke the Complete() function and the message will be removed from the queue.
  • If the receiver fails to process or does not respond within the specified time interval, the Abandon() function will be invoked and the message will be available for other receivers.

    Example

    Let's take an example, where people are ordering food from an online website application. When the user is done with ordering, a message with the order menu will be pushed into Queue by the application. Order processing application will consume messages from the Queue and process them one by one for delivery. Here food orders must be processed in sequence. Hence, Queue is the perfect option to choose.

    Key concepts of Azure Service Bus

    Figure 3: Food delivery app architecture using Service Bus Queue
  • Topics are nothing but single input queues and multiple output queues.
  • Output queues are nothing but Subscriptions.
  • Receiving apps need to create subscriptions to receive messages from Topic.
  • Subscriptions can filter out the messages based on rules on message properties.
  • Publish/subscribe scenarios can be implemented using Topics.

    Example

    Let us use the same example, which we have discussed above.

    • Now we require high throughput while processing incoming orders.
    • Here we can add multiple order processing applications, which will be reading the same message queue.
    • It is not possible to have multiple receivers for a Queue.
    • Hence, we will create different subscriptions based on restaurant-selected orders and process them differently.
    • Subscription will filter the messages from Topic by restaurant name. Each order processing application will read messages from the 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 provide unidirectional messaging.
    • To facilitate bi-directional communication, Azure provides a Relay messaging service.
    • In Queues or Topics, there is no explicit connection between sender and receiver.
    • However, for relays, each application will create an outbound TCP connection to the Service Bus.
    • All communication happens using WCF (Windows Communication Foundation).
    • We do not need to create relays explicitly.
    • The relay will be created when the application establishes a connection to the Service Bus.
    • The idea of providing a Relay method is to connect applications irrespective of their deployment environment.
    • Some of the applications are deployed to different on-premise data centers.
    • Connecting these applications for communication is not the trivial task of development as well as configuration.
    • To provide direct communication between applications without much effort, we can go for Azure Service Bus Relays.

     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 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 10k Service Bus per namespace queues.

    • 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 can be used for one-to-one communication but Topics can be used for one-to-many communication scenarios.

    • Receivers need to subscribe for topics and optionally need to specify rules.

    Advanced features of Azure Service Bus

    1. Messaging Sessions

    Sessions are utilized to ensure messages are processed in a first-in, first-out manner in the Service Bus. Message sessions enable the organized handling of interconnected message sequences without limit.

    2. Auto-forwarding

    Auto forwarding allows you to link a queue or subscription to another within the namespace using its capability. When auto forwarding is 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 by any recipient. Subsequently, you can. Delete messages from the DLQ.

    4. Scheduled delivery

    To facilitate processing you can enqueue messages for a queue or topic. This enables scheduling tasks making them available for system processing, at specified times.

    5. Message deferral

    In cases where unique application conditions prevent message processing by a queue or subscription client, deferred message retrieval may be employed. The message is set aside. Remains, in the queue or subscription.

    6. Transactions

    A transaction establishes an execution scope by combining two or more operations. Within a transaction context Service Bus allows grouping operations on a messaging entity (queue, topic, or subscription).

    7. Filtering and actions

    Subscribers can specify which messages they wish to receive from a subject. These messages are described in the form of one or more named subscription rules. For each matching rule condition, the subscription generates a message copy that may be annotated differently.

    8. Auto delete on idle

    You can set an interval with auto-delete on idle after which the queue will be automatically removed. The interval resets when there is activity in the queue. The minimum idle interval is five minutes.

    9. Duplicate detection

    To address uncertainty multiple detections permit the sender to retransmit the message if needed. In case of an error that leaves the client unsure, about a send operations outcome, the queue or topic discards any copies.

    10. Shared access signature (SAS)

    It is a Role-based access control and managed identities. In short. Azure resources benefit from security measures such, as Managed identities, Role Based Access Control, and Shared Access Signatures (SAS) provided by Service Bus.

    11. Geo-disaster recovery

    In the event of a geo disaster data processing can seamlessly continue in an Azure region or data center if primary locations are affected.

    12. Security

    Service Bus supports Standard HTTP/REST and Advanced Message Queuing Protocol (AMQP) 1.0 to ensure communication protocols.

    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.

    Conclusion

    Service Bus Messaging service has a lot to offer, but we cannot cover all its capabilities in a single article. In short, Azure Service Bus helps us build our loosely coupled software components with fewer deployment efforts and high scalability and availability of communication. By providing three different types of services. Also consider ScholarHat Azure online training to help you earn Azure real-time focused Hands-on skills and get Azure certification.

    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

    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

    Share Article
    About Author
    Akshay S Deshmukh ( Author and Architect)

    He is an Author, Architect and Optimist by choice. He has development experience in Azure, Microsoft Bot Framework, Angular and SharePoint. Strongly believe in "sharing is caring".
    Accept cookies & close this