Introduction
Azure Service Bus is a brokered messaging service offered by Azure that can be used to decouple the various applications forming the business integration solving the business problem. The Applications transfer messages between them to share the data between them. The messages can be in XML, JSON or simple text format.
Namespace
Namespaces are containers within which the Service Bus Queues and Topics can be created. The namespaces can be in Basic, Standard or Premium Tier. The main disadvantage in the Basic tier being Service Bus Topics cannot be created.
Service Bus Queues
Service Bus Queues can be used when there is a one to one communication needed between the Applications. Queues store the message in redundant storage until the message is received by the receiver.
Service Bus Topics
Service Bus Topics can be used when there is a one to many communications needed between the Applications. Messages can be sent to the Service Bus Topics but cannot be received from the Topic directly.
Topic Subscriptions
Topic Subscriptions can be created within a Service Bus Topic. The messages sent to the Service Bus Topic will be copied to the subscription, based on the filters created for the Topic Subscriptions.
Main Queue and Dead-Letter Queue in Queues and Topic Subscriptions
Messages sent to the Service Bus Queue or Service Bus Topics will be generally present in the main queue of the Service Bus Queue or Topic Subscription. There may be certain scenarios in which the message is invalid, or it cannot be delivered to any receiver. In such cases, the messages can be moved to the Dead-Letter, so that the messages in the Dead-Letter path can be repaired and resubmitted to the same or different queue.
Message Receival Modes in Service Bus
The messages from Service Bus Queues and Topic Subscriptions can be received either using the PeekLock Mode or the ReceiveAndDelete Mode.
When the message is received in PeekLock mode it can be removed from the queue by calling Complete() method. When the message is received in ReceiveAndDelete mode, the message is automatically removed from the queue.
When the message is received in PeekLock mode and if the message is not completed or if the message lock is expired, the message will be automatically available for other receivers.
Check out the blog on Azure Service Bus delete message to understand how to resubmit and delete messages in Azure Service Bus Messaging.
Real World Scenario
Let us consider a hospital management application. The task of the application is to allocate a doctor to the patients visiting the hospital according to the patient’s requirements. The Application constitutes a Service Bus Queue, a message pumping application and a message receiving application.
Whenever a patient visits the hospital, the message pumping application pushes a Service Bus Message with the Patient’s details as message content. The message receiving application receives the message from the queue in PeekLock mode and checks if any doctor is available at that point of time who suits the Patient’s requirements. If a doctor is available, then the patient is allocated to the doctor and the message is completed. If the doctor is not available, the message is not completed and is simply abandoned. This makes the message available to be picked up again for further processing.Now let us consider that the patient has reached the hospital at 9 AM and the doctor he wants to meet will be available only at 10 AM.
The message receiving application can choose any of the following approaches:
Approach 1
The message can be received by the message processing application and abandoned if the doctor is not available at that point in time. This lets the same message be received again and again which decreases the performance of the Application or the message may reach its MaxDeliveryCount causing the message to be dead-lettered.
Approach 2
The message can be removed by the queue by calling the Complete() method and the message can be cloned with ScheduledEnqueuedTime as the Doctor’s arrival time and pushed to the same queue. This makes the message to be available for processing by the message received application only when the doctor has arrived. This solves the continuous retrieval of the same message by the message processing application.
Approach 3
Another approach is that the received message can be deferred by calling the Defer() method. By doing this, the message will be deferred, and it will be no longer available for the active listeners of the queue. The messages in the Defer mode of the queue can be received only if the sequence number of the message is known. So the messages with the patients whose doctor will be available only after a certain duration of time can be deferred and the sequence number of the message along with the doctor’s arrival time can be stored in some storage option and this can be used for processing the deferred messages at that point of time when the doctor has arrived.
Deferred Messages
The messages in the main and dead-letter path of the Service Bus Queues and Topic Subscriptions can be either in the Active state or in the Deferred state.
Active State
The messages in the active state will be available for all the receivers of the Service Bus Queue or Topic Subscription. The messages will be available for reception using the methods like OnMessage() and Receive() in PeekLock and ResubmitAndDelete mode.
Deferred State
The messages in the deferred state will not be available for the active listeners of the Service Bus Queue or Topic Subscription. The messages can be received only using the Sequence Number of the message in the Receive() method in PeekLock and ResubmitAndDelete mode.
Message Deferral APIs
The API is BrokeredMessage.Defer or BrokeredMessage.DeferAsync in the .NET Framework client, MessageReceiver.DeferAsync in the .NET Standard client, and IMessageReceiver.defer or IMessageReceiver.deferAsync in the Java client.
Advantages of Deferred Mode
The main advantage of deferred mode in Service Bus messages is that if a message in the main queue cannot be processed at a particular point in time when received in PeekLock mode, the message can be deferred instead of dead-lettering it. As to process the dead-lettered message some other mechanism is required to move it back into the main queue. Whereas the Defer mode lets the message remain in the main queue but still not available for the active listeners unless they know the sequence number of the message that has been deferred.
Limitations of Deferred Mode
One of the major limitations with deferred messages is that the messages in the deferred mode can only be received again only by using their sequence number. To achieve this, we must store the sequence number of the messages that are deferred in some storage so that we can use it to receive the messages at a later point in time.
Discovering Messages in Deferred State Without the Sequence Number
The messages in the deferred state can be retrieved even if there is no track of the sequence number of the deferred messages. This can be done using message browsing. Message Browsing is the process in which the messages in the Service Bus Queue or Topic Subscription can be retrieved by using the Peek() method. This method returns the messages in the Service Bus Queue or Topic Subscription irrespective of the state of the message. The message may be in Active, Deferred or Scheduled state.
Peek API’s
The Peek/PeekAsync and PeekBatch/PeekBatchAsync methods exist in all .NET and Java client libraries and on all receiver objects: MessageReceiver, MessageSession, QueueClient, and SubscriptionClient. Peek works on all queues and subscriptions and their respective dead-letter queues.
Message Processing Capabilities in Turbo360
Messages can be received in Turbo360 in either of the following modes
- Peek Lock Mode
- Defer Mode
Messages can be resubmitted to the same or other Service Bus Queues or Topics or saved to a file when received in Peek Lock Mode.
Messages can be resubmitted, repaired and resubmitted, deleted or saved to a file when received in Defer Mode.
All the above-mentioned operations can be done both on the active and the dead-lettered messages.
Conclusion
I hope this blog gives you a detailed understanding of the deferred messages in Service Bus Queues and Topic Subscriptions along with its advantages and limitations. To take a look on every other blog highlighting Azure Service Bus capabilities, follow this link. Happy learning!
