Architecture for Azure application with Win8, iOS and web clients

Question

Hi all,

I'm pretty new to cloud development, but I'm planning to build a small service that can be consulted from a variety of platforms (Win8, iOS, ASP.NET web client). I'll use Azure for all the computation stuff; SQL Azure and queues for storage.

My question: what type of architecture should I foresee for the communication between cloud and clients? Taking into account that I should be able to add new clients later and that I obviously want the majority of logic on the cloud side.

I was thinking of using REST and JSON messages to communicate between the client and the cloud. Is this the good approach? Are there any tutorials to get me started?

Should I also use JSON messages to communicate with my ASP.net client? Since I will be hosting the ASP.net pages also on Azure, I could also directly access the storage and the cloud calculations. (Then again, I probably also can do this from within my Win8 or iOS client)

Answer 1

Hi Ron,

What you'll want is to create a public API that can be used by all your consumers (be it WIN8, WP7, iOS, Android, ...). This can easily be done with the new ASP.NET Web API: http://www.asp.net/web-api 

The ASP.NET Web API allows you to work content negotiation using accept headers. This will allow you to use a different content type based on the consumer. Simplified, this means that if you feel more at ease to use XML on iOS, you could just 'ask' the server to return XML. If you prefer JSON, you can ask for JSON.

I mentioned public API before, because this is what you want to expose to your consumers. On the other hand, you'll have something internally (a WCF service maybe, or just logic within your webapplication) to do much more, like managing users. 

And finally, I would (almost) never let the client applications talk directly to storage directly. This might increase complexity when you start changing things in your backend, since you'll also need to update the client applications. If you hide all the logic behind an API (a webservice), you can change the backend however you like without impacting the clients too much.

Hope this helps.

Sandrino

---

Sandrino Di Mattia | Twitter: http://twitter.com/sandrinodm | Azure Blog: http://fabriccontroller.net/blog | Blog: http://sandrinodimattia.net/blog

Answer 2

Hi Sandrino,

Thanks for this info! I will definitely have a look at the ASP.NET Web API.
If I understand it correctly, my central cloud app would consist solely of worker roles, web roles to support the Web API and maybe some Web APIs for administration stuff.
My web client will be a separated cloud project that communicates with the Web API of my cloud app, just like my iOS and Win8 apps.

Is this correct?

Answer 3

That is one option yes. But to lower the cost you could combine multiple web applications on the same role. 
You could then have the following setup containing 2 roles:

• 1 Web Role containing:
  myapp.cloudapp.net/api => Public API (exposes limited functionalities), uses the WCF service in the worker role.
  myapp.cloudapp.net/ => Public website (your web client) that uses myapp.cloudapp.net/api
  myapp.cloudapp.net/admin => Admin website, uses the WCF service in the worker role.
   
• 1 Worker Role containing:
  WCF service with the backend processing, exposes all functionalities.
  Timer/Service Bus Subscriptions/queue processing/... to handle processing like sending mails, ....

Sandrino

---

Sandrino Di Mattia | Twitter: http://twitter.com/sandrinodm | Azure Blog: http://fabriccontroller.net/blog | Blog: http://sandrinodimattia.net/blog

Answer 4

Ok, I understand. You really need to take the cost aspect into consideration with Azure. Even though things are sometimes much cleaner when they are separated, at first you should combine as much as possible into 1 role to keep costs low.

1 further question though. My clients will ask on-demand calculations from the server. Where will this on-demand logic sit? Should I put it in a worker role that is constantly waiting for calculation requests from a client (through the web API)?

Answer 5

Hi Ron,

The WCF service isn't mandatory. If the cost aspect is important, you could just implement the business layer in your web application (if this fits in your architecture). You could have a class called UserComponent containing the business logic. Then the UserController (the public API) would talk to a limited set of methods on the UserComponent (like ResetPassword etc...). Besides that, you can also have a UserManagementController talking to the same UserComponent class (allowing you to group all logic regarding users in the UserComponent class). All this could run in the web application, possible taking away the need for a worker role.

The on-demand logic would then also live in a "Component" class (ie: run in the web application).

But a service layer (using WCF) in front of this, be it on the web role or on a different worker role, would also work. It just depends the type of on-demand logic, the budget, the architecture, ...

Sandrino

---

Sandrino Di Mattia | Twitter: http://twitter.com/sandrinodm | Azure Blog: http://fabriccontroller.net/blog | Blog: http://sandrinodimattia.net/blog

Answer 6

What if you need to separate the "web site" from the "api"?  Would the following configuration work and how would I handle SSL (Port 443) if I need it on both web roles?

• 1 Web Role containing: mywebsite.cloudapp.net mapped to port 80
• 1 Web Role containing: myapi.cloudapp.net mapped to port 8080
• 1 Worker Role for background processing

Let me know your thoughts, trying to work through this to support a similar scenario as Ron.

Thank you,

Frank