Azure Messaging Service

Azure Messaging Service

Sending information between two or more systems isn’t something that is new to computing; it’s actually a fundamental concept. From a web application perspective, HTTP based protocols such as SOAP, WCF, and REST are used for managing the communication between systems. Additionally, there are protocols such as Microsoft Message Queuing (MSMQ), Data Distribution Service (DDS), and Advanced Message Queueing Protocol (AMQP), which are useful in scenarios that won’t or don’t function over HTTP.

In this section, you will learn the following:

• Event versus messaging
• How to choose the right messaging service
• Messaging patterns
• Event Hub, Service Bus, Azure Storage Queue, and Event Grid
• Logic App and Notification Hub

Event Versus Messaging

An event is a notification from a publisher that a change in state or condition has occurred. e. In the Azure messaging service context, the glue between a publisher and a consumer is Event Hub or Event Grid. Once the consumer (function or method) is notified that it needs to run, it parses the content of the event metadata and executes code based on its findings.

Service Bus and Azure Storage Queue handle messages that you can visualize as an array of characters and strings. They receive, queue, and track messages until they are consumed, processed, and deleted.

Service Bus and Azure Storage Queue handle messages that you can visualize as an array of characters and strings.

How to Choose the Right Messaging Service

Below decision tree explains about how to choose the Right Messaging Service

The primary decision to make is whether your solutions need to be triggered on an event or if you will be receiving or processing messages.

If you require event-driven capabilities and the amount of data needing processing is huge, like big data huge or perhaps you have a constant stream of data, then Event Hub is your choice. If not, go for Event Grid. If you require a messaging-driven capability with simple messages that are less than 64KB, then choose Azure Queue Storage. If the message is larger than 64KB and/or the messages require FIFO or you must guarantee processing, then a Service Bus should be used.

Below table compares Azure Messaging Service.

Messaging Pattern

In most components of technology, there are best practice use patterns for achieving high availability, optimal scalability, resiliency, and performance. This applies to loosely coupled interconnected and asynchronous messaging systems, too. Some of the most popular patterns are listed here: Publisher/subscriber

• Asynchronous request/reply
• Queue-based load leveling
• Sequential convoy
• Competing consumers

 Publisher/Subscriber

Also commonly referred to as pub/sub.

The benefit of this pattern is that the entity providing or creating the data must send it only to a single location. The “entity” is the publisher, and the location the data packet is sent to is inserted into an input data queue, which is an ultrafast ingestion data store. The message broker would then be responsible for managing the data packet and notifying the subscribers in the form of an event that there is a message for them. This pattern avoids having to send the information to multiple consumers or subscribers, which would take much longer than sending out a broadcast message from the publisher.

Below figure describes Publisher/Subscriber Messaging Pattern.

The solution is more reliable because the ability for the publisher to send data to a consumer is no longer dependent on the consumer being available. The data is placed in a queue, and the consumer is notified and can come retrieve it whenever they want.

Asynchronous Request / Reply

When using the HTTP protocol, the client sending the request is expecting a response. The most common and most expected successful response from a sent request is a 200. However, if the request is asynchronous, then it is likely the response is sent before the code completes, so a 200-response code isn’t the correct status. Instead, the response would be a 202, meaning that the request has been accepted but not necessarily completed.