The enhanced (intelligent) Windows Azure Project template @ AzureContrib.codeplex.com is now updated to run on Windows Azure Tools for Microsoft Visual Studio (November 2009).
There is a new piece of code for managing logging (tracing) with the new Microsoft.WindowsAzure.Diagnostics functionality. The Microsoft.WindowsAzure.ServiceRuntime has been updated to reflect the recent changes to the Azure runtime including support for the new Windows Azure Role Lifecycle.
The new Microsoft.WindowsAzure.StorageClient release is pending but that takes a bit of more work. The goal @ AzureContrib where Cloud Storage is concerned is to enable so called Persistence Ignorance (PI). The PI thing is about being blissfully ignorant of exactly where my data is stored and how it is stored. Instead of depending on a specific storage technology those who adhere to PI instead depend on an abstraction of storage that gives us the abstract functions we require; such as save, load, select etc. This part of AzureContrib will be reviewed later (soonish).
The enabling extensibility technique
We use Managed Extensibility Framework MEF to enable extensibility and inversion of control features in AzureContrib.
Azure Service Runtime news
There are some news to the Windows Azure RunTime. Just briefly:
Lifecycle
There is now a lifecycle for an instance of an Azure Role (both web role and worker role) that has three steps: OnStart, Run and OnStop. Only in Run state will the role receive incoming traffic from the Fabric Controller.
Three types of work
This means we have redone the way our “work” is used. We had the notion of “IWork” that would run in normal operation and also an “IOneTimeWork” that ran during startup – once.
Now instead we have that which is called an “IWorkITem” that has a “WorkItemType” that can be OnStart, Run or OnStop.
Introducing Azure Diagnostics
Debugging the cloud is a BIG task for any Azure application. This is done through tracing which works really nice. Trace is stored in a Windows Azure Storage Account off the actual role instance that did the tracing. Pretty nice if you ask me!
The problem with statics
However if tracing is this important I feel, as a responsible developer, that the only reasonable thing would be to be able to use tests to validate that specific trace messages actually are written. The problem then becomes that System.Diagnostics.Trace is a static class.
How do you easily write tests for accessing static methods?
The answer is: It is not easy to do.
Enter the ITrace abstraction:
ITrace – the abstraction of static Trace
We have abstracted out the Trace class and it’s static methods from our code in AzureContrib. This is done by creating an ITrace contract. This contract is in turn implemented by a wrapper class that wraps around the calls to the static Trace class.
Using this abstraction of Trace we can now write tests that actually verify the existence of specific trace messages after certain conditions in code have happened. This way we can trace errors, warnings what have you and attain the ability to write tests that can verify our trace messages.
Windows Azure After Work event in Stockholm on December 2nd
Finally I’d like to mention that if you are in Sweden near Stockholm on the 2nd of December Microsoft and the Microsoft Extended Experts Team, where I am a member, is arranging and hosting a Windows Azure After Work event. Dotway (through my colleague Peter von Lochow and me) are co-hosting and will be demoing and leading discussions on Azure technology and opportunities. Anyone can meet up in central Stockholm after work where we will discuss Windows Azure to our hearts content:
http://www.facebook.com/event.php?eid=177384451401&ref=mf
Hope to see you there!
And we, Peter and me, hope that this new drop of AzureContrib will be useful as inspiration to someone out there aiming their development efforts to the clouds.
Cheers,
M.
posted @ Sunday, November 29, 2009 11:49 AM