Community, Events, RIA Services, Silverlight, Windows Azure

DigiGirlz, Deep Zoom and Azure

A few weeks ago I was tasked with coming up with something for the attendees at the first ever DigiGirlz event in Australia to play with. Something to get them a little excited about technology. Catherine Eibner came to me with some ideas that she thought would make for a compelling exercise and we came up with a cool Azure based Deep Zoom app!

We decided to take the Eventr (Codeplex | Blog | Blog) open source project I worked on last year for ReMIX Australia 09 and make it more accessible and dynamic (and brand it a little for the event).

What came out the other side was a dynamic Azure based DeepZoom creation application with auto updating Silverlight front end!

What does it do?

Firstly, check out the running application here!.

The Silverlight application shows a DeepZoom composition of all the photos that were taken at the DigiGirlz event.

The photos were all added to a Flickr Group which the Eventr application automatically scans. When new photos are added, the photos are downloaded in to Azure and processed in to a new DeepZoom composition.

The Silverlight client is notified that new images are available – it then highlights the new images and automatically reloads the DeepZoom composition from the server.

The system is configurable to scan a Flickr Group, perform a Flickr full text search or perform a Flickr tag search (or a combination of these).

The system has been designed to be “multi-tenanted” which means it can host more than one group of images… I.e. it could do DigiGirlz and another collection – all the images would be separated depending on the URL entered.

How does it work?

