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?"
You might want to check out Enterprise Patterns and MDA : Building Better Software with Archetype Patterns and UML (Addison-Wesley Object Technology Series) by Jim Arlow and Ila Neustadt. They present a decent model to describe rules.
-- bearclaw
Depending on what you are doing a finite state machine could be a good answer. Take a look at the state machine compiler (SMC) on sourceforge.
Rule based programming's purpose is to solve a problem that requires complicated logic by declaring what the relationships are, instead of describing a procedure that solves the problem.
The advantage in these sorts of uses is that you can reason about the declarative program much easier than you can about the set of steps that you would write down in a procedural language.
SQL is a kind of declarative language that you might be familiar with. Although it is much less powerful than say prolog, its advantages for searching for information over something like a bunch of perl code are clear. Instead of describing how to search through the tables, you tell the database what the properties are that you're looking for.
Code that becomes nearly trivial in prolog often would look like some kind of nested case statement with exception handling in C++ for example.
Like many thing in programming, the declarative method is good for some things and less good for others.
((lambda (x) (x x)) (lambda (x) (x x))) http://www.endpointcomputing.com a scientific approach to custom computing.
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).
I am a PROLOG practitioner and I work in the field of AI, specializing in complex systems. Prolog is an excellent choice when the rules become unusually complex. You don't need a translator or compiler if you use Amzi! Prolog. You can generate compiled modules and call them via a DLL. No problem there. Check them out at www.Amzi.com. As to maintainability, any complex system can become formidable. Prolog will make long-term maintenance easier, not harder. Let me know if I can help. Best wishes, Burt Pierce