Cloud Architecture Series-Durable Messages using Windows Azure (Cloud) Service Bus Queues–Establishing your service through the Portal

Introduction

The purpose of this post is to explain and illustrate the use of Windows Azure Service Bus Queues.

This technology solves some very difficult problems. It allows developers to send durable messages among applications, penetrating network address translation (NAT) boundaries, , or bound to frequently-changing, dynamically-assigned IP addresses, or both. Reaching endpoints behind these types of boundaries in extremely difficult. The Windows Azure Service Bus Queuing technologies makes this challenge very approachable.

There are many applications for this technology. We will use this pattern to implement the CQRS pattern in future posts.

Topics

Windows Azure also implements the concept of "Topics." In a topic-based system, messages are published to "topics" or named logical channels. Subscribers in a topic-based system will receive all messages published to the topics to which they subscribe, and all subscribers to a topic will receive the same messages. The publisher is responsible for defining the classes of messages to which subscribers can subscribe.

Topics are one-to-many (pub-sub model)	In contrast to Service Bus queues, where each message is processed by a single consumer, topics and subscriptions provide a one-to-many form of communication. Topics represent the publish/subscribe pattern.
One to many	It is possible to register multiple subscriptions (or listeners/receivers) to a topic.
Pub-Sub	When a message is sent to a topic, it is then made available to each subscription to handle/process independently.

Well known pattern in computer science

These technologies reflect well known patterns in computer science, such as the "Pub-Sub" or publish-subscribe pattern. This pattern allows senders of messages (Publishers) to send these messages to listeners (Subscribers) without knowing anything about the number of type of subscribers. Subscribers simply express an interest in receiving certain types of messages without knowing anything about the Publisher. It is a great example of loose coupling.

Publish-Subscribe Pattern

http://en.wikipedia.org/wiki/Publish/subscribe

Getting Started at the portal

The next few screens will walk you through establishing a namespace at the portal.

Essential Download

To create a Service Bus Queue service running on Azure you’ll need to download the Azure SDK here:

http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-13-13-metablogapi/0247.lahxjo2d_5F00_3.jpg

Establishing a namespace for the service bus endpoint

Select “Service Bus, Access Control & Caching” as seen below.

Creating a new service bus endpoint

Click “New”
0qqwhgy4

Providing a namespace, region. Selecting services.

The end result

Summary of information from portal

Namespace	dataevents
Service Gateway	https://dataevents.servicebus.windows.net
Management Endpoint	https://dataevents-sb.accesscontrol.windows.net
Default Issuer	owner
Default Key	xzjyCn3ZHOgIsmavht5Xhsb9ZATZcmn5jdakLMN/ffc= [typically you would keep this secret but is included to help explain the process.] Thank you Valery for making this clear.