AZ-303 Microsoft Azure Architect Technologies – Implement Solutions for Apps (10-15%) Part 5

11. Service Bus Introduction

Azure Service Bus is a multitenant cloud messaging service that sends information between applications and services. The information is stored in a messaging queue. The Asynchronous operations give you a flexible brokered messaging along with structured processing and a published subscribe capabilities. Queues offer first in, first out messaged delivery systems. That is, receivers typically receive and process messages in the order in which they were actually added to the queue, and only one message consumer receives and processes each message. The Service Bus implementation takes care of this for you. A key benefit of using queues is to achieve the decoupling of application components. In other words, the producers or senders and consumers.

Receivers do not have to be sending and receiving messages at the same time because the messages are stored durably within the queue. Furthermore, the producer does not have to wait for a reply from the consumer to continue the processes and send messages, and this consumer doesn’t even have to be online at that moment in time. In contrast to queues in which each message is processed by a single consumer, topics and subscriptions provide a one to many form of communication in a published subscribe pattern.

These are useful for scaling to large numbers of recipients. Each published message is made available to each subscription registered with the topic. So messages are sent to a topic and delivered to one or more associated subscribers, depending on any filter rules that could be set on a per subscription basis. The subscriptions could then use additional filters to restrict the messages that they want to receive. So, for example, if you were processing delivery orders, rules could be used to identify the nearest subscriber to make that actual delivery.

Messages are sent to a topic in the same way that they’re sent to a queue, but messages not received from the topic directly instead they receive from subscriptions. A topic subscription resembles a virtual queue that receives copies of the messages that are sent to the topic. Messages are received from a subscription identical to the way that they are received from a queue.

So, because Azure supports two types of queue mechanisms the storage queues and the service bus queues, it’s important to know the differences between the two. As we can see from the following table, storage queues don’t guarantee ordering, whereas service bus queues do. With storage queues, delivery is guaranteed at least once, whereas with service bus queues it’s guaranteed at least once, but only once. As we can see, there are some similarities, but there are also some differences, and it’s important to understand these to decide which would be best for your application.

As a solutions architect, you’ll not be responsible for understanding the code to produce or retrieve the messages, but you will be responsible for interpreting the service plus namespace, obtaining management credentials, creating the queues topics, and then managing and monitoring the queues and topics. Service bus queues are typically partitioned into namespaces. Each namespace provides both the service and the security boundary. A Namespace is a scoping container for all messaging components, and multiple entities can reside within a single namespace, and namespaces often serve as application containers. In this diagram, a service bus relay is shown. The Azure Relay service facilitates your hybrid applications by helping you more securely expose services that reside within a corporate enterprise network to the public cloud. You can expose those service without opening a firewall connection and without requiring intrusive changes to a corporate network infrastructure. So let’s go ahead and actually build our own namespace.

12. Service Bus Walkthrough Part 1

As always, it’s much easy to understand if we actually create and use these services. So the first thing we need to do is create a service bus instance from this year Portal. Go ahead and click create resource and search for service bus first thing we need to do is give our service bus name and then select pricing tier. If you choose Basic, you can only choose Queues. But because we want to do queues and topics and subscriptions, we’re going to need to go for the standard pricing. Generally speaking, the costs aren’t too much.

If we just did the standard tier without doing many requests at all, say less than a million a month, then the actual cost would be around $10 a month. And then from there the price goes up depending on how many calls you need to make to the service. Next, I’m going to create a resource group to put this in and finally tell it which location to go in. Once that’s finished, we can go to the resource and the first thing we’re going to do is create a queue.

So from the overview page we can see here we’ve got these options to create queues and topics. So go ahead and click Queue and we’ll give it a name so we can define some basic options. So first of all, we define the queue size so you can actually tell it how big or small you need to be. You can see there’s not a huge amount of options and we’ll just go for the minimum.

Next, we can set the message time to live. So if a message goes in a queue at the moment, by default it will only last 14 days, after which point if it hasn’t been processed and removed, it will just be deleted from the queue anyway. You can increase or decrease this as your application needs. Again, the lock duration. When another service picks up an item from the queue, it tells the queue that it’s starting to process it. If it doesn’t finish processing and release it during 30 seconds, then the lock will automatically be removed.

However, for the 30 seconds that it’s processing it, that lock prevents any other processors from trying to pick it up from the queue. And then we’ve got these extra options here so we can enable duplicate detection to ensure that we don’t have multiple messages in the queues, enable dead lettering on message expirations, enable sessions and partitioning.

