Azure Service Bus

Microsoft Azure's Service Bus is a cloud service that helps provides the ability to share data among decoupled systems. In this article, we will learn how to leverage Azure's Service Bus with Brokered Messaging to distribute data among systems. However, if you are at all familiar with Azure services that provide support for distributed systems, you'll know that Service Bus is not the only service of its type.

Azure's Queue Storage service also provides similar functionality and provides the ability to share data among distributed systems. So what queue service is right for you? These questions as well as the following topics are all areas we will be covering.

  • Service Buses

  • Service Bus vs. Queue Storage

  • Brokered vs. Relay Messaging

  • Queues vs. Topics and Subscriptions

  • Getting Started with the Building Blocks

  • Asynchronous Approach

  • Service Bus Queues

  • Sending Messages

  • What Kind of Message are You Sending

  • Receiving Messages

  • Topics and Subscriptions

  • Dead Lettering

  • Auto Forwarding

  • Transactions

  • Batch Processing

  • Security

  • Best Practices

Service Buses Simply put, Service Bus is the second message queuing platform built by Azure that provides Relay and Brokered Messaging capabilities. It is feature-rich and a matured service that can provide a way for decoupled systems to exchange information independently. Azure's Service Bus is one of the many Platform As A Service (PaaS) services and can be as simple as a single queue or highly complex message workflow with a near-infinite number of interrelated queues, topics and subscriptions. Service Bus vs. Queue Storage As I have already pointed out, Service Bus is not the only message queue service Azure offers nor was it the first. But there are significant differentiating features between Service bus and Queue Storage, Azure's first message queuing service. We will be diving deeper into the features of Service Bus with the Brokered Messaging offer, but it's important that you are aware of when to use which service. Microsoft has provided a comparisons and contrasts document to help you make that decision. However, with the limited reasons for using the Queue Storage service, we can quickly summarize when Queue Storage would be the best chose. If you are in need of the least complex approach and your application meets the following needs, Queue Storage would be the best choice:

  • Needs to retain more than 80 GB of data in queue

  • Message time to live less than 7 days

  • The ability to track message processing within a queue*

As you can see, the message storage size and time to live are the two key differentiating points of an Azure Storage Queue service. Naturally, the data retention aspect of the Storage Queue service is due to the underlying Storage service. So, unless one of these points is a critical requirement, the Service Bus service will be a more feature-rich and versatile option.

However, within the Service Bus service, there are more than one messaging capabilities. This article is focused on Service Bus with Brokered Messaging. But, Brokered Messaging is not the only messaging capability that Service Bus offers. Relay is another option that you will read about when investigating Azure's Service bus, so let's take a quick moment to distinguish the two. Brokered vs. Relay Messaging So far we have only mentioned Brokered Messaging with Azure Service Bus. But this is not the only messaging capability provided by Service bus. Instead of the pattern of queuing messages that we have been alluding to so far, Relay Messaging provides the ability to “bounce” a message off of a service to an connected receiver. It requires that the receiver expecting the message is online and available. A strong point of Relay Messaging is the ability to expose the service's endpoint without the typical network firewall and infrastructure configuration hoop-jumping to make it available to external clients. However, durability is not as much of a strong point of Relay Messaging as it is with Brokered Messaging. Brokered Messaging supports the scenario of truly temporal decoupled systems where the availability of either the message producer or consumer is not guaranteed. Therefore, messages that are not immediately delivered must live somewhere and that is where the “broker” comes into play. With Brokered Messaging, the queue is the broker that retains a message created by a producer and where the consumer can retrieve the message when ready. So whereas the exposure of