Azure Service Bus is basically an Enterprise Cloud Messaging Service offered by Microsoft. Service Bus is like that of a physical postal service where a data is delivered even if the parties do not know each other or are online. It allows you to transfer data between services and applications in message format like JSON, XML, and Text. Service Bus revolves around two most important services – Queues and Topics. So, in this blog, we will be discussing on what are Queues and Topics and the distinct factors differentiating both the Azure Service Bus offerings. So, buckle up!
Service Bus Queues
Service Bus Queues follow a very simple messaging protocol – a message sender delivers a message to a Queue that will be residing in a Service Bus Namespace, which would then be received by a receiver in initial or later stage. Queues follow asynchronous communication model where messages tend to go only in one direction. The messages in the Queue are processed via FIFO (First-In-First-Out) pattern, which means the first message delivered into the Queue will be the first one to be retrieved by the receiver. One of the biggest advantages of Service Bus Queues is that a message stays in a queue as long as the receiver picks it up.
Service Bus Topics
Topics are almost similar to Queues, but it varies on a slight factor where Topics can have multiple, independent subscriptions. A subscriber to a Topic can receive a copy of each message sent to that Topic. Multiple receivers could be allocated to a subscription. A Topic can have zero or more subscriptions, but a subscription can only belong to one Topic. If you do not want all subscribers to read all the messages, then you can apply rules to specify additional actions to filter or to modify message properties.
When to use?
This messaging system can be used in a more complex messaging infrastructure and by the companies who think messages are their blood to run. Also, when there is a need to pass the message in the one-to-one model.
This messaging model contains a number of Subscriptions underneath it. These are called Topic Subscriptions. One can opt for this model if there is a need to send incoming messages to multiple users or systems. The maximum limit for subscribers in a Topic is 2000.
Message Reading at the Receiver side
It is possible to have multiple receivers, but the key point is that each message will be received only to one of those receivers.
Even in this model, we can have multiple receivers (subscribers) to receive the messages. But the key difference is that the message copy can be sent to any number of subscribers associated with the Topic.
when a receiver reads data from 1 subscription, the others cannot read it again from the same subscription.
A simple example of using Queues is POS (point of sale) systems. POS terminals produce some data with different load/times and the inventory management system must process all of them. The inventory system and the Terminals are loosely coupled there might be different software’s in each terminal, but there is only 1 receiver on the other end.
A simple example of this would be when you create data in a way and process them in different manners. For instance, if there is an ordering system which registers orders for different companies, then each company only needs to know about its orders.
Express Queues allow you to store the messages in the cache before storing into the actual Queue for faster access. This can be enabled through a property in Azure Service Bus Queues.
Express Queues property is not available in Topic Subscription.
In partitioned Queues and Topic Subscriptions, the messages will be stored in multiple fragments (Partitions) and the requests are handled by the dedicated message broker of that partition.
This property is available in-Service Bus Queues.
Enable Partition property is not available in-Service Bus Topic.
We need to define the number of receivers beforehand. It can’t be added at the run-time, unlike Topics.
A subscription can be added at runtime. We don’t need to stop the system or recreate the Topic. Once a new subscription is created, all the new messages that are sent to that Topic will be received by the new subscription also.
The messages can be auto-forwarded to a specified Queue or Topic. But the destination cannot be a Topic Subscription.
The Message can be auto-forwarded from a Topic to a Queue or Topic. Also, it is possible to forward the messages from a Topic Subscription to a Queue or Topic.
Queues does not essentially require any filters as the messages are being received by only one user.
Each message that is sent over a Service Bus can have a collection of properties. Properties are used when a custom filter per subscription is applied. Also, each subscription can have a custom action that is executed when a message is received by it.
Overcome Management and Monitoring challenges with Serverless360
Service Bus Management
It is possible to process the active/dead-letter messages to some other Queues or Topic and backup the message to storage blob. Remote actions like Enable/Disable the Service Bus Queues or view the properties.
In Serverless360, it will be easy to manage the Topic and Topic Subscriptions. As for Service Bus Queues, it is possible to Enable/Disable the Topics and Topic Subscriptions. User can also define the filter rules and actions for the Topic subscription
With the help of import capability in Serverless360, user can import the entities of a namespace to another namespaces.
Activities in Serverless360 helps the user to process bulk messages from the Queue or Topic to same or other Queues/Topic with scheduling.
Service Bus Monitoring
With various types of monitors in Serverless360, it is easy to monitor the errors, message flow, connections, size, etc. With Auto healing capability, User can auto-correct the state of the Service Bus Queues or Topics. User can also monitor the Topic Subscription which is not available in any other tool in the market.
Queues and Topics act as the integral services to meeting the messaging requirements of real time applications. By realising the key factors differentiating them, users can make use of Azure Service Bus in a more sophisticated way.