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.

To introduce the MOOP Framework, I’m going to talk about a new implementation of the AzureArchitect Web Tools, this one using HTML, JavaScript and Handlers. The old version of the tools would allow you to enter your Account and SharedKey and then work with Blobs, Queues and Tables. This was handled by several different ASPX pages, one for each type of Azure Storage. Let’s take a look at the Blob Storage ASPX page as an example.

Once you’ve filled in your account and shared key, you could get a list of containers, for instance. Every time the button is pressed to get a list of containers, a call is made to the ASPX, which then uses the AzureCommands DLL to connect to the Storage, get the list of containers and the ASPX then processes the container list, populates the form and delivers it back to the client. Given the low traffic usage, this didn’t exactly tax the server in any way, but there’s a much better way to handle this, and that’s by applying MOOP programming principles.

The first thing we need to do is to separate out the components of the blob storage interface. There are three parts:

• The user interface
• The interaction with Azure Blob Storage
• The processing of results from Azure Blob Storage

The first step was to expose the functionality of the AzureCommands in a way that would make it easy for JavaScript to access. To do this, I created a Handler. Handlers seem scary but a Handler is really just a specialized bit of code with no UI that handles web based requests. You can find the Azure Blob Storage handler code here (I’ve actually added a project in AzureCommands to store the Blob, Table and Queue handler).  All the handler does is grab parameters out of the request, make the appropriate call to the AzureCommands interface and then format the return data. This means that we can now interact with the Azure Storage elements from a web page without having all of the code that went into the ASPX.

Now that we have that piece of the puzzle, we can use JavaScript to write both our UI and to process the results of the interaction. Which means that a majority of the processing have been removed from our web server and shifted it to the client. By cutting the amount of processing that our web server has to do from interfacing with Azure Storage and processing the results to just interfacing with Azure Storage and returning the results. The fact that our web server is doing less means it can serve more requests, which means we can handle more traffic before we need to implement an additional web server. The only other thing our server needs to do is to deliver up the static HTML/Javascript files. And, if caching is properly implemented (as I discussed here), we can cut down on the number of files we need to serve up.

Tomorrow, I’ll discuss how we can capitalize on Azure Blob Storage to implement this caching correctly and discussing Handlers in much more detail as we look at the first of the Azure MOOP Framework handlers.