MOOP stands for Matter Out Of Place, and the MOOP Programming principles can really be summed up as stating that every part of program has a place where it should be running and having everything running in its place provides a built in efficiency that we can harness, an efficiency that’s especially important in cloud computing where we pay for our computer usage.

Yesterday, as I was introducing the MOOP framework, I introduced the concept of Handlers and showed their benefits. Today, we’re going to talk about the first handler that is part of the MOOP Framework, AzureBlobHandler. As the name implies, this handler processes blobs but in doing so, it removes the need for local files from our web role and helps us define caching in a way that drastically reduces our cloud computing costs. 

One of the main principles of MOOP Programming Principles is determining where programming should be located and making sure that it is carried out there. Yesterday I explained how this included removing as much of the UI processing as possible from the web server and offloading it onto the client. This means utilizing DHTML as much as possible, which also means that most of what our web server is going to be delivering is static content. The plus side of this is that delivering static files is the simplest task that a web server can do.  The downside of delivering static files from the web site is updating them. The easiest choice for delivering static files from an Azure Web Role is to include the files in your web role. The problem of this is that changing these files require a redeployment of the files.

With the MOOP Framework, however, we have an easier way to do it: use Azure Blob Storage. All of the HTML, JavaScript and Images on  http://azurearchitect.cloudapp.net/ are being delivered from our Azure Blob Storage. This takes advantage of the fact that there are no bandwidth charges between web roles and Azure Blob Storage, which means it doesn’t cost us anything to have the web role getting information from Blob Storage. In addition, we can then set caching in such a way that static files can be cached publicly, further cutting down on how much bandwidth we incur.

The basic flow of this handler is really very simple. To begin with, it gets the Azure Account information out of the Configuration, meaning changes can be made to the storage with minimal disruptions to the  web role. Then it checks to see if the file being requested exists locally. If it does, then we’re going to deliver up the file locally, but we need to take care of some housekeeping to implement caching and cut down on future requests if the client already has a copy of the file. To do this, we need to generate an ETag. A good ETag will be unique not just to the file but to this version of the file. To this end, we create an ETag using the MD5 hash of the file’s last write time and the MD5 hash of the physical file location. Given that these two values should be the same for all instances, we should be good.

With the ETag generated, now we check to see if the browser has included an ETag in the headers collection. If it has, and if the ETag matches, then we can set the HTTPResponse.StatusCode to NotModified, which tells the client that it can use the cached copy. If the ETags don’t match (or if there is no ETag in the headers collection) then we set an Expiration time of one hour and state that the file can be publicly cached, get the MimeType of the file and send it off to the client.

If, on the other hand, the file doesn’t exist locally, we assume that the file is going to be one we can get out of Blob Storage.  We use the path of the URI to determine the location of the object in storage, so http://azurearchitect.cloudapp.net/scripts/imgs/color.png would be the blob imgs/color.png in the scripts container. If the request contains an ETag and that ETag matches the version in Blob Storage, we set the HTTPResponse.StatusCode to NotModified and we’re done. If the ETag doesn’t match or there is no ETag, we get the item out of Blob Storage, set the ETag, set the Cache Expiration and set caching to Public and send the item off. If the item doesn’t exist, we pass the 404 back that Azure Blob Storage returns to us.

If you’re interested in getting our MOOP Framework, please contact us and we’ll be happy to discuss how we can help you.

Tomorrow we’ll post about how to use a Handler to interface with your data and some of the fun experiences that IE brings to AJAX Queries.