How we built TwitterMatic.net - Part 1: Introduction

“Once upon a time, Microsoft started a Windows Azure developing contest named new CloudApp();. While it first was only available for US candidates, the contest was opened for international submissions too. Knight Maarten The Brave Coffeedrinker and his fellow knightsmen at RealDolmen decided to submit a small sample application that could be hosted in an unknown environment, known by the digital villagers as “the cloud”. The application was called TwitterMatic, named after the great god of social networking, Twitter. It would allow digital villagers to tell the latest stories, even when they were asleep or busy working.”

There, a nice fairy tale :-) It should describe the subject of a blog post series that I am starting around the techncal background of TwitterMatic, our contest entry for the new CloudApp(); contest. Now don't forget to vote for us between 10 July and 20 July!

Some usage scenario’s for TwitterMatic:

• Inform your followers about interesting links at certain times of day
• Stay present on Twitter during your vacation
• Maintain presence in your activity stream, even when you are not available
• Never forget a fellow Twitterer's birthday: schedule it!
• Trick your boss: of course you are Tweeting you're leaving the office at 8 PM!

Perfect excuses to build our application for the clouds. Now for something more interesting: the technical side!

If you are impatient and immediately want the source code for TwitterMatic, check http://twittermatic.codeplex.com.

TwitterMatic architectural overview

Since we’re building a demo application, we thought: why not make use of as much features as possible which Windows Azure has to offer? We’re talking web role, worker role, table storage and queue storage here!

• The web role will be an application built in ASP.NET MVC, allowing you to schedule new Tweets and view archived scheduled Tweets.
• The worker role will monitor the table storage for scheduled Tweets. If it’s time to send them, the Tweet will be added to a queue. This queue is then processed by another thread in the worker role, which will publish the Tweet to Twitter.
• We’ll be using OAuth, delegating authentication for TwitterMatic to Twitter itself. This makes it easier for us: no need to store credentials, no need to maintain a user database, …
• The web role will perform validation of the domain using data annotations. More on this in one of the next parts.

For people who like images, here’s an architecture image:

What’s next?

The next parts of this series around Windows Azure will be focused on the following topics:

• Part 1: Introduction
• Part 2: Creating an Azure project
• Part 3: Store data in the cloud
• Part 4: Authentication and membership
• Part 5: The front end
• Part 6: The back-end
• Part 7: Deploying to the cloud

Stay tuned during the coming weeks! And don’t forget to start scheduling Tweets using TwitterMatic.

This is an imported post. It was imported from my old blog using an automated tool and may contain formatting errors and/or broken images.