Azure Skittles Part 3
Last time, we got our service up and running. This time we will jump in and write some code.
Web Role
The job of our WCF Service is to grab requests from clients and put them on an Azure Queue. Start by modifying our contract (IService1.cs by default). I made mine pretty simple. For a non-skittles project, it’s best to use a DTO pattern with Request-Response DTOs (https://bit.ly/10jDze).
For the implementation, we will do a couple things. We will grab a reference to our queue, write a message to it and log a debug statement. Here’s that implementation.
In order to get an instance of a CloudQueue class (https://bit.ly/btc4r0), we must use the CloudStorageAccountStorageClientExtensions.CreateCloudQueueClient
method . (Let’s see you say that 10 times fast! https://bit.ly/b26TCj). CreateCloudQueueClient (https://bit.ly/bseZ1U) requires a CloudStorageAccount. We will use the conveniently provided DevelopmentStorageAccount. According to MSDN (https://bit.ly/ao7fd2) …
Authenticating Requests for Development Storage
Development storage supports only a single fixed account and a well-known authentication key. This account and key are the only credentials permitted for use with development storage. They are:
Account name: devstoreaccount1
Account key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
Important The authentication key supported by development storage is intended only for testing the functionality of your client authentication code. It does not serve any security purpose. You cannot use your production storage account and key with development storage. You should not use the development storage account with production data.
From there, we will get a reference to our CloudQueue. I call mine “testqueue”. I had some trouble with Queue names that contained capital letters (I started with “testQueue”), but got malformed request errors.
Of course, this will not run, because the Queue is not yet created. We will do that on the Worker Role side.
Worker Role
We will add a simple implementation for our WorkerRole.
First thing to note: logging now uses System.Diagnostics for writing log entries through the Azure Diagnostics API (https://bit.ly/bJ9B25). By calling Trace.WriteLine, we will get a line output into the Development Fabric. This is accomplished in the Default OnStart method by calling DiagnosticMonitor.Start("DiagnosticsConnectionString") (https://bit.ly/aqjVc1).
We follow the same procedure to get an Account and a Queue as we did in our Web Role, but in this case, we call CreateIfNotExist on our CloudQueue to build the queue if we don’t have one yet. I call Clear() here because this is a toy example. You would probably not do that in a real situation. The reason I do that here is because I want to clear out everything from my previous debugging runs. I’ve kept the Queue access synchronous here to not cloud up (hehe) the code.
So let’s run this. If all is well, we should see our Worker Role starving.
Next time, we will feed him.