Cloud computing contest with Windows Azure – The architecture and technology of our Austrian contest application

As many of you might know, in Austria we are currently running a Windows Azure Contest where it’s possible to win a Samsung flatscreen TV together with an XBox 360 as well as 10 external 500GB hard disks for all participants successfully completing the contest.

In this blog-posting I will describe the technical architecture and provide the source-code as a download so that you can take a look at the details of this nice “in-production”-application on Windows Azure!

Contest home: https://atazurecontest.cloudapp.net
Official announcement: official announcement here
Azure Contest App Source Code: Azure Contest App
Working Participant Sample App Source Code: Participant Test App

How does the contest work?

To participate in the drawing for the flat-screen and the Xbox 360, you basically need to register at our contest home page (if you’re in Austria, only, see qualification requirements), then write and deploy a simple web service on Windows Azure and finally let our Azure-application try to call your web service. Graphically that looks as follows (click for details):

Scenario%20-%20Overview[1]

Architecture of the Microsoft Windows Azure Contest App

The contest-front-end you see when navigating to https://atazurecontest.cloudapp.net is just a little part in the overall game. Although the code has rather the state of a sample, the architecture of the system is asynchronous by its nature to scale out a bit better. Therefore the front-end is really just accepting and storing registrations and displaying some simple web pages – not more not less. Sending emails and testing participant applications happens asynchronously in a worker as shown in the illustration below.

Architecture%20-%20Overview[1]

As you can see above, the web role accepts the requests through simple ASP.NET pages from the user. These are the following:

  • Users can register for participation.
    With that the application generates a registration token (a GUID) and stores the registration data in a Windows Azure table storage so that we can query the data, easily. Behind the scenes the following actions happen:
    -) a registration-token is generated
    -) the registration data is stored in table storage
    -) a message is added to the queue with the token and a command for the worker
    -) the worker takes the token, reads registration data and uses it to send an email.
  • Users can test their registration.
    Every test requires the user to enter the registration token – not more and not less. With this information the following actions happen behind the scenes:
    -) the web role tries to read the registration data
    -) if valid, it adds a message with the token and the validation-command to the queue
    -) the worker picks this message up and reads registration data based on the token
    -) it tries to call the service according to the token and the registration data
    -) it updates the registration data after the call succeeded or failed appropriately

In the web role, all the actions are delivered through an AJAX-web service. So you won’t find any code in the pages except JavaScript-calls to this AJAX-web service. If you are interested in how messages are added to the queue or data is added to the table storage, the AJAX-web service contains this code as well as the code for the worker role does.

Also note the solution I’ve implemented for the content pages. I knew that our marketing department definitely will want to change some parts of the textual and graphical content of the application. These are independent of the actual application logic and application pages and therefore I’ve separated them out as stand-alone HTML pages. All these pages are stored in blob storage and whenever our marketing requires an update, I just update those simple HTML pages and upload them in blog-storage again instead of re-deploying the whole application. This is a pretty neat approach for this situation to be able to make simple textual and graphical changes quickly without the need of re-deploying the whole application (mini-mini-mini-mini CMS functionality;)).

I think the application is a pretty nice sample for leveraging the different parts of Windows Azure. Feel free downloading the source code for the contest application as well as a example of the participant-test-application and setup your own environment if you want to try something more interesting than just a hello world application:)

Download the Microsoft Austria Azure Contest Application Source Code here

Download a working and ready-to-deploy sample participant application web service here

For me it was definitely great fun building this content application, I hope it’s funny for you implementing and deploying the participant application web service, as well! Feel free sharing any feedback with me!