In the last post, I wrote all about portals, and how they can be used to build up a hierarchy of communicating KnowledgeScapes for performance, reliability and access control. In this post I want to introduce a little bit of magic with regard to distributed computing and performance. When you configure your KnowledgeScape cluster, you define KnowledgeScapes on the machines on which they will run. From the user interface, you can also define "slaves". These are slave processes, that can run on the same machine, or any other machine on the cluster. These slaves are then available to offload rule and genetic algorithm execution to another processor core.
There are really two salient features of KSX slaves that deserve mentioning here. One is how easy it is to use them. Any rule script can use them. Instead of invoking the rule script using the invoke command.
invoke myRuleScript
You can simply "fork" the rule script, and it will be invoked on one of the processing slaves.
fork myRuleScript
The execution happens asynchronously. You may want notification on the main KnowledgeScape server when the asynchronous work is done. This is very easy too, you simply extend the fork keyword with the callback keyword and another rule script.
fork myRuleScript callback anotherRuleScript
When myRuleScript finishes executing on some remote slave, anotherRuleScript is invoked on the server KnowledgeScape and passed the return value of myRuleScript. It really couldn't be any easier. So long running, resource intensive tasks like statistics and reporting can just be shunted off to a slave, leaving the KnowledgeScape server unencumbered.
The other point I want to emphasize on the ease of use, is with the genetic algorithm optimizers built into KSX. A genetic algorithm is a sophisticated search technique for finding global optima (minimum or maximum) based on a fitness function. It is nevertheless an iterative process. It simulates natural selection, where a individuals in a population breed with one another selectively, based on fitness. The best individuals favored above the worst. In the computer implementation of this, a fitness function is evaluated. This may be a simple, or arbitrarily complex calculation. In KSX it is simply the evaluation of any rule script. KSX allows the invocation of the fitness rule scripts to be performed in parallel on slave processors by simply checking a checkbox. If you have an computationally expensive fitness function, you can achieve huge performance gains by simply adding slaves to your cluster and running the genetic algorithm in parallel.
Now, onto the second salient feature of KSX slaves. They are dynamic. The rule system has built in functions to manage slaves across the KSX cluster. You can query, add and remove slaves dynamically, at run time from KSX rule scripts. This means that you can elastically add and remove slaves as needed to process jobs at hand. If you are running batch optimizations or any other sort of batch job, you may want to increase your computing resources, so you can simply invoke the built in functions to increase the number of slaves on the cluster, run the jobs, then shutdown the extra slaves when you are done. Another great feature that ties in directly to this is the ability to actually start and stop machines in the cluster. KSX has been designed for elastic clusters, meaning, it runs on the cloud. Since KSX rule scripts can call out to the operating system shell, it can call any Windows batch file, Unix shell script, or executable. This means that it can easily call scripts to spawn new Amazon EC2 instances.
So not only can KSX dynamically spawn jobs to processing slaves, it can dynamically add processing slaves to computers in the cluster, and dynamically add computers to the cluster, giving the user the ultimate flexibility in performing compute heavy jobs. To me, this sets KSX apart from any other expert system or rules engine software out there. And it makes it a candidate for all sorts of applications we haven't even thought of. If you can dream it, you can do it with KSX.