In the above figure we can see that an MVC application stores unprocessed data in a database and then fetches the location and name of the data from that database and finally sends this information to the Azure Messaging Service as a message (JSON) where each message object contains the name and location of the data. Whenever a message arrives in Azure Messaging Service, an application retrieves and locks the message so that no other application can retrieve the same message and finally processes it and stores it in the database.
Now the question is why not sending messages directly to the application instead of Azure Messaging Service?
At first glance it may seem that the use of Azure Messaging Service is pointless here, but if you look a little closer, you will see that there is a reason for this.
- When a message is sent, they will fight among themselves over which of the three applications will process it.
- If an application fails to process then the message will be lost or the earlier mentioned MVC application has to resend the same message which means the MVC application has to wait for successful completion of processing the message from the process application.
- If an application fails to process then the message will come to the Azure Messaging Service again and other application can pick it.
- The MVC applications no longer have to wait. Which means a decoupling architecture can be created.
- Azure Storage Queues.
- Azure Service Bus.