In this series:
- Part 1 - Why Use Messaging?
- Part 2 - The Challenges of Messaging
- Part 3 - Introducing Azure Service Bus
- Part 4 - Sending and Receiving Messages
- Part 5 - Message Sending Options
- Part 6 - Message Receiving Options
- Part 7 - Topics and Subscriptions
- Part 8 - Commands and Events
- Part 9 - Premium Features
In the last two posts I talked about the benefits and challenges of messaging. In this post, I want to give a very brief introduction to Azure Service Bus, and show you how to create an Azure Service Bus "namespace" using the Azure CLI. We'll then be able to use this Service Bus namespace in future posts demonstrating how to implement various messaging operations.
What is Azure Service Bus?
Azure Service Bus describes itself as "cloud messaging as a service". Basically it fulfils the role of a "message bus" or "message broker". In other words, you send your messages to Azure Service Bus, and it stores them and makes them available to the message recipients when they poll for new messages.
Queues and Topics
Azure Service Bus allows you to publish messages to queues. A message queue is very simple. The messages sent to a queue are held there until a recipient asks to receive a message. The recipient is then given the first message on the queue (i.e. the earliest one that was sent). The recipient can keep polling until all messages have been processed and the queue is empty.
But there is another way of sending messages, known as "publish and subscribe" (or "pub/sub"), where instead of sending messages to a "queue", you send them to a topic. The difference is that a topic can have multiple "subscribers". For example, if a topic has three subscribers, then when I publish a message to that topic, essentially three copies are made, one for each subscription. This is great when the messages you send might result in multiple actions. It's a very powerful pattern when you are sending "events" as messages.
We'll return to the idea of queues and topics later in this series, but for now it's enough to know that these two main styles of message publishing are available, and Service Bus allows you to use a combination of approaches.
Creating a Service Bus Namespace
To get started with Azure Service Bus you need to provision your own "namespace". This essentially gives you your own private Service Bus, with its own security credentials. When you create a queue or a topic, you create it within your namespace.
In this post, I'll show you how to use the Azure CLI to create a Service Bus namespace from a PowerShell prompt.
We'll start by creating a resource group
$resourceGroup = "servicebustest" $location = "westeurope" az group create -n $resourceGroup
Now let's create a unique name for our namespace (that's important because it forms part of a domain name), and then create the namespace with
az servicebus namespace create. There are a few pricing tiers (called "sku"s by the CLI) for Service Bus - we'll just use the standard pricing tier (which costs about $10 a month).
$namespaceName = "marksb$(Get-Random 10000)" az servicebus namespace create -g $resourceGroup ` -n $namespaceName -l $location --sku Standard
I'll also create a queue, which we'll use in our next demo. I'll call it
$queueName = "queue1" az servicebus queue create -g $resourceGroup ` --namespace-name $namespaceName -n $queueName
Finally, let me show you how to get hold of the connection string, which we'll also need for our next demo
az servicebus namespace authorization-rule keys list ` -g $resourceGroup --namespace-name $namespaceName ` -n RootManageSharedAccessKey ` --query primaryConnectionString ` --output tsv
This produces something like this (I've changed the key):
You can of course also create a Service Bus namespace in the Azure Portal, and access the connection string that way, so if you want to follow along with demos for the next parts of this series, why not create yourself a Service Bus namespace.
In the next installment, I'll show how we can use the Azure Service Bus SDK to post a message to this queue and read it off the queue.