Service Bus Messaging

This section will look at the Azure Service Bus Brokered Messaging capability.

What is it?

Azure Service Bus Brokered Messaging is a feature within the Azure Service Bus which provides a highly scalable cloud based platform as a service message queuing capability. The Azure Service Bus Brokered Messaging supports AMQP v1.0 to provide interoperatility with with other technologies but the Service Bus also supports a REST based approach too.

In Service Bus you can use either a queue based store and forward type messaging and also topic based messaging which supports a publish and subscribe messaging style.

Being on top of messaging issues with proactive monitoring of Azure Service Bus dead-letter messages across multiple Queues and Topic Subscriptions.

The below picture shows an example of how many different clients can interact with Azure Service Bus queues using AMQP or another protocol and how the messages could be processed later by a message processing component.

Features

• Queue based messaging for store and forward
• Topic based messaging for publish/subscribe patterns
• Partitioning of queues to support improved reliability
• AMQP 1.0 support
• REST support
• .net SDK support

Strengths

The key strength of the Azure Service Bus Brokered Messaging feature is the combination of its huge scale combined with its simplicity. The queues are really easy to interact with from many different languages and technologies yet you can build apps which can scale to huge volumes using service bus.

Dependencies

The only dependency is that you need a Microsoft Azure subscription. Once you have your subscription set up then you are ready to create a Service Bus namespace in the Azure portal and from there you just create a queue and your ready to go.

Costs

The costs for Azure Service Bus Brokered Messaging are really good. The model is that you pay a small amount for a very large number of messages. There is no big up front cost you just pay for what you use. When your namespace isnt processing any messages then it doesnt cost you anything.

We have seen small and medium usage customers who hardly notice they are spending anything but for very large users you might need to spend some time to understand how many messages you will be processing. As a guide though your paying approximately $1 for 100,000 messages.

Related Technologies

The following technologies are similar or related to Azure Service Bus Brokered Messaging.

Windows Server Service Bus

Windows Server Service Bus is very similar to Azure Service Bus Brokered Messaging except that it is hosted on a Windows machine by you. In Azure Service Bus it is hosted by Microsoft as a platform as a service capability. You can interact with both products from an application in pretty much the same ways and both can be used from the same SDK. Windows Server Service Bus does not include the other products which come with Azure Service Bus such as Relay and Notification Services.

Customers may use both Azure Service Bus and Server Service Bus at the same time but for different purposes. Server Service Bus is likely to be used for on premise inter-application messaging where as Azure Service Bus is used for cloud scale messaging or bridging out to apps and partners outside of the organisation.

MSMQ

MSMQ is similar to Azure Service Bus Brokered Messaging in that it supports store and forward based first in first out messaging. There are a number of differences though. Firstly MSMQ uses a proprietary protocol where as Azure Service Bus supports better interop through support for REST and AMQP. MSMQ is also hosted as a Windows Server component where as Azure Service Bus is hosted in the cloud.

MSMQ is more likely to be used in on-premise only scenarios. If you had an existing on-premise implementation which heavily used MSMQ then you may create a bridge component to move messages from MSMQ to Azure Service Bus and back.

BizTalk

Sometimes people struggle to understand the differences between BizTalk and Service Bus Messaging. BizTalk is an Integration Broker where as Service Bus Messaging is a Message Broker.

They both play the role of a brokere but for different scenarios. Service Bus receives messages and puts them onto queues from which an external party can come and collect the messages from the queue.

BizTalk receives a message and uses its own internal queue concept but attempts to send the messages it has received to an endpoint.

The key difference is that BizTalk is a push delivery model and Service Bus Messaging is a Pull delivery model.

BizTalk also has a lot of other features beyond just messaging which helps it to participate in other use cases but both products share the capability of durable messaging, but they are implemented in a different way.

BizTalk and Service Bus can be used together very effectively.

Samples

• BizTalk and Azure Service Bus Messaging
• Azure Service Bus Fanout

Learn More

• Technet wiki
• Service Bus Messaging Deep Dive with Clemens Vasters

Product Positioning