I have divided this article into three parts and that will make you understand some of the gotcha with Windows Azure.

1.       Windows Azure and Live Mesh

2.       Windows Azure and .NET Services

3.       Windows Azure and WCF Services

Windows Azure and Live Mesh

If you are planning to have Live Mesh integrated with you Windows Azure applications in that case you just can’t use the Live Mesh assemblies like

·         Microsoft.LiveFX.Client

·         Microsoft.LiveFX.ResourceModel

etc..etc..

As these assemblies cannot be used from your Windows Azure code guess why? The reason being these assemblies are still not APTCA signed. And you will get a security Exception if you do this.

So if you want to do functionalities from your Windows Azure Application like Connecting to Live Mesh, Creating folders, files, deleting files and folders you just can’t use these assemblies directly.

The beauty of Live Mesh is that it supports pure REST based calls; in that case you can use all the functionality of Live Mesh from Windows Azure using “System.Net.Http.HttpWebRequest” only.

For this I highly recommend Fiddler2. http://www.fiddlertool.com/fiddler/ which will definitely help do create you HttpRequest objects.

Windows Azure and .NET Services

If you are planning to integrate .NET Services from your Windows Azure code, you will face the same problem as you faced when you tried using the Live Mesh assemblies, i.e. you just can’t use assemblies like

·         Microsoft.ServiceBus

·         Microsoft.Workflow.Activities

etc..etc..

The reason being same these assemblies are still not APTCA signed.

What if you want to call Service Bus Services from Windows Azure code?

The only option is, when you host you Service Bus services use bindings like “Microsoft.ServiceBus.WebHttpRelayBinding”

Now in this case if you want to call this service from your Windows Azure code you do not need to have  “Microsoft.ServiceBus” assembly referenced. You can call this service using plan…vanilla…our old and simple “System.Net.Http.HttpWebRequest”

What if you want to call Workflow Service from Windows Azure code?

If you want to use Workflow service from an Application you have to do a sequence of steps like

1.       Create an instance of Workflow

2.       Start the workflow instance

3.       Now you can call this instance

The first two steps of above are not possible directly when you try to do this from your windows Azure code because in that case you need to have “Microsoft.Workflow.Activities” assembly referenced, and you can’t use this assembly from your Windows Azure code.

The last step of the above i.e. Call a cloud workflow instance. You can do this using “System.Net.Http.HttpWebRequest” from your windows Azure code.

Windows Azure and WCF Services

If you want to call and host WCF services in your Windows Azure application you can only use the Partial Trust profile of WCF.

At last if you are planning to develop you Windows Azure application you should know some of the above gotcha, as this will help you to know what is and what’s not possible from Windows Azure Applications.

Lately I was working on Microsoft Cloud Workflow services, and with some good new things you always get some limitations too…

At present the Cloud workflow comes with some basic activities and using then we can create some workflows, call Service Bus, make Http Requests., control access to them, and define some rules and some more…..

And yes you will get good scaling, management without investing into hardware, you also get a portal for management of workflow instances and if you don’t want to go to portal always you can always use the workflow API to manage them.

But some features I didn’t like…

·         Unlike a typical workflow whose instance is created when ever a request comes, in .NET workflow service we have to do some sequence of steps before making a call…surprised, YES?

o    Create an instance of workflow either through portal or using API

o    Explicitly start it.. and now off course you can call it. But here is one more trick. When you create an instance you get an instance Id, and the url to which you have to send a request depends on several things and one of them is the instance id.

o    So for you the Request url is always dynamic as it depends on workflow instance id which is a GUID.

o    The Request URL looks like this

http://workflow.windows.net/workflowsHttp/<UserName>/workflows/<WorkflowTypeName>/instances/<InstanceId>/<ActivityName>

·         The activities which are presently there are fairly limited.

·         And if you are using CloudXPathRead and CloudXPathUpdate activities in your workflow make sure that the request you pass them should have correct type i.e “"text/xml"” otherwise the data will be Binary in WF and your WF will crash.

·         One more feature which I would love to see is to have a local deployment server, so that we can debug these, unlike at present we have to always deploy them in the cloud and we cannot debug themL.

·         And the last thing which is really important if you are planning to call cloud workflow from your Azure applications. You cannot create workflow instance and start them as the assembly which has these API cannot be called from Partial trust, and your Azure applications always run under that .. a big hindrance which Microsoft should really look into.

SSDS is a new offering from Microsoft and which shows its promise on investing in S+S and SaS. It is an Online,  On Demand, highly scalable and query processing Web Service. See here

It consists of Authorities, Containers and Entities, where in Containers are not defined by schemas (Tables are defined as schemas) but as a name value pairs.

It also provides a very good query processing capabilities. You can get integrated with it using the provided SOAP or REST interfaces..The interfaces are quite simple and good. However, there are still some good things missing and one of the things is a UI for SSDS.

Using the SOAP interfaces, it did not took me too much of time to create a UI for SSDS for query processing. This Tool supports.

·         Connect to the SSDS

·         Add Entities

·         Delete Entities

·         Update Entities