I've started the development of this library. It's been an interesting experience using the existing Amazon EC2 C# library as a base for this library. All I've got to say about that library is it really is coded weird; I'm not going to say its coded badly, lets just leave it at weird. Lets just say it really appears to be coded by a non .net person.
If you remember from an earlier post, I have a few requirements for this library:
- It should compile and run under both WPF and Silverlight with the same code base
- It should make asynchronous calls the norm (since that is the model for Silverlight)
- It should use the WebClient class, the norm for Silverlight
Yes, I'm kind of coding to the least common denominator of Silverlight (as versus to WPF), but it is a better model in my mind anyway.
One of the first issues I had was in determining how to issue REST requests for EC2 using the WebClient class. Believe it or not, I really did not find a lot of info on this while googling around. In the end, it turned out to be pretty easy. The code to do this is exemplified in this picture:
In short, this method takes a dictionary of key value pairs which are mapped to REST parameters. Each caller of this method (like the AttachVolume method) will set its parameters (at a minimum the Action key). It then adds in the required parameters in the call (access keys, signatures, ...), most of which are passed in on the constructor of this object and others calculated on the fly.
The WebClient object is then created, and the proxy added if in use, and then two headers that are required. A callback is setup for handling the async response, and then the data is passed up with a POST method using the UploadDataAsync method. I happen to pass a custom object as the UserData that encapsulates a callback passed from the calling method, and that can be seen in the explanations to come as well as by examining the async handler.
That's pretty much it to send the REST command to EC2. Now lets see how to construct a command that uses this technique.
I've been building this out with an immediate need which requires me to be able to attach and detach volumes from an EC2 instance, so I have focused on the Attach-Volume, Detach-Volume, as well as the Describe-Volumes commands (the last is needed to track the attach/detach status). As an example, lets look at the code to detach a volume:
The method first sets up the parameters required for this actual process, and then calls the invoke method to send the command to EC2. You can see here that I also pass a delegate to a callback that will handle the response (the invokes call back calls this method), and I also allow higher layers to pass their own user data (it helps this library to deal with multithreading).
The real trick now comes in the handling of the response in the callback, and where I think my approach differs greatly from the existing Amazon EC2 library. That library applies XSLT embedded in the resource to build a result object (and also does not do things async, as well as having all kinds of other overhead), where I just use a little Linq to XML to process the return XML into an actual object. Did I say I really like Linq to XML?
Matter of fact, let me show the code for the describe volumes command. This is nead as it has a link query that shows two levels of query in one statement, as the response is an array of volumes, with each volume having a potential of multiple attachement objects. The Linq to XML below does this easily and clarly in one statement:
Notice the nested from statement; Attachments is a list property of the DescribeVolumesResult class, and the "from" will be interpreted to be the currently selected volume entry in the XML as represented by the volume variable. I also really like the use of absolute XPath to select the outer level objects, and then the relative XPath that is automatically relative to the XElement selected from the outer "from".
BTW, did I say I love Linq to XML?
I have a few more layers on top of this, but this is the basic stuff to make this work. Those upper layers allow things like blocking until a detach/attach is complete, which I need for scenarios that I will also explain at another time. There is also some interesting things that I will have to say about multi-targeting this code for both WPF and Silverlight that I'll discuss at another time (but for now lets say its a pain in the arse).