xLim 2 Engine is an extremely simple concept and continues the idea from post on “How to simplify complex maintenance tasks of your information management solution?”.
So, if you have architecture like this, you can just:
- take multiple maintenance and automation tools of yours
- throw out all the repetitive code (connection, logging, security, etc) and wrap everything that remains with some common interface (ICommand or Action<IContainer> are equally fit here)
- Create some simple host (Win Service, Mono daemon, Console Application) that establishes an IoC environment by loading the shared assemblies (by just asking the shared module to register), then resolves every command in a dedicated scope and runs it.
Since the commands are just ordinary IoC components, you can configure them in some XML file and provide the parameters. The resulting config file will resemble NAnt build file quite a bit. The only difference is that you are playing with business objects, workflows and services instead of some low-level development entities.
And since the engine talks to the main server via the common gateway interface (and uses some access account for this), you can be sure that
- all possible harm will be limited by the permissions defined by the account
- logging and audits will be applied
We recently had to implement similar automation engine for the current xLim 2 implementation. That was extremely easy with this concept, since all we had to write was the engine host (200LOC for the console implementation) and the actual command logic. Shared modules lent us all the other required functionality (and even a couple of ICommand implementations were reusable)
Now, you’ve just got your simple business integration engine. Adding new tasks is trivial here, since you have to worry only about the actual code (the engine and IoC will DI all the required interfaces from the shared modules). Given that, you can easily:
- Send warning if some system goes short on DB or HD space
- Save sales numbers every 1 hour to capture the statistics for future analysis
- Fire alarms if some KPIs go out of range
- Send message to admin if that document processor service is not responding again
- Alert developers if there are any exceptions in the server log
It is an interesting coincidence that Ayende had written about the continuous validation concept in his web log. That fits quite close in this picture, although I believe he mixes two different concepts that logically should be separated: Environment Validation Framework and the Automation Engine.
Basically, the validation framework is just some IValidationReporter interface that is supported by some singleton components living in the root scopes of the application being validated. And then there is some component that generates composite validation report per request and sends it to the external monitoring system.
Now, why do we want to separate environment validation from the engine? These are the reasons:
- System might not have the components/interfaces for running regularl environment validation checks and then taking some actions based on complex logic (do you want to add that extra code in there just for that?)
- Configurations of different systems might have different ways of going invalid (i.e.: some systems could have recommended HD limit of 40Mbs while others could be limited to 40GBs, some could require access to dedicated workflow server and some could just live without that). You would not to spread that info with every config.
- Some failures could be detected only after being aggregated (i.e. work cluster could be considered to be in invalid state if all nodes are consistently overloaded)
- Some failures could be linked to external systems (i.e. HD space allocation for the user depends on type of the account of his company)
So it seems to be more efficient to have dedicated automation engines (you could have as many of them as you want) to handle all the meta-system logic, while leaving only report generation to the actual system being monitored.