Peter Miller

More About Time: Leveraging Castle Windsor

In a previous post, I mentioned working on a time keeping component. We used this component as the basis of a task scheduling application. Our tasks were represented by classes that implemented a common task interface:

 
public interface ICustomTask
{
   CustomTaskResult Execute();
   DateTime? ExecutionTime { get; }
   TimeZoneInfo ExecutionTimeZone { get; }
   string Description { get; }
}

public class CustomTaskResult
{
    public bool WasSuccess { get; set; }
    public string Message { get; set; }
}

So far, so good. Next challenge was how do we specify which of these tasks to run, and when? My initial thought was to put these details in an app.config or custom XML file. Task elements with the class name and time as attributes for example. Then additional elements for custom parameters that a task might need to initialize.

Fortunately enough, I work with some smart people, one of whom gently suggested that rather then create and manage my own custom config file, I instead leverage Castle Windsor (our dependency injection framework) and its configuration.

I’ll let the code do the talking; here’s a windsor section of an app.config for our task scheduler which will run two tasks at 9pm and the end of every day (the default if no time is specified) respectively:

<castle>
   <components>
       <component id="NightlyProcessing" lifestyle="transient" 
         service="Clarity.ICustomTask, Clarity.Task" 
         type="Clarity.Processing.NightlyTask, Clarity.Processing">
		<parameters>
		     <timeZone>Eastern Standard Time</timeZone>
	              <processingTime>9:00 PM</processingTime>
		  </parameters>
       <component id="RunSSISPackage" lifestyle="transient" 
	service="Clarity.ICustomTask, Clarity.Task" 
	type="Clarity.SSIS.PackageTask, Clarity.SSIS">
       <parameters>
         <description>Nightly Data Archiving</description>
          <pathToPackage>c:\Data_Archive.dtsx</PathToPackage>
          <pathToConfigFile>C:\DEV.dtsConfig</PathToConfigFile>
        </parameters>
      </component>
   </components>
</castle>

The namespaces have been sanitized, but the point is that you can specify parameter elements that map to constructor arguments. So for example, the NightlyTask class has a constructor with a timeZone and processingTime argument that get mapped to the ExecutionTime and ExecutionTimeZone properties on the custom task.

--- Relevant Links  ---

To take this to the next level (or if you just don’t like the angle bracket tax):

http://sheitm.blogspot.com/2009/05/fluent-castle-windsor-and-configured.html