Messaging on Windows RT

As probably known the cloud messaging platform in Windows Azure is based on Service Bus technology. Few months ago Microsoft has published the Windows Azure Toolkit for Windows 8 which provided the same API for Windows RT.
Unfortunately this library has been deprecated. The new WinRT library for Service Bus is now part of Windows Azure Mobile Services and can be downloaded here.
Note that the new so called messaging managed library is simplification around existing Service Bus SDK. Do not be surprised if you cannot find yourself in the new library. The good thing is hat If you are novice in this are you will feel relaxed. :)

API style is changed

In common version of Service Bus SDK (currently 2.1) you can do something like this:

var appuserCli = QueueClient.CreateFromConnectionString(“…”, “myQueue”, ReceiveMode.ReceiveAndDelete);

appuserCli.Send(new BrokeredMessage("abc"));

var m = appuserCli.Receive();

However the WinRT version is very different. For example WinRT version does not know anything about BrokeredMessage. There is now the new message simply called Message. The WCF guys and most old school guys will be probably disappointed with this, because Message is well known type from System.ServiceModel. But who cares? Most hobbyists who develop apps do not known what service model is (This is something behind WCF).

Another interesting thing that API style is shifting from commonly well known used style in .NET framework. For Example QueueClient is the class which provides operations to deal with Messaging Entities like Queue or Topic.
It looks like:

QueueClient.DoSomethingOn(Queue);
QueueClient.DoSomethingElseWith(BrokeredMessage);

The new API on WinRT looks different:

There is no QueueClient and similar things!!!
Message entities are no more entities. They are now active objects, similarly like in C++ era in he late 90-ties. Here is an example:

Queue.DoSomethingWith(Message);

To me, the number of types is reduces (it is simpler), but the API design is not the best one or not the common one at least in the .NET framework.

Queue queue = new Queue(m_QueueName, m_ConnStr);          

await queue.SendAsync(new Message("bla"));

await queue.ReceiveAsync();

 

Serialization Defaults are different

The most interesting thing is that by default these two libraries are even not compatible with each other. Of course they are, bit take a look on following example and you will understand what I mean with incompatible.
In following example Desktop application sends the message which will be consumed by WinRT app. In this case WinRT app will fail with serialization error.

Desktop:

var appuserCli = QueueClient.CreateFromConnectionString(“…”, “myQueue”, ReceiveMode.ReceiveAndDelete);
appuserCli.Send(new BrokeredMessage("abc"));

WinRT

Queue queue = new Queue(m_QueueName, m_ConnStr);          
var msg = await queue.ReceiveAsync();

Ok, then let’s try following:

WinRT

Queue queue = new Queue(m_QueueName, m_ConnStr);          

await queue.SendAsync(new Message("bla"));

Desktop

var appuserCli = QueueClient.CreateFromConnectionString(“…”, “myQueue”, ReceiveMode.ReceiveAndDelete);

var m = appuserCli.Receive();

Now, Desktop application will fail with serialization error. So what is the point?
The Desktop SDK uses under the hub DataContractserializer to deal with messages. WinRT bits however use DataContractJsonSerializer. The result of this is messages send from different Windows Platform are differently formatted and not compatible.
To fix this, you new to provide the expected serializer.

If you are polite you should do it in the desktop application as follows:

var appuserCli = QueueClient.CreateFromConnectionString(“…”, “myQueue”, ReceiveMode.ReceiveAndDelete);

var msg = appuserCli.Receive();

var txt = msg.GetBody<string>(new DataContractJsonSerializer(typeof(string)));

In one of next posts I will describe how to deal with different serializes on desktop and mobile platform.