Don Cameron

I realize there are a number of options for decision based rules engines (WF BPE for example), but wondering what people do for calculation type formulas The business problem is adjudication of loans. The business rules consider 120 input values, 150 constant values, 420 formulas giving about 80 result values for each application. Of course these values and formulas can change on a peridic basis.

I am sure those of you in the banking and or the insurance industry are doing something similar.

thanks

Don



Re: Architecture General Rules engines for large number of formulas

jftl6y_007

Full disclosure before I continue - I have no affiliation whatsoever with Corticon.

At any rate, I'm evaling a bunch of rules engines right now (Blaze, JRules, JBoss Rules, BizTalk BRE, etc.) and an interesting one came up in Corticon. I say interesting because while the others are all RETE based engines, Corticon pre-compiles their rules during design time, so there's no runtime decision tree overhead. I'm not sure based upon your post if this is what you're concerned about, but I'm thinking that perhaps such an engine would be more performant for calculation formulas as the execution path is pre-compiled.

My $.02




Re: Architecture General Rules engines for large number of formulas

MossUser1

Hi,

Your point is well taken but i would like to know as why those big tools like blaze,biztalk,Jboss work on a technology(creating decision tree at runtime) which is slow performing.Can't rete based algo can be implemented while compiling at design time rather than at runtime.i think there should be pros also of making decision tree at runtime.

Any inputs on this will be highly appreciated.

Cheers





Re: Architecture General Rules engines for large number of formulas

jftl6y_007

Actually the Rete algorithm is quite fast, much faster than firing rules in a set sequential order and in fact often the drawback to Rete algorithm engines is that they consume memory in favor of speed, though this wasn't ever an issue in our evaluation.

The point I was making before was that the Corticon tool may be (and I stress the "may be" as I have no hard data to support this) more performant at run time for the specific instance raised, where there are a large number of formulas used in the rules, because it does not have to build the decision tree at runtime - for rules with many calculations involved in either the left hand side of the rule or the facts which satisfy the rule, this could take some time to build the decision tree, but once built, the performance is excellent regardless of the number of rules.

For many implementations, the performance hit for building the tree is not significant. In our specific evaluation (for an insurance company), many of the rules are fairly straightforward, dealing with policy and claims processing rules, so there is not a lot of calculations happening, and none of the Rete engines had any performance issues.

As for why can't the Rete algorithm be implemented at design time vs. runtime, I'm sure it could be though one of the advantages of runtime inferencing is that you could potentially modify rules dynamically. Corticon claims (disclosure, this came right from the mouth of the sales rep and their white papers) that whereas the Rete engines all evolved out of building Expert Systems with a lot of human interaction (and hence the runtime inferencing and dynamic modification and conflict resolution of rules) their rules are designed to be deployed as a static rule set that cannot be modified at runtime, which Corticon claims is more performant for set rules, and also generates more predictable results (and easier testing) as conflicts are caught and resolved at design time.

I haven't seen the Corticon product yet, but some of their claims (taking the normal discounts for salesman-speak) make a lot of sense in that they're addressing a different paradigm. All of the products tested so far have performed more than adequately, the challenge has really been realizing the claims of all of these engines that the real advantage is being able to have a business analyst compose and maintain rules and deploy more quickly than having them in code. I haven't seen anything quite yet that I'd be comfortable handing to a BA and saying "Go for it" and many of these I can see are more operationally focused than others.

And architecturally speaking, I'm still not convinced that I'm saving time or becoming more agile by implementing one more very complex, very expensive tool than by implementing rules as a set of strategy patterns, and having a configuration data store that tells my code at run time which of my rules to fire and how to fire them.

Sorry for the book....




Re: Architecture General Rules engines for large number of formulas

pkr2000

On a slight tangent, have you considered using Excel Services (you don't to see the spreadsheets)

http://windowsfs.com/eNews/tabid/112/articleType/ArticleView/articleId/2073/Default.aspx