If we hover over each of these, we get simple messages and ideas, simple messages to show us what these actually mean. So for example, the partitioning, it’s telling us that it partitions the queues across multiple message brokers and message stores. This is great when you have large amounts of messages and need to be able to increase the processing. The enable sessions is quite important if you want FIFO functionality. So FIFO means first in, first out. Without that enabled, you are not guaranteed to get the first in, first out with your messages. Once we’ve got the basic items in place, go ahead and click Create.

Once the queue is created, we can go into it and see various bits of information about it queue size and any messages that might be in. A useful piece of information to know is that if we go into the properties, we can change some of those defaults reset early, such as lock duration, but we can also disable the queue state. So by disabling the queue state, it stops any application sending or reading messages from it, but it still keeps the object alive, ie. We’ve not deleted it. So now we want to test this queue that we’ve set up. So what we’re going to do is bring down an example again from GitHub. The one we’re going to want is this time in Azure rather than Azure Samples and it’s called Azure Service Hyphen Bus. So this actually contains the source code for the Service Bus modules themselves, but importantly contains these samples. So I’m going to want to just clone that while make a copy of the location. And now in Visual Studio, I’m going to tell it to Clone or checkout code. I’m going to paste in the URL my Git repository and then I’m going to click Clone.

So that’s going to pull down that repository to Visual Studio. And while it’s doing that, just go back to our Service Bus and we need to go to this shared access policies here. And in here is where we can create and obtain keys to be able to read and write messages from the queues. So we get one created by default. And I want to copy this primary connection string. As you can see, this default queue allows us to manage, send and listen to messages. In the real world, what you’d probably do is create different shared access policies.

One access policy might allow you to send messages to the queue and a separate policy may allow you to listen. And as you create separate policies, they each get their own primary secondary keys and therefore their own different connection string endpoints. For the purpose of this, we’re just going to go ahead and use the root managed key. So once we pull down this one, go to the short folder, view and navigate through Samples net. Getting started.

And first of all, we want this basic send and receive quick start. Open that and then open the solution. Now open the program. Now if we look at this application code, you can see that it’s a console application and it’s going to want us to sending arguments for the connection string and the queue name. I’m just going to override these to make it work with first of all the connection string that we’ve just copied and then the queue name that we created.

I’m not going to go into too much about the code, but I’m just going to have a quick run through what it’s actually doing. So with console applications, they all start with this static main void and that’s what gets run when you first run the code. So it’s going to look for these arguments which we’re not going to supply, but that doesn’t matter because we’ve actually hard coded them up here. It just does a check to make sure we’ve got a connection string and a queue name filled in. And then if everything’s okay, it executes this main async.

This main async task does a couple of things. The first, it sets the number of messages. So at the moment just ten. And then it creates a queue client. So this queue client is connecting to our service bus string that we’ve just pasted in and to the particular queue that we’ve just created. It then does this register on message handler and receive messages.

So what this does is it basically sets some options and it registers another task called process messages with these options. And basically what this is doing is it’s registering a task against the message receive portion of the queue. In other words, this here will receive notifications when items go in the queue and action something.

And this actual process message is the bit where the action happens and all it’s going to do is just do a right line saying it’s received a message, what sequence it’s received in, and the body of the message itself. It then tells the client that it’s actually finished processing, which will then release the lock. So once it’s registered that message handler, when new message go in the queue, it then goes and executes another task which is to send a set of messages.

And as you can see, we’re passing in the number of messages, which is ten. So now all this is going to do is just looping through for the number of messages and for each one it’s going to send a message with the message body of message and the number and it’s going to send those messages from the queue. So what we should see is the console sending messages to the message queue and then at the same time we should see it receiving the messages and printing them back out. So let’s go ahead and run this program and see what happens.

So we’ve sent the messages, ten messages starting at zero, and then as it’s received the messages in and our program has been notified of the messages, it’s then printed them out. As you can see this first one here, it received the notification while it was actually sending you the messages, hence while we’ve got this slight out sequence message. But that’s just a very basic example of how we can send and receive messages from a queue in a real life situation. These would be separate programs to perform the activities that you require. Quit out of that, close that down. Now go back to your overview of here and in the next lecture we’ll go ahead and create a topic and subscribe encryption and use that rather than the queues.