Categories: .Net, AWS, C#, EC2, S3, Silverlight, WPF Posted by mheydt on 12/31/2008 8:54 PM | Comments (0)
As part of all of this research into Amazon cloud computing I've started to program against the API's to see how they work.  Eventually I'd like to build a client that does a lot more than what can be done with ElasticFox, which is a great tool, but falls short when you try to do things that require multiple steps.  For example, one scenario that I'm already repeating all the time is the following:

1) Launch AMI
2) Mount 2 volumes to it (one step for each)

This isn't very difficult to do, but imaging if I'm building out managed services on behalf of other clients of mine, and the # of clients gets large, such that this will actually start to take a lot of time in the aggregate.  I'd like to have a tool that can do this automatically, and it is possible to program this to be done through the web services.

Another scenario that I'm thinking will be useful is to be able to do automated backups of AMI's and / or volumes, and perhaps also roll back AMI's and / or volumes on a regular schedule.  Again, not too hard with ElasticFox, but again a manual process that doesn't scale well.

So, I've started programming a WPF client using one of the C# api's available on the Amazon site, the C# Library for EC2.  It's been pretty easy to use so far, and I wanted something C# based instead of pure SOAP / REST.  There are deficiencies in the library that I will address later, but I wanted to show what I've done so far even though it's really just proving to myself that this works.

The following is a control that I put together to manipulate S3 buckets.  It's a listbox that is databound to the results from the 'listAllMyBuckets' method on the AWSAuthConnection class in the C# library:



Indeed, these are the two buckets that I have right now.

For reference, I include the XAML and the code behind for the control:






I've also coded this to show me my running AMI instances, but I'll save space here and not post that.

As I mentioned earlier I consider this library to be good but also to have a few deficiencies which I am going about fixing, and I'll probably post these changes back into the amazon code samples.  My two big issues at this point with the library are:
  1. All the calls are synchronous, and
  2. The "business objects", like 'Bucket', do not utilize INotifyPropertyChanged

The first causes the UI to lag when the calls are waiting to complete.  This could be addressed by running these calls in a background thread, but that only solves this for WPF.  Inherently, this library will not work under Silverlight as all calls are asynchronous in Silverlight.  So, all these calls need to be made to be asynchronous to support Silverlight, which I definitely want to use the library with.

The second point prevents a lot of the nice databinding capabililities, particularly two-way binding, in WPF and Silverlight.  As an example, suppose you are monitoring an AMI initializing and want to change the UI when the state changes.  The UI control will be bound to a 'RunningInstance' class object, and will show the current state of the instance.  You'll then need to poll occasionally to see if the state changed, and when it does, you will currently need to change both the property value in the RunningInstance object, and then also code the change to the UI as the property will not advise any listeners of it's change. 

Both of these aren't bad design issues in the library, as when it was built I'm sure it was not with the intention of being used in WPF and Silverlight.  So, I'll fix them up and put them back in the Amazon code samples.  I'll address the property update problem first as it is more important to me right now, and then handle the async calls afterwards.

Edit: I've since looked into this and to me it seems that it will be far less work to just rewrite the library.  In addition to not taking advantage of either INotifyPropertyChanged, or using asynchronous calls, there are also great advantages to be had in using LINQ 2 XML to parse the results.  Currently, this is all done with XSLT, and that's just way too complicated when you can use newer language constructs.

Another decision that I've come to is that since I'm going to work on rewriting this instead of extending it, I'm going to post the new code on Codeplex instead of back at Amazon.  I've actually created the project and it is here http://www.codeplex.com/AmazonAWSSharp.  No code yet, but hopefully some basic S3 stuff in the next few days.

Comments