Azure vs WCF vs ASP.NET vs ... How does it fit together?

Question

a newbie question. I've done plenty Java dev (e.g. GAE) and mobile dev such as iOS and Android. I am investigating Windows Azure as the platform for our server-side services that our mobile devices interact with. I have to admit I have a hard time getting my head around it. Part of it is acronym-overload. Are there any good pointers how the various acronyms glue together?

I've worked through some of the tutorials but they mostly focus on doing a web site in Azure. In our case, there really aren't any web pages but rather services (some REST, some otherwise) that the devices call into. To come perhaps to a specific question: how does a worker role, or a web role, retrieve the content of an http-post sent to the endpoint I created for it?

Answer 1

The answer to this should be fairly easy. Azure, towards you, is a hosting provider. It helps you scale your application servers based on demand (e.g. number of mobile clients downloading & installing your application).

A little marketing speak: Azure lowers your cost of ownership for your own solutions because it takes away the initial investment in firstly figuring out (guessing) the amount of hardware you need and then building/renting a data center and/or hardware. It also provides some form of middleware for your applications, like AppFabric, so that they can communicate in the "cloud" a bit better. You also get load balancing on Azure, distributed hosting (e.g. Europe datacenters, USA datacenters...), fail safe mechanism already in place (automatic instance instantiation if one were to fail) and obviously, pay as you go & what you use benefits.

Going from there on, ASP.NET is an application framework, specifically, a web application framework. It helps you write web based applications using eight WebForms or MVC. For what you stated, this shouldn't really be of much use to you (for running a back-end system only). But if you need a web application on top of that, yes, ASP.NET works perfectly with Azure (obviously).

Finally, WCF or the Windows Communication Foundation, is another framework, this time for writing and consuming services. These are either web services, or other, e.g. TCP based services, even MSMQ based services. This is, in my opinion, what you should be looking at for exposing your back-end. WCF provides you the ability to easily specify a contract and implementation, while leaving the hosting of the service and the instantiation to IIS (IIS being Microsoft's web server, which is also running under the covers on Azure).

Now, to try and answer your question: I would go about having a web role, hosting a WCF service, exposed at a public endpoint. Your mobile application will from there on call this public endpoint (defined by an address and port, obviously) and use standards-based web services to communicate with your services.

Does this make sense?

Shameless plus: I've written about these buzzwords and whatnots on my blog, which you are welcome to check out.

Answer 2

I think most of what you're seeing is the .NET way of doing things. (ASP.NET and WCF are .NET technologies.) Windows Azure is a platform that can run all sorts of things (though mostly people use it for .NET). In a Windows Azure web role, your code just runs under IIS (a web server), and you can run ASP.NET, WCF, PHP, etc. within that.

I think the most common way people build REST APIs in Windows Azure is to use either ASP.NET MVC 3 or WCF to build a REST service and then host that in a web role. How you get at the data posted to your endpoint depends on which technology you use. Under ASP.NET MVC 3, you might write something like:

[HttpPost]
public ActionResult CreateMessage(string title, string body)
{
    // use title and body here... they'll be the parameters in the HTTP post
    return Content("Message created!");
}