Posts Tagged ‘Windows Azure Service Bus’

The Windows Azure Service Bus Notification Hub is finally released and it is generally available to be used in the development. It supports multiple platform push notification like Google, Microsoft and apple push notification. The Notification Hub will easily help the application to reach millions of users through their mobile or windows application by simply sending them a Notification through the Service Bus.

Here are the differences between the Windows Azure Mobile Services and the Notification Hub push notification. This table is taken from Announcing General Availability of Windows Azure Notification Hubs & Support for SQL Server AlwaysOn Availability Group Listeners

Mobile Services

Notification Hubs

MPNS, WNS, APNS, and GCM support

Yes

Yes

Turnkey event-triggered push

Yes

No

Device registration management

No

Yes

Interest tags for routing messages to a subset of users

No

Yes

Templates for formatting messages to user preferences including language

No

Yes

Broadcast to >1 million devices at once within minutes

No

Yes 

Advertisements

After the introduction of the Service Bus, we agreed that they are divided into 2 different types the Relay Messaging and the Brokered Messaging and here are the differences between them. In this post or application associated to it, we are going in more depth in it, we now understand the main functionalities that will be used in developing an application using the Brokered Messaging API and have seen how the code can be done with Brokered Messaging whether with queues or Topic & Subscription.

To create the Windows Azure Service Bus on the Windows Azure account you can read this blog post describing how to do it.

Now starting to work with the development, there are few things that you have to put in consideration like working with Service Bus doesn’t mean that you have to build Cloud or Windows Azure application, remember that Service Bus is a messaging platform where it can connect multiple application together no matter where they are hosted.

As previously described in a previous blog post, Building your first Service Bus Brokered Messaging using Queue. I am not willing to write the same code again, however I just want to clarify that this type of messaging is like the queue storage that is used to connect both the WebRole and the WorkerRole in Windows Azure Cloud Services. However the Service Bus Brokered Messaging using queues also connects multiple roles together, with certainly some differences between them, you can find them here.

Here is a complete guide for the Windows Azure Service Bus Libraries, the Microsoft.ServiceBus & the Microsoft.ServiceBus.Messaging, they are based on the .Net SDK 1.8 Version.

Here is a link for the project discussed using Microsoft Windows Azure Service Bus Brokered Messaging using queue.

We have seen before in previous blog posts how to communicate between the Windows Azure Cloud Services roles WebRole and WorkerRole using Queue Storage. I also introduced the Windows Azure Service Bus, and showed the development of the Windows Azure service bus using queue messaging. As both of these types of queue are used for the connection between multiple roles, like the previous explained WebRole and WorkerRole communication using the queue storage and the inter role communication using the Service Bus queues.

For the Queue storage, some people don’t consider it as a storage for a simple reason that it is not durable. The queue storage only be stored for a maximum time of 7 days as for the Windows Azure Service Bus queues, its time to live is more flexible than the queue storage and you can decide its duration on creating the Service Bus itself on Windows Azure. For the queue message, the queue storage will not allow more than 64 KB in the same time the service bus queue messaging will accept more than 64 KB it can work with more than that but less than 256 KB. In the other hand, this point that you should take in consideration that the Windows Azure Queue storage will give you the ability to exceed 5 GB as the total size of all queue messages in the interval of time to live but the service bus queue storage will not allow you to reach this size, it is preferable that the total size of all queues be less than 5 GB during the interval of time to live for the messages.

However the queue storage is a very easy to implement, you can see an example in the following link. For the Windows Azure Service Bus brokered messaging using queue storage, will require more development, integration with WCF service.

You can find all about the predefined functions for the queue storage in the following document. You can also find all the predefined functions for the Microsoft.ServiceBus DLL and the Microsoft.ServiceBus.Messaging DLL.

For more information about the differences I really recommend you to read the following web page.

After the Windows Azure Brokered Messaging API post, I will show you how to create your service Bus for Brokered Messaging through the portal and how to connect it your application on Visual Studio 2012, after that you will be able to start building your first application using Windows Azure Service Bus Brokered Messaging whether by using the queue or even by using the Topic/Subscription

First of all open your Windows Azure portal and follow one of the below instructions:

The first one is by clicking on the +New button and getting everything from there, you will be able to define the type of service bus you want whether topic, or a queue one.

After that you can choose the type you want to start using, here is some basic information about the Relayed VS the Brokered Messaging (Topic/Subscription or queue). As for the Windows Azure Service Bus Notification Hub, you can find all the details in here.

After choosing one of the Service Bus Services, you will be asked for to choose between “Quick Create” or “Custom Create”. The main difference between both is that the “Quick Create” creates the Service Bus with Default Configuration Settings and in “Custom Create” you will have to define the configuration yourself.

if you choose the “Custom Create”, here are what will ask you to enter. (In the following case assuming that you want to build a queue Service Bus). You will have to enter the following fields, the queue name, the region where you want to host your service bus (you will have 8 choices, 8 Windows Azure datacenter worldwide, you will have to choose the best one most probable the nearest to you or your applications). Watch out that the Namespace Name must be unique, this what define your service bus between the others.

The second page is where you can define the required configurations.

For the topic Service Bus, it goes with the same process but only in the configuration part, there will be a slightly difference. Like the following:

Certainly you can skip the above step by simple choosing “Quick Create”, it will configure it for you with the default configuration like the below picture.

Let me here explain a bit the configurations for the queue and the topic (Common configurations):

  • Max Size:
  • Default Message Time to Live :
  • Enable Duplicate detection:

For the Queue configuration:

  • Move Expired Messages to the dead-letter subqueue:
  • Enable sessions

The other way where you can create the Service bus is by going to Service Bus button on the left most of the portal.

After that, just click on the button create a new service bus, you should be prompted with the following message:

This is where you will have to define the service bus namespace name and the region where the service bus will be hosted.

Once the service bus is created you will be able to see the following page, where you can make all the required configuration for whatever type you choose, the relayed, Topic/Subscription, or even Windows 8 Notification Hub.

If you want to work with queue, you can create on the queues in the top of the page where it will directly get you back to the “Quick Create” or the “Custom Create” step again.

Now connecting your application with Visual Studio:

To connect your service bus with your application on Visual Studio, you will need what is called the management access Key. If you go to your service bus page on the portal you will find the access key at the bottom of the page. Once you click on it, a new windows will be prompted and you will be able to see your keys, the connection string that you will use, to connect to your service bus, the default name which is the “issuerName” and the Default Key “issuerKey” (these are used most probably during the development).

After copying the above 3 things, you will have to go to Visual Studio:

In you service Definition file enter the following line of code to define that your application will require a connection o Service Bus

<WebRole name=”MyRole” vmsize=”Small”>

<ConfigurationSettings>

<Setting name=”Microsoft.ServiceBus.ConnectionString” />

</ConfigurationSettings>

</WebRole>

After that go to your configuration file and define the connection string and enter the value of the connection string that you got from the portal from the access key.

<ConfigurationSettings>

<Setting name=”Microsoft.ServiceBus.ConnectionString”

value=”Endpoint=sb://[yourServiceNamespace].servicebus.windows.net/;SharedSecretIssuer=[issuerName];SharedSecretValue=[yourDefaultKey]” />

</ConfigurationSettings>

Now Congratulations your applications is now connected to your service Bus, Now let’s start Building your first Queue or Topic/Subscription application