Posts Tagged ‘Live in a Cloudy World’

After introducing the EAI (Enterprise application Integration), and its solution the Windows Azure Service Bus and its different solution, the Brokered Messaging, the Relay Messaging and the difference between them. I went in details with the Brokered Messaging API and here I am into the Relay Service in deeper.

Unlike the Brokered Messaging target to connect multiple clients to an application, the Windows Azure Relay Service is to connect multiple application together from different datacenter, in our case one will be on the Windows Azure and the second one will be the company datacenter. The Relay service is offering to communicate multiple application across multiple datacenters to deliver reliable application.

To work with the Relay Service, this will require you to develop a WCF Service it doesn’t require more than that. All you have to do later on is to define the service bus endpoints in your configuration file and after that create the endpoint programmatically in your application using the normal WCF with defining the Service Bus Environment in it. Certainly you will have to define what type of binding you are willing to work with. Here are the types of the Binding you can work with and the differences between them, the NetTCPRelayBinding, the WSHTTPRelayBinding, the NetOneWayRelayBinding and the NetEventRelayBinding.


For those who have worked with the Windows Azure Mobile Services, after building a new Windows Azure Mobile Services you can download the application or connect it to the application you have already built. For each application you build using this mobile service or for any change of the application domain you will have to add its domain to the Windows Azure Cross-Origin resource sharing known as CORS. The reason you will have to do so is to allow the communication between the different applications, from different platforms with different URLs to communicate with your Windows Azure Mobile Services.

I have faced this error especially when I was developing an application on the local machine. If you have downloaded the application from the portal directly and have run it without any modification it will run smoothly without any errors, the reason it worked smoothly is that if you went to the CORS under the configuration you will find the local host added to the CORS.

If you have added a new project to your solution that you have downloaded from the portal, and just run it. You will find that it will run smoothly but won’t execute any functions that require actions from the Windows Azure Mobile Services. The reason is that your application that runs on your local machine is not using local host but an IP with that you will have to add it manually on your Windows Azure Mobile Services only for the testing after that I think that you will have to remove it before publishing the application.

After a while of putting Node JS on Windows Azure, and the people start working with it plus the great advantages Node JS is offering to the clients and its great performance and some advantages over the web API. Windows Azure is now offering Windows Azure mobile services that will help the developers build applications for different platforms with a very easy way to store, push notification and even provide identity with the integration with several identity providers like Hotmail, Google, Amazon and others.

So how to create a Windows Azure mobile service?

There are few several steps to be done to create your Windows Azure Mobile service through the Windows Azure portal.

After signing in to the Windows Azure portal, just click on the button “New”, select “Compute” then “Mobile Service” and finally on “Create”.

A new window will be prompted and you will be asked to enter a valid URL for the Mobile Services, choose whether you want to create a new SQL database or connect to an existing one and the location you want to host your mobile services in.

After you click on next, you will be asked for the username and the password for the database. You will have to enter the required credentials and after that you will see the Mobile services is being created.

Now let’s dig a bit more in the Mobile service. When the Windows Azure finishes creating the mobile services, click on it and the following page will open.

This page offers you all what you can do with the Windows Azure mobile services. The first one, the button that has a look of a cloud and a thunder in it will bring to this page, where you can choose the platform you want your mobile service to connect to it. you can see a lot of different platform you can connect to them using the Mobile services. In the Get Started you will have 2 options whether you can download a full application for the required platform so you can build application for it or it can helps you to connect to an application that you have already started developing it.

The next button which is the Dashboard, it gives you a small monitoring on the mobile services with statistics, certainly with all the required information about the Mobile services, the location, its URL and so on.

The Data button is the one responsible for the data you entered in the Windows Azure mobile services. You can create several tables as much as you need, all these tables are automatically created in the database related. One of the best things in the Mobile Services is that the table created has dynamic columns which means that you can add new fields in the table as much as you need whenever you want. You will not have to create these columns on the table creation but depending on your application demands.

Lately Windows Azure Mobile services has started to support different Node JS NPM so you rather than just building mobile application with some limited functionalities now it gives you the opportunity to develop and do more using the NPM that you can add to the Mobile service. To develop on Windows Azure Mobile Service and use the NPM in your development you should create a new API found under the third button.

You also can schedule some work to be done from time to time using the Windows Azure Scheduler found in the fourth button, however this feature is still in preview, as the scaling one too.

The next one which is the Push, is the one related to the push notification. This is compatible with different platforms whether Microsoft Technologies (Windows 8 or Windows Phone) and non Microsoft Android and Apple. You can find a small introduction on Windows Azure push notification in a previous blog post and this one in the Mobile Portal is the new evolution of it. There is also the Windows Azure Service Bus Notification hub.

The next feature is the Identity, this one will allow you to integrate your application with different identity provider whether they are Microsoft or others. This feature will also require that you get some information about your application from your application that you developed on this platform most probably you will find them in the administration on the marketplace.

The last one I am going to explain now is the “configure” this one where has the main details about your database and server. The main thing that I want to show now is the CORS or the cross origin resource sharing, this is where you will be asked to enter the URL that will be allowed to deal with your application. PS if you develop cloud application and you want to test them on the local machine and this application is integrating with the mobile service you will have to enter the URL of your machine.

You can find the tutorials that can help you to get started here.

A very great integration I think you can offer you application while developing Windows Azure Mobile services using the NPM is also using the SignalR for better interaction between the client and the server and create better real time application

Here you can find all the details for the updates done on the mobile services and how you can start adding the NPM to your solution.

In the following link you can find the Windows Azure SDK for the Windows Azure development using Node JS.

There are several ways you can do to create the Windows Azure Virtual Machine. Certainly there is the easy way where you can create it from the Windows Azure portal, there are also several others way that might be helpful for you in some cases during the development. First one is the PowerShell where you can create and take control over the Virtual Machines created on Windows Azure (IaaS) with some PowerShell Commands, you can find all the technicalities and the how to in the following link.

There are also another way where you can take control over the Windows Azure Virtual Machines is through the .Net Application where you can create new Virtual Machines using some C# or VB code. Here is the operation that can be done in your .Net application to achieve this.

Here is an example I found online that can help more the explanation and how the things can be done.

Here are some operations that you can do on the Windows Azure Virtual Machine Images, others that can be done on the Virtual Machine Disks.

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”>


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



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.


<Setting name=”Microsoft.ServiceBus.ConnectionString”

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


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