[By the way this was a goal of OMG PRR, but we failed to come up with any decent visual models so didn't fulfil that requirement. No vendor has AFAIK either...]

Also you will note that in TIBCO BE we don’t claim that / target the BE rule language as being suitable for “business managers” or even “business analysts”. It’s a developer language (analysts are targeted by the BRMS, which tellingly does not map to the Rete production rules…).

In any case, I’m sure we can agree there is more work to be done on exploiting Rete rules. It will be interesting to see what Dr Forgy has to say on CEP and rules at ORF in a few weeks…

Cheers

peter

I love declarative rules, but the same problem exists. Depending on how the user translates the business requirements into declarative rules affects the efficiency and performance. In the past, this has been the job of a knowledge engineer who has knowledge of both the business and technical domain.

My feeling is the tools have a long way to go towards making writing maintainable high performance rules easy. I’ve been working on these problems for over 8 years now. For example, I have a RETE topology cost function, which makes it easier to measure the average cost of a ruleset or rule. You can read the paper here.

http://jamocha.svn.sourceforge.net/viewvc/jamocha/morendo/doc/dynamic_typing.pdf

peter

Note that in TIBCO BusinessEvents we:
- have both declarative rule and continuous query languages that exploit the Rete pattern matching algorithm
- provide a UML state model as a higher level abstraction for rule programming [but this is in no way a generic inference model]

For a further discussion on anti-Rete hype see http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1549797&discussionID=3561358

Cheers

A “user friendly” event language has to find the delicate balance between ease of use and accuracy. Ultimately, the user has to understand temporal logic. There’s no way to get around that. The problem is, most people have zero understanding of temporal logic and don’t realize they’re writing garbage.

In the past, I encoded the temporal logic in the DSL, so the user doesn’t have to know it. The limitation is the DSL isn’t general purpose and can become brittle/obsolete over time.

peter

cheers,

Opher

I pointed out this one example to illustrate the difficulty of understanding how to write good rules that scale well. Instead of using a fact for timestamp, the user should have used a function and avoided modifying the timestamp fact.

The average rule user doesn’t have a clue how a production rule engine works and doesn’t realize they’re doing something really bad. On the surface, it looks ok. Unless someone has a deep understanding of how RETE engines work, they’ll keep doing things that bring the engine to a crawl. The sad thing is, the example I cited isn’t the first time that type of question has been asked by a developer.

I’ve seen that type of question asked countless times and most of the users never take time to understand how to write performant rules. Instead, they make false assumptions and write procedural rules thinking it will all work. when it doesn’t they blame the engine or RETE and don’t realize they don’t understand RETE.

peter

In the JESS case you mention the thread ends with the comment
“don’t set the update frequency of you timestamp fact to high!!!”
- which presumably is something particular to JESS or the user’s application…

In BE the events are presumed to be pushed, not polled, so if you wanted to poll you would have to set up a rule timer to and associated action. (Or a scheduler).

But I don’t think a polling frequency setting is anything to do with Rete per se. And the basics of Rete (which are probably my level of understanding) - for example as documented in OMG PRR - are usually sufficient for most cases except in developing clever Waltz and Manners type programs. For the latter, then yes, a couple of years’ worth of experience may be useful!!!

Cheers

You’ve been around rules for much longer than me, so I’m sure you’ve seen this hundreds of times over the years. On CLIPS and JESS mailing list, this type of thing happens all the time. Earlier this year, someone was trying to use JESS for event stream processing and was running into problems.

The individual asked for help. After he discovered the watch command, he realized the mistake. The details of this one case is in jess mail archive (http://www.mail-archive.com/jess-users@sandia.gov/msg10787.html).

Even though the user found a workable solution with some help, he still doesn’t understand how to write performant rules. The types of cases I’ve seen weren’t due to business analysts writing rules. Typically, I see developers making these mistakes. I’ve seen very bright senior engineers struggle with RETE and never really get it.

It’s probably taboo to say this, but learning how to use a RETE rule engine requires several years of dedicated study. An engineer with 4-5 months to make a prototype simply doesn’t have the time to learn how to write great rules. More likely than not, they make all the same mistakes and then mistakenly think product X is bad for my project.

peter