I’m going to take a high-level overview of the Microsoft Azure Service Bus. I’ll discuss briefly the four services that make up the Service Bus.

The essence of application integration is software talking to other software. But how should this communication happen? Sometimes, a direct call via API Management is perfect. In other cases, though,
this synchronous style of communication won’t work. What if both applications aren’t available at the same time, for instance? For situations like this, an asynchronous approach is required.

This kind of communication is exactly what Service Bus provides. Because it lets applications exchange messages through queues, Service Bus allows non-blocking interactions between different chunks of software.

Service Bus provides asynchronous communication between all kinds of software

Service Bus provides enterprise messaging among many kinds of software, including cloud applications, on-premises applications, and Azure services. Doing this well requires providing a diverse set of features—it’s harder than you might think. Accordingly, Service Bus provides all the following:

• Queue semantics, including message persistence and strict first-in, first-out ordering of messages.
• The service also detects and deletes duplicate messages.
• Atomic transactions, letting a queue read or write be part of a larger operation that succeeds or fails as a single unit.
• Poison message handling, so a message that causes problems won’t put a receiver into an ongoing loop.
• High availability, including geo-replication, along with built-in disaster recovery.
• In short, Service Bus provides all the features required for an enterprise messaging.

This Azure service also provides more, however. For example, Service Bus lets a user create one or more topics, then send messages to this topic. Receivers can subscribe to specific topics, then get only the messages sent to that topic.

Service Bus lets subscribers selectively receive messages sent to a topic

As the figure shows, receivers aren’t required to get every message sent to a particular topic. Instead, each receiver can define filters that determine exactly which message subset they receive. For example, a receiver that subscribed to a topic with messages carrying financial transactions might elect to receive only those messages with an amount of 10,000 Euros or more.

Asynchronous, message-based communication is an essential aspect of enterprise integration. Service Bus provides this and more like a cloud service on Azure. It’s a fundamental component of Azure Integration Services

Event Grid

There are lots of integration scenarios in which communication through messages rather than API calls is the best approach. But requiring receiving software to periodically check whether a new message has arrived—commonly known as polling—can be wasteful. Why not let a receiver be notified via an event instead?

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

Event Grid invokes receivers when a particular event has occurred.

As the figure suggests, many Azure services can generate events. For example, 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.

To receive an event from an Azure service, such as Blob Storage, the receiver subscribes to a standard topic provided for that service. But while subscribing to events from Azure services is probably today’s most common use of Event Grid, it’s not the only option. Cloud and on-premises applications can also create custom topics, letting Azure services and other software receive custom events by subscribing to these topics.

All of this raises an obvious question: Isn’t Event Grid awfully similar to topics in Service Bus? Why does Azure Integration Services include both? The primary reason is that Service Bus is an enterprise messaging system, with all of the reliability and features that implies, while Event Grid provides only a simple and fast way to send events. Some of the differences that flow from these divergent goals are these:

• Service Bus topics work with messages, not events. They let receivers decide when to read a message, and they require the receiver to actively poll for new messages. With Event Grid, events are raised by Azure Blob Storage or something else, then delivered to subscribers. No polling is required to receive these lightweight events.
• Event Grid is significantly more scalable than Service Bus, supporting up to 10,000,000 events per second in a single Azure region. To achieve this, Event Grid might deliver events out of order, while Service Bus guarantees in-order message delivery.
• Service Bus is fast, but Event Grid provides near real-time performance, with 99% of events delivered in less than a second.

Asynchronous communication is a necessary part of an iPaaS. By providing both Event Grid and Service Bus, Azure Integration Services addresses whatever communication needs your scenario might require.

The Microsoft Azure Service Bus is a cloud computing service, and this means a number of things. Firstly, the billing for the service is based on the usage, so with cloud computing, you’re going to be paying for compute instances, data storage, data transfer, and transactions. And with the Azure Service Bus, you don’t pay anything to actually create the messaging entities, it’s when we use those messaging entities and exchange messages on those entities that we’ll incur billing.

Cloud computing leverages the Economy of Scale to provide very cost-effective ways of being able to deliver services. There is a lot of infrastructures required to provide the reliable, globally-available Service Bus, and the massive data centres that Microsoft has been provisioning over the past few years allows them to be able to provide us with this infrastructure and charge us for using it.

Another thing that’s important today is the Economy of Resources. The data centres provide a lot of power-saving functionality to ensure that both costs and global emissions are kept as low as possible. With cloud computing, the resources are available on-demand, and that means that the provisioning time for creating services is typically measured in minutes, and sometimes it can be seconds. Cloud computing is also self-service, and this means that the consumers of the service are going to be responsible for provisioning and managing the services. We can either do this through a web-based interface or we can use an API to automate the process. Within the data centres, there’s very often no human interaction when we’re creating these services.

The Microsoft Azure Service Bus currently offers four technologies.

• Relay Service
• Brokered Messaging Service
• Service Bus Event Hubs
• Service Bus Notification Hubs

The Azure Service Bus Relay Service allows clients to expose endpoints in the cloud. The server that’s hosted behind the firewall can make a secure connection to the Relay Service. On receiving this connection, the Relay Service will activate an endpoint for the on-premise service in the cloud. Any client with internet access can then make calls to this endpoint, and the service calls are relayed back to the service host behind the firewall. This provides a very cost-effective way for companies and organizations to expose services, and the applications hosting these services can either be hosted on-premise or in a public or private cloud.

The Service Bus Brokered Messaging capabilities allow for durable entities, such as queues and topics, to be created and hosted in Azure Data Centers. In this example, a queue has been created. An application can then connect to the queue and send messages to this queue, and these messages will be stored durably. Receiving applications can then connect to these messaging entities and receive and process the messages. And as with the Relay Service, both the sending applications and the receiving applications can be hosted in the cloud or on-premise.

Service Bus Notification Hubs allow messages to be broadcast to a number of devices. Once a Notification Hub is created, an application can send messages to that Notification Hub. We can then have a number of mobile devices that will be receiving those messages. And Notification Hubs provide great scalability, allowing for messages to be broadcast to thousands, and sometimes millions, of devices.

Event Hubs provide telemetry services on a massive scale, and they’re typically used for large-scale application telemetry and Internet of Things scenarios. When an Event Hub is created, it can have a number of devices, and these could be applications, they could be console games, they could also be physical devices. These devices can then send telemetry messages to the event hubs, allowing for tens of thousands, and in some cases, millions of messages per second to be received and processed. This course will be focusing entirely on the brokered messaging capabilities of the Service Bus. There are additional courses on Pluralsight that will cover the other services.

References:
Microsoft Azure Service Bus Brokered Messaging In-depth
Azure Integration Services Whitepaper