The application is hosted in Windows Azure and utilises a lot of what Azure has to offer.

  • It uses a WebRole to host the Silverlight application and services (which read from the DataBase).
  • All data is stored in a SQL Azure database. The data stored includes information about which images have been downloaded from Flickr, their metadata (title, description etc.) and their processed state (have they been included in the DeepZoom composition yet?).
  • Linq to SQL is used to access the SQL Azure database. You can access SQL Azure in the exact same way that you would access a normal SQL database. In fact when in development mode (local) I used SQL Express, and during deployment I changed my config to point to a SQL Azure instance… too easy.
  • WCF RIA Services was used to communicate from Silverlight to the server (where Linq to SQL is used to then go up to SQL Azure). The Silverlight client is very easily then able to get the metadata (title, description) from the database, as well as send data back (like view counts etc). All in all, it was a very simple task to get data from SQL Azure into Silverlight.
  • Azure Blob Storage is used to store the generated DeepZoom files. Blob storage is great because you can access the files directly using a URL, as well as get programmatic access to them to CRUD(create read update and delete) them.
  • To fire commands based on events from the user, the system uses Azure Queue Storage. Queues allow you to add an item in one place, and read it in another (only one thing can read an item)… so it’s great to fire a command once, and pick it up once to execute it. An example command in this system is “Clear”. Admins can clear out all the images/collections and data and start again.
  • To build the Deep Zoom collection, the system utilises an Azure Worker Role. The worker role polls the database every few seconds to get out the Flickr search configuration (i.e. which group or text search to scan). It then performs this search against Flickr. New images are downloaded and added to the SQL Azure database for later processing.
  • When the Azure Worker Role downloads an image, it is stored in a Windows Azure Drive. Once stored, it is processed using DeepZoomTools (a part of Deep Zoom Composer.

    Windows Azure Drive is important as DeepZoomComposer doesn’t work with streams (which is how Azure Blobs work)… it needs a drive letter. Azure Drive is great as it provides drive letter access to a special type of blob storage – meaning it will work in Azure!

    Once the composition has been built it is uploaded to Azure Blob storage for access from Silverlight (you cannot access Azure Drive files from outside the Windows Azure hosting platform – they are a special type of storage).

  • Can I test it out??

    Unfortunately at this stage I cannot release the code for this stuff, but – you can have a go at using this project yourself…

    Head over to the test Flickr group here. Add a photo the the group (KEEP IT CLEAN PLEASE!!).

    Then head over to the test URL and keep watching… your new images will show up in no time (under 2 mins)!

    Resources

    Azure Team Blog: http://blogs.msdn.com/windowsazure/
    Azure Storage Intro: http://msdn.microsoft.com/en-us/azure/cc994380.aspx
    SQL Azure Overview: http://www.microsoft.com/windowsazure/sqlazure/
    Windows Azure Overview: http://www.microsoft.com/windowsazure/windowsazure/
    WCF RIA Services Overview: http://www.silverlight.net/getstarted/riaservices/
    Get Started with Silverlight: http://www.silverlight.net/getstarted/
    Eventr DigiGirlz Demo: http://jak.cloudapp.net/Default.aspx?guid=764fbcd0-c15f-45f3-bda5-de3ed9081ce8

    Eventr Codeplex project: http://eventr.clodeplex.com

RIA Services, Silverlight

Upgrading from .NET RIA Services to WCF RIA Services

I just had to go through the process of upgrading an app built with the RIA Services CTP code from a few months ago to the new WCF Ria Services beta that was released at PDC.

After the upgrade I was presented with a billion errors – I had one of those “OMG I wish I didn’t just do that” moments… but after some hunting around I found that the changes were not too bad.

Here is my report on what I did to get my project working.

In web project

I had a custom object being exposed via RIA Services, which meant I had to have a [Key] attribute on one of the properties. System.ComponentModel.DataAnnotations has been upgraded, but the reference in your project will have required specific version set. So remove the missing DLL and re-add it. Use the 3.6.0.0 version.

System.Web.DomainServices.Providers has been split in to two files – System.Web.DomainServices.LinqToSql and System.Web.DomainServices.EntityFramework. I’m using LinqToSqlClasses in my project, so I added the Linq version (and removed the old reference).

You’ll also have to update the name spaces in your DomainServices – Change “using System.Web.DomainServices.Linq;” to “using System.Web.DomainServices.Providers;”.

ServiceOperation has changed to Invoke.
Please note that it seems that in the VS2010 version of WCF Ria Services you can return entities from Invoke operations but not in the VS2008 version. Keep this in mind when you are designing your domain services – although you probably should use normal non Invoke style methods to return entities.

Also in your domain services on the server, “this.Context” has been changed to “this.DataContext”.

I had an enum that was exposed by a ServiceOperation (now Invoke) and it wasn’t being properly pushed out the client code. This appears to have been fixed, so I removed the .shared part of the file name to fix (it was doubling up on the client and getting a compiler error).

Silverlight Client

SubmitOperation is now in System.Windows.Ria namespace, not System.Windows.Ria.Data

If you are using RiaContext to get login information etc, then you’ll have to change RiaContextBase to WebContextBase.

IEditableCollection is gone… I use PagedCollectionViews mostly anyway (which use IEditableCollectionView) – IEditableCollection was in the SL3 Beta (but removed for RTW), and seemed to be included *again* in the older RIA Services stuff – but it’s gone again 🙂

ServiceContract() (which is in the auto generated files on the client) is now in System.ServiceModel.dll (so add it as a reference).

MergeOption has been changed to LoadBehavior with new options – KeepCurrent, MergeIntoCurrent and RefreshCurrent (much nicer!)

That’s all I had to do to get the app compiling, but at runtime I had a few problems with the RIA services requests getting 404. I fixed this by adding a temp domain service to the app – which updated the Web.Config for me…

It Added the following httpModule:

<add name="DomainServiceModule" type="System.Web.Ria.Services.DomainServiceHttpModule, System.Web.Ria, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />

It Added the following module:

<add name="DomainServiceModule" preCondition="managedHandler"
    type="System.Web.Ria.Services.DomainServiceHttpModule, System.Web.Ria, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />

It also added some WCF stuff right down the bottom of the file:

<system.serviceModel>
  <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
 </system.serviceModel>

Hope this helps you upgrade your projects!