Whitepaper continued...

 Introduction: This is a continuation of the whitepaper on Host Integration Server introduced here. We now describe the remaining of four components of the overall design – namely, APIs, Events, Messaging, and Orchestration.

Description:

3) Messaging:

Plenty of backend operations are asynchronous by nature requiring background operations. Sometimes, a direct call via API Management is perfect. In other cases, some form of background processing is required. Situations like this call for a message queue.

The Azure Service Bus is well positioned to provide this functionality. It allows non-blocking interactions between different components of software by facilitating message exchanges on queues where the messages are ordered and retried. The messaging works across many kinds of software, including cloud applications, on-premises applications, and Azure services. Service Bus provides all the following:

Queue semantics, including message persistence and strict first-in, first-out ordering of messages, deduplication, dead letters, poison messages and retries.

Transactional guarantees, letting a queue read or write be part of a larger operation that succeeds or fails as a single unit.

Poison message handling so that a message that causes problems won’t put a receiver into an ongoing loop.

High availability for built-in disaster recovery via geo-replication.

Service Bus provides all the features required for enterprise messaging.

4) Events:

Events facilitate the notion of publisher-subscriber so that the polling on messages from a queue can be avoided.

This is exactly what Event Grid allows. Rather than requiring a receiver to poll for new messages, the receiver instead registers an event handler for the event source it’s interested in. Event Grid then invokes that event handler when the specified event occurs. 

Azure Services generate events. The arrival of a new Service Bus message might cause Event Grid to send a message that starts a Logic App running, or the creation of a new blob in Azure Blob Storage might cause a custom cloud application to begin processing the contents of that blob. Using an event-driven approach can simplify application development, and it can also save money, since the receiver needn’t waste cycles polling for new messages.

A blob storage can receive an event by subscribing to a standard topic provided for that service. This is a common use case for the Azure Event Grid, but it is not the only option. Custom topics allow different subscriptions.

Conclusion: An enterprise integration solution hosted on Azure must make use of these four components of API management, Logic Apps, Service Bus and Enterprise Grid.