What is Service Bus?

- [Instructor] Let's start by understanding what is Service Bus? Azure Service Bus is a multitenant cloud messaging service that sends information between applications and services. Know this does not mean that those applications and services need to reside in the cloud. All this means is that Service Bus itself is a cloud based service. The conduit through which your messages flow, go through Azure cloud.

So what are some common messaging scenarios that Service Bus helps you implement, starting with messaging. This allows you to transfer business data. It's pretty simple. It allows you to transfer things like sales or purchase orders or journals or inventory movements, really anything. Another scenario is to decouple applications. Decoupling applications help you improve reliability, and scalability, of those applications. Because the client and the service don't need to be online at the same time.

Also, decoupling applications generally means if one link in the chain goes down, the rest of the chain doesn't go down. Then we have a concept called topics and subscriptions. I'll talk more about this shortly, but at a high level, this allows you to build one to n relationships between message senders, also known as publishers, and subscribers. And finally, message sessions.

They allow you to implement workflows, where you care about message ordering or things like message deferral. At the heart of Service Bus is something called Azure Service Bus Namespace. Think of the Namespace as a scoping container for all messaging components. Multiple cues and topics can reside within a single Namespace. And Namespaces often serve as application containers.

So inside of a Namespace, we would provision something called as a queue. You can have more than one queues. And multiple queues and topics can reside within a single Namespace. So another thing that we build upon queue is called Azure topic, and topics are where publishers will push their information to, and then subscriptions are interested parties that are interested in listening to what those topics have to say.

The important thing being that these queues, and these topics, and these subscriptions, they all live within your Service Bus Namespace. Let's understand queues a little bit more. Messages are sent to and received from queues. It's pretty simple really. Queues enable you to store messages until the receiving application is ready to listen to those messages. Messages in the queue are ordered and timestamped on arrival.

Once accepted, the message is held safely in redundant storage, so you don't lose any of those messages. And then these messages are delivered in pool board, so the receiver has to ask for a message. In contrast, topics and subscriptions, well they are slightly different. They can also be used to send and receive messages acing currently. But a queue is generally point to point communication.

Where topics are useful in a published subscribe scenario, individual topics can have multiple independent subscriptions. A subscriber to a topic can receive a copy of each message sent to that topic, or, have the ability to specify rules and filters so certain receivers gets certain messages, or possibly one message is delivered to more than one receiver.

And Service Bus also supports a whole bunch of other concepts, as you see over here. As you can see, this is a fairly powerful technology. Service Bus also fleet integrate with notable agile services, as shown here. Things like Event Grid, Logic Apps, Functions, Dynamics 365, Stream Analytics, all of them work with Service Bus quite well. And if you're aware of what even greater for instance, it really allows you to bring Service Bus to a whole bunch of other services, not to mention it comes with a very simple API that the various other services can use anyway.