The relation between Business Rules Engines and Constraint Programming languages

If one looks at (perhaps older) manuals of Drools or some other rule engines, one of the illustrations of their added value is solving puzzles such as the Miss Manners puzzle (manual of Drools). Now, such puzzles are naturally formulated and solved using Prolog or the more recent Constraint Programming languages, and one wonders why would anyone would use Drools for this purpose. The added value which Prolog and CPL give in this case is their ability to naturally formulate the puzzle as a set of logical predicates and to automatically search the space of solutions (with CPL being more efficient in this respect). But what is the added value of product such as Drools (I mean besides of the bells and whistles of taking, for example, an Excel file and translating it into a set of rules)?

More specifically, Prolog implements backtrack search, CLP implement backtrack search with constraint propagation, and therefore instead of searching, so to speak, the whole Cartesian product of spaces for individual variables, they prune away large portions of this product space. This what makes them effective and useful. Both Prolog and CLP are discussed amply in the literature.

On the other hand, while it is clear that Rete algorithm caches the set of rules in the form of some data structure(s), thus (to my understanding) making it more effective to evaluate the output if some of the inputs have changed, and giving means to efectively update this data structure for incremental changes, it is difficult (for me) to understand the basic idea, and even more so, its efectiveness (compared to what? to Prolog? to CLP)? Unfortunately, it is hard to find good references that view Rete algorithm in this wider context.

The documentation of Drools is unfortunately not very informative in this respect. The most I could find was "The Rete algorithm, Leaps algorithm, and its descendants such as Drools' Reteoo (and Leaps), provide very efficient ways of matching rule patterns to your domain object data. These are especially efficient when you have datasets that do not change entirely (as the rule engine can remember past matches). These algorithms are battle proven". Very efficient - compared to what? Battle proven - could one point to real world applications?

I would appreciate if one could throw some more light on this subject or give a valid reference.

-

migrated from stackoverflow.comOct 17 '11 at 15:14

This question came from our site for professional and enthusiast programmers.

This question is a bit broad and doesn't really 'belong' here... – Widor Oct 17 '11 at 14:31
Well, I'm afraid that for cstheory.stackexchange.com it is too "industry-oriented".. What really interests me what is the basic point about business rules engines and why using them is more adavantageous than using Prolog or CLP. If you have a suggestion for a better place to post it, I will be glad to hear it. – John Donn Oct 17 '11 at 14:39

I think the argument for many commercial Business Rules Systems using forward chaining engines (eg. Drools) vs backward chaining (Prolog) is that many "Joe programmers" are used to dealing with IF/THEN/ELSE logic - and this makes it a whole lot easier to market to the masses. I don't think technical merit has anything to do with it.

I'm posting this as community wiki because it is my rather coloured opinion and not a real answer.

-

Drools recently adding backward chaining, seamlessly into the drl language. So now you get the benefits of both words.

It doesn't yet quite have all the features of prolog, for instance no 'cut'. But it's unification and deriviation tree results will work as prolog people expect, i.e. full support for transititive closures. And features will continue to grow, such as support for tabling, cut, unification on expressions.

You can use forward "reactive" or backward "query" rules separately, or use them together; where the reactive rule can join with the results of a query.

One thing we added is our queries can be fully materialised as a reactive view. So you can call a transititve closure query and it'll stay open in a reactive manner and respond to change in the underly ground data - without having to re-poll the query.

See New & Noteworth sections for when "backward chaining" was added: http://blog.athico.com/2012/05/drools-540final-released.html

So I think your question would be better worded, why would you want to use anything else, when you have Hybrid Reasoning System like Drools? http://blog.athico.com/2012/05/drools-54-artificial-intelligence.html

-

Drools started off by being based on CLIPS. CLIPS was an older "production system", and like all production systems is a forward chaining system. A lot of research on Rete has "gone dark" as the originator ended up going to work for companies where the algoritms were intellectual property. Rete version 3 is owned by the folks who make FICO scores, so yeah, it is "battle proven".

-

I agree with you that Prolog is more powerful than Drools. But I think Drools is appealing to enterprise client because of the fancy front end tools and integrations Drools has with other popular enterprise applications. I think these rules are then persisted to the database where many Drools engines can use them immediately.

Changing rules during runtime is a pretty dynamic way of using the Drools engine and it is supported. I believe Prolog could have a similar system, but this doesn't exist AFAIK. Where would these rules or edited rules go? asserted in the db of the program? On restart, these rules would be lost. Would we persist them to a shared db and then assert them into the program as needed? Prolog might be useable, but Drools is already well integrated into the enterprise application stack, so why make yourself crazy (except for fun)?

"I agree with you that Prolog is more powerful than Drools. But I think Drools is appealing to enterprise client because of the fancy front end tools and integrations Drools has with other popular enterprise applications"

As per my comment above, Drools now implements goal based derivation trees in the same manner as Prolog. Further Drools can do somethign with that deivation tree that most other Prolog systems can't. Drools can materialise the derivation tree into a view and receive reactive updates as the underlying grouond terms change.

-
@MarkProctor, generally, things which are objections as opposed to corrections should generally be done via commenting and (potentially) downvoting, as opposed to editing the content of someone else's answer. – Charles Duffy Jun 19 '14 at 4:11