In my previous post I described the idea of using plug-ins in Windows Azure. In context of this sample we implemented a general plug-in framework. As we saw in the video, we need two services: one which is taking the work orders and stores them in the repository and the other one which is processing them.
WorkOrderGatewayService is representing a service which takes the work orders and stores them in the BLOB Storage. This service also answers the question whether the work order is done or not.
WorkOrderProcessorService is representing the service which is processing the work orders.
I often hear about the Cloud as the Messiah these days. Cloud should not be seen as a bad architecture saver; it is not. Bad architecture or approach will remain ‘bad’ under any circumstances, but linked with a Cloud you will faced significant costs. Cloud is about elasticity enabled through the pooled resources. If you don’t achieve high utilization, you are paying for nothing. High utilization of machines should be given as well, but how can we achieve this? The idea is simple; we are specializing work, instead of worker.
The “worker” in context of Windows Azure (now Windows Azure Cloud Services) is the Worker Role. The Worker Role is the beast which is continuously looking for a new job to be processed, similar to a Windows Service. But how to deliver a job do be done in flexible way and independently? The idea is simple, with the help of plug-ins.
Update 14. February 2013: In the Plug-Ins infrastructure I implemented in this sample was one big design issue. If you downloaded the code before this date, please take the new one. Read this blog entry for more details.
Update 10. March 2013: In the class
PluginBase was overridden the method
InitializeLifetimeService. This method is returning null, to disable remoting lifetime service. If you don’t do this you will get, after couple of minutes, the Remoting Exception “Object […] has been disconnected or does not exist at the server.” when the plugin’s instance is not be used. This is not the best idea for your production code, because the plugin’s instance is staying in memory until will not be explicitly unloaded from.