What is an Azure Service Bus? A Cloud Messaging Service

 Software applications have different components like front-end app, 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 communication protocol over a network. These application components can be visualized as Service Bus.

 Figure 1: SOA Components

Azure Service Bus is a fully managed multi-tenant cloud messaging service (MAAS). It is brokered messaging system. 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.

Architecture

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. 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 does not store messages.

To use these messaging services, user must create namespace under 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

Why Service Bus

As Azure Service Bus is fully managed service, scaling and availability will be taken care by Azure team. It is integrated with other Azure services like, Event Grid, Logic Apps, Stream Analytics etc. Azure Service Bus provides reliable and secure asynchronous message communication platform along with facility of delayed processing of events or data. Shared Access Signatures (SAS), Role Based Access Control (RBAC) and Managed Service Identity (MSI) protocols are supported by it. Service Bus also supports client libraries for .NET, Java, JMS.

Service Bus Tiers with Features

Features of Service Bus are 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 Standard tier are variable, hence performance is not predictable. In built scaling is also not available and maximum message size is upto 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 1mb. Premium name spaces provides CPU and memory level isolation for resources. Performance of Premium tier resources at peak load is much faster than Standard ones.

Service Bus Services

1. Queues

   As name suggest, Queues messaging service offers First In First Out data delivery. It enables ordered handling of unbounded sequences of related messages. Message sessions is 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 receiver app fails while processing then that message is lost. To avoid this situation, we can go for Peek Lock option. After receiving, it makes message invisible/locked for other receivers. If receiver processes message successfully, it will invoke Complete() function and message will be removed from queue. If receiver fails to process or does not respond within specified time interval, Abandon() function will be invoked and message will be available for other receivers.

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

    Figure 3: Food delivery app architecture using Service Bus Queue

2. Topics

   Topics is nothing but single input queue but multiple output queues. Output queues are nothing but Subscriptions. Receiving apps needs to create subscriptions to receive messages from Topic. Subscription can filter out the messages based on rules on message properties. Publish/subscribe scenarios can be implemented using Topics.

   Let us use 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 same message queue. It is not possible to have multiple receivers for a Queue. Hence, we will create different subscriptions based on restaurant selected in order and process them differently. Subscription will filter the messages from Topic by restaurant name. Each order processing application will read message from respective subscription.

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

3. Relays

   Queues and Topics provides unidirectional messaging. To facilitate bi-directional communication, Azure provides Relay messaging service. In Queues or Topics there is no explicit connection between sender and receiver. However, for relays, each application will create outbound TCP connection to Service Bus. All communication happens using WCF (Windows communication Foundation).

   We do not need to create relays explicitly. Relay will be created when application established connection to Service Bus. Idea of providing Relay method is to connect applications irrespective of their deployment environment. Some of the applications are deployed to different on premise data centers. To connect these applications for communication is not 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.

    Figure 5: System Block diagram using Service Bus Relay

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-once delivery of message.

• We can receive messages in batch from both the services.

• Both supports In-place update of messages.

Differences

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

• Service Bus Queue allows batched send of messages.

• State can be managed in Service Bus Queue messaging.

• You can create 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 message level; in Service Bus it is applied at 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 scenario.

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

Summary

Service Bus Messaging service has a lot to offer, we cannot cover its all capabilities in single article. There are Paired Namespaces, AMQP support, Partitioned Queues and many more. In short, Azure Service Bus helps us to build our loosely coupled software components with less deployment efforts and with high Scalability and Availability of communication. By providing three different types of services, it enables architect/developer to implement different communication scenarios.