« review: Patterns of Enterprise Application Architecture | Main | John Sowa on the Semantic Web »

Here be dragons

The Mountain of Worthless Information

Ted Neward asks about rule driven programming:

In many respects, this should come as a welcome relief to enterprise system programmers, since it now means that a large part of the coding effort of the "business logic" in the system can be done in a tool that better fits the problem domain. If that were the case, then, why haven't rules engine become the new "Hot Topic' within the industry?

I've asked myself the same thing. Once you've been bitten by the Prolog or Jess bug, businesss logic programming in a systems language can seems very awkward.

Ted says:

The problem that the current crop of rules engines face is that the language by which we express the rules is frequently a language that Java developers have never, ever seen before.

Well true, there is no accounting for developer taste, but perhaps the problem is not just syntax.

Ted is interested in drools because the XML syntax may appeal to developers. But even if you accept the premise that developer reluctance is the bottleneck, arguably coding business logic in XML is at least as much a bogosity as coding business logic in Java (make no mistake, this is a form of coding). At the very least, an editing tool that hid the markup from sight would be needed. And I think if I must hack code in XML, I'd just as rather use XSLT or XQuery instead of a new syntax. As well as drools syntax, lets not forget the RuleML specification, which has close ties to the Rule API JSR.

XQuery btw is the W3C sanctioned XML Query Language, a hybrid of SQL and XSLT, that ends up looking a bit like a shell script. 'Software platypus' is a good term for it. Anyway, XQuery could prove to be useful as a target language for rules programming. And there are a number of currently used languages in the enterprise that could be leveraged for rules programming. It doesn't take long to build a conditon-action pair system out of XPath or regular expressions (and that's what many SOAP routers and firewalls will look like on the inside). Heck, you can even throw this sort of thing together with dependency checkers like make or Ant (is not a scripting language! I know).

Or you could use SQL. Most everything you might want to say in Prolog or an XML rules language, you can say in good old SQL with a SELECT clause, and optionally, some triggers. That's because all these languages are based on what AI types call 'existential conjuctive logic', or ec logic, a tractable subset of predicate calculus. It'll be inefficient (as you're working with syntax trees via a relational structure), but it will work. And guess what? Chris Date is a strong advocate of using a rules based language to describe business logic. His book, ''What not How?" is a manifesto of sorts for rules programming.

So arguably we already the languages needed for rules in the enterprise, it's matter of using them that way. But if we were look at the developers again, I think the real issue you will find is not that Prolog or Jess or drools, or XSLT is syntactically weird, but that thinking in terms of rules and recursive functions is weird, for I would dare to say, the majority of procedural and OO programmers, no matter what the rules language is. Try running the line 'a SQL query is a theorem about a database' past your developer colleages to see how they respond. Or show them a non-trivial makefile. You're working against years of training that teaches people to think.. like programmers.

It is easy to write rules that are computationally inefficient (even if you have the Rete algorithm implementated like drools does). And as I said above, if a rules system sits above a relational database performance may be unacceptable, since relational databases cannot easily store tree structures in an efficient manner. Much of the stuff a business will want to apply rules over will be in RDB tables.

One of the big lessons learned from the expert systems collapse in the 1980s was that it can cost just too much money to get a factbase in place; gathering data in relational form and writing procedural code and SQL proved to be cheaper and quicker, albeit dirtier. You absolutely want the business to drive the evolution of a factbase.

As for drools itself (nice code base), there is one immediate downside with its approach. Java is the wrong language to use to populate a factbase. That's something that should be done by the business, ideally without the intermediate step of going through a programmer - in much the same way, we don't like to ask web designers to deal with Servlet code. In Prolog, you would generally use Prolog itself to write down facts (they tend to look a bit like RDF triples actually). Often, facts are just degenerate rules (they have no action against the conditonal, so the conditional becomes an inert fact).

The single biggest lesson learned by AI is that it is a mistake to treat rules and facts as configuration files to an engine. How knowledge is declared is far more important that the algorithm applied to it. This is the one of the main reasons the Semantic Web effort has been bogged down in the minutiae of knowldge representation for the last two years. It's a painful but important process.

Having said all that, Prolog is a fun language and anything that gets compound logic out of Java like drools does, is a good thing. I like rules technologies and Prolog is one of my favourite languages. But there are real costs and risks asociated with using them. Like so many technologies the devil is in the details.

If this stuff takes off, and I think it's inevitable someday, business rules systems will require specialist maintainers or analysts (a Rules Base Administrator, or RBA), who also understand the problem domain. Because version control becomes an issue for large rule sets. A large rule base will probably contain inconsistent or contradictory rules resulting in unpredictable, undesirable and inefficient effects, unless a specialist maintainer is appointed. A lot of research was done on automating the management of factbases using Truth Maintanance Systems (TMS) in the 1980s, but I don't know how much of that work made it out of the labs.

Acolytes of rules technology I think believe that business rules software can replace hoards of programmers and programming, since business people will write the rules themselves. This is a very seductive message. I'm sure I remember the same thing being said about SQL and RDBs, but in hindsight seems that RDBs have generated their own programming industry - I don't think anyone expected that.

February 23, 2003 11:38 PM


James Strachan
(February 25, 2003 07:17 AM #)

Note that drools already supports pluggable rule semantics in a variety of different languages from XPath, Java syntax or Jython. It'd be trivial to add XQuery, SQL or even Prolog if you wanted.

Trackback Pings

TrackBack URL for this entry: