22
DecWhat is an Azure Service Bus?
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.
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
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.
Figure 3: Food delivery app architecture using Service Bus Queue
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.
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.
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
- Point-to-Point
- Publish-Subscribe
- Request-Reply
- Scheduled
- Session-Based
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.