In this video, Sharon provides an overview of the Azure Service Bus Messaging solution, including the benefits, use case, design, and tiers. She also demonstrates how to implement the Azure Service Bus Messaging solution.
- [Woman] The Azure Service Bus messaging feature allows applications to interact with other applications as well as other services, both in and out of Azure. The Azure Service Bus is a messaging as a service feature of Azure. Sometimes you may see this referred to as MAAS. It allows us to connect across on-premise and cloud environments. I like to think of it as an information delivery service similar to the physical postal service where data is delivered even if the parties do not know each other or are online.
In the example of the postal service, we would say that the sender and receiver are decoupled and that's exactly what a service bus allows. It allows us to share data between systems that are decoupled. The sender and the receiver do not know each other and are not dependent on each other. Let's look at a few use cases for the messaging service. Think about financial services and interbank transfers. The sender bank does not need to know about the receiver bank and the receiver bank doesn't need to know about the sender bank.
Next would be logistics and order processing. This is a great example. An order is placed into the system and then another system processes that order. And health care, the transfer of medical records between different systems. Maybe your x-rays going back to your family physician. The sender and receiver are not dependent on each other for that transfer to occur. We have three communication options when we're referring to the service bus. First of all we have queues and queues allow for one-direction communication.
We have topics and subscriptions, again these allow for one-direction communication but the receivers can only pull from the subscriptions. And finally we have relays which provide bidirectional communication. Data can go between the sender and the receiver. This is a very high level overview of these options. We're going to explore each of these in detail in the upcoming lessons. And with as most things in Azure, there are different tiers that we can select from and the tier that you select will be based on your needs for your messaging system.
We have three tiers, there's a basic, standard, and premium. The maximum message size for the basic and standard tiers are 256 kilobytes. And under the premium tier, your message size can be one megabyte. Queues are available in the basic, standard, and premium tiers, but if you need to use topics and relays, you're going to have to move into a standard or premium tier. And scheduled messages are available in all three tiers. No matter which type of service bus you'll be implementing, you will need to have a namespace.
I like to think of a namespace as a container for entities which are the queues, topics, and relays. And you'll notice from our example here that entities can be mixed and matched. For example, in Namespace 1, we have two queues, Queue A and Queue B. Whereas in Namespace 2, we have combined topics and relays. Now that we've provided a little bit of an overview of the Azure Service messaging system, let's go ahead and provision one within Azure. I've gone ahead and created a resource group called LiLMessaging for our demonstration.
I'm going to pop into that resources group. I'm going to scroll over for a slightly better view. And you'll notice that I have nothing in this resource group so I'm going to go ahead and add in a service bus. To do so, click Add. I'm simply going to search for service. And next I'm going to pick the Service Bus. The Service Bus blade will open providing a little bit of information about the service bus. I'm going to go ahead and click on Create.
First thing I need to do is create that namespace. And you'll notice that this will need to be a unique namespace because we are using .servicebus.windows.net. I'm simply going to call it Lilnamespace. Next we can go ahead and pick that pricing tier. For our demonstration, I'm going to go ahead and use the Standard tier. And the reason I'm selecting this is because it will include topics which we'll be covering in an upcoming lesson. You will notice though, under the Premium tier, that this is the tier that is recommended for your production workloads.
And then go ahead and click Create and that's all there is to it to create the service bus. Now that our service bus is created, let's go ahead, close our blades, I'm going to refresh on our resource group and we can take a look at that service bus. You notice that we have shared access policies that we can use within this service bus. You'll also notice that we have a default one already there. We'll be talking about shared access policies in a little bit more detail in an upcoming lesson. We have our entities, queues, and our topics.
And as I've already mentioned, we'll be discussing these in the following lessons. To quickly recap, we use a service bus to decouple our senders or receivers or our front ends from our back ends. And it allows us to connect across on-premise and cloud environments.
- Creating compute-intensive applications
- Creating long-running applications
- Implementing messaging systems
- Azure Service Bus relays
- Using Azure Storage queues
- Creating an Azure Event Hub
- Creating Azure WebJobs
- Managing cloud environments with Azure Active Directory Domain Services