Messaging Patterns with Azure AIS | Serverless360 Blogs
← Return To Home

Messaging Patterns with Azure AIS

This blog covers the final session of Integrate 2020 day -2 which is “Messaging Patterns with Azure AIS” by our Azure MVP – Wagner Silveria

Wagner Silveira spoke about some common Messaging Patterns that can be implemented on Azure Integration services.

First Things, first…

He started with one of the widely asked question “What is the differentiation between Messages and Events?”.

He gave a teardown comparison on what is the message and what is the event.

1-First Things, first

In this above illustration, we got a clear understanding for What is message and event but what is the stream? Stream is a collection of events.

We got to see about Messages and Events but what are the AIS that can handle them? There he gave a comparison on well known Azure Services that are Azure Service Bus and Azure Event Grid

Below is the illustration that shows tear down a comparison of Azure Service bus Azure Event Grid and how are being used for handling Messages and Events:

AIS-messaging services


So, it was more about Messages and Events handling services. Then What about others?

And there he gave a comparison on how Azure Logic Apps and API Management processing the messages.

other ais services

Implementing Messaging Patterns in AIS

In this section, he explained about different messaging patterns available for a better message or event handling.

  1. Publisher/ Subscriber Pattern
  2. Claim check pattern
  3. Sequential convoy

Publisher/Subscriber

Publisher/ Subscriber pattern will have a single publisher with Multiple Subscribers being data replicated for individual subscribers

Publisher/Subscriber

Now we got to know about Publisher/Subscriber pattern but let us see if it can be implemented into our AIS

AIS-implementation

As shown in the above image both the Azure Service Bus and Azure Event grid works based on the Publisher/Subscriber model

We can replicate the data with the help of this pattern when there are multiple subscribers but what if every subscriber needs their respective data. Can we implement routing in AIS?

Well, it is possible to implement Routing as mentioned in the below illustration

content based routing

Both the Azure Service Bus and Event Grid can filter the messages and events based on the filters provided by the user

Claim Check Pattern

In the Publisher/ Subscriber model, we were dealing with the actual message. What if there is a message lost?

There comes the Claim check pattern. Here Instead of sending the actual message, a copy of the message will be sent through the messaging service whereas, the message will be stored in the common Storage by the send through other AIS like Logic Apps or API Management.

Claim Check Pattern

As mentioned in the above illustration, both the Azure Service Bus and Event grid can act as message handler to send the copy of a message and API Management & Logic Apps acts as a proxy to put the original message in the common Data repository of Sender and Receiver.

Sequential Convoy

Azure Integration Services are very powerful tools that can satisfy both Publisher/ Subscriber and Claim check pattern but there is another complex pattern which involves a stream of data – Sequential Convoy

In this pattern, there will be a stream of data which needs to be received in an order based on the receiver requirement. This can be achieved by Correlation or sequence Id with which the messages can be retrieved in order very easily

Sequential Convoy

We saw the pattern but how it can be achieved in AIS?

This can be directly achieved by sessions in Azure Service bus and even Azure Logic App can be used to retrieve data in sequence

AIS-implementation-2

It’s a Demo Time

In the Demonstration, He took an Azure Logic App which will put the actual message into a Storage blob and send the copy of the message to the Message handling system Azure Service bus

In the other End, there will be receiver logic which will receive the message from the Azure service bus and validate that message with an original message in the Storage Blob. If it is a valid message it will be taken for the further process.

Below is the illustration of how the above Claim check pattern can be implemented through the Azure Integration Services

Demo

Conclusion

Wagner interestingly covered this session with a lot of illustrations and a great real-world demonstration. He concluded with the summary and answered a few questions from the audience.

Q&A

  1. How can you guarantee at least once execution if Service Bus doesn’t have endpoints supporting distributed transactions? – John Brockmeyer
  2. We can use the peek-lock option that guarantees all the message we received but before you commit it back

  1. When is subscription filter access via the Azure Portal due to become available? – John Anderson
  2. It is already available there. Filtering based on Message properties and SQL filtering is already available there in Azure portal

  1. How do you handle retries with azure service bus topic-subscriptions? – Rodrigo Groener
  2. We can re-submit the messages from the client-side. All message will be there in the Azure Service bus if you are receiving the message in peek-lock. You can any time retry the messages

Stay tuned for the awesome sessions of 3rd day of Integrate 2020 remote…