Slashdot Mirror
Building Intelligent, Rule-Based Applications?
Donald Hughes asks: "What are good approaches for building intelligent, rule-based applications? In particular, I typically build ASP.Net applications. I came across P#, which translates Prolog into C#. I also came across NxBRE, which touts itself as the first open-source rules engine for the .Net platform. Currently, the intelligence in my applications consist of data stored in the database, which is either processed in T-SQL or in a C# class using linear conditional logic. This approach works fine to a point, after which the complexity of the if/then statements becomes extremely difficult to manage. This is especially problematic when returning to a project after several months of not looking at it, or when someone needs to be introduced to it for the first time. Does anyone have some helpful advice?"
How about this: consider an institutional currency trading system, such as those used by banks to hedge their currency positions.
You need a set of rules about when traders can go ahead and execute a particular trade. For example, if the bank already has a huge stash of Japanese yen, they might not want to buy any more (regardless of the price); they'll have a particular risk profile that each trade must fall into.
Now, the people who write the code to check how much the bank holds in Japanese yen at a particular point in time, will almost certainly NOT be the people who create and maintain the risk profiles that the bank needs to trade under when it buys or sells yen. The first set of guys will probably be full-time "normal" programmers who reference stuff out of one or more databases; the second set of guys will be trading management type people. While there's obviously a level of synergy required between the two, they're unlikely to (want to) sit and work together on a regular basis.
So far, it's not that unusual a problem.
Where it gets interesting is that both areas tend to be very dynamic: the definition of a good risk profile tends to vary over time, and the way of calculating current positions in Japanese yen may also change over time (as the bank starts/stops trading in different exchanges, as the bank opens/closes trading rooms in different parts of the world and different timezones, and so on).
Where rule-based apps shine in this scenario is that the two requirements can (and should) be largely separated. Provided the data coming from the data guys can be kept valid (which can be a huge challenge in itself), there's no reason for the risk management guys to be aware of where that data comes from or to question its integrity; they should be adjusting risk profiles via a rules-based mechanism rather than a programming mechanism that requires them to understand anything more than the actual values of the data.
Their rules may include things like "if we're going to buy more yen, we have to sell Brazilian real because we believe there's a relation between the two"; sure, you could employ a regular OO-type coder to do this stuff, but it's much quicker/safer for the guys making such rules to implement them in a rules engine. In this scenario, when a trader puts in a request to buy more yen, it will have to be matched with the amount of Brazilian real that has been sold to see if the appropriate ratios exist to allow the yen trade to go through.
Frequently, things get much more complicated than that, and maybe you'll have to deal with half a dozen other factors as well; this is a simplistic example that could probably be done with a few Excel macros and stored procs, but hopefully you can see how the complexity could scale to the point that a rules-based approach becomes significantly better than "traditional" alternatives as the problem becomes less and less trivial.
I know the original poster typically builds .NET applications, but for those times when you want to do this in Java, there are at least two good engines: http://www.mandarax.org/ is a backwards-chained engine (like Prolog), and http://www.drools.org/ is a forward-chained engine (takes action based on input).