Re: [xml-dev] A design problem

["Peter Hunsberger" <peter.hunsberger@gmail.com>]

On 10/19/06, LAKKAM Vinay (AXA-I) <Vinay.Lakkam@axa-insurance.co.uk> wrote:
> Hi,
>
> I need a suggestion for an xml design in my project.
>
> We have a requirement to build a rules engine which will be accessed very
> frequently(almost after every screen) to get a rule result. The rules engine
> will have about 100 rules, and when we pass the input information it will
> process again all the rules and returns the matched.
>
> I could only think of using a database table to implement this rules engine.
> For that I need to call DB after each screen to check if any rules matched.
> But this is going effect the performance of the system. The other way is to
> get all rules initially, preserve it with message that you send between
> server and client, and use to get the matched rules whenever needed. But the
> increased message size will again cause degrade in system performance if the
> rules size goes big.

You're talking very small rule set sizes.  Any standard database
should be able to keep such a set in memory and provide very good
response times.  It seems unlike the issue will be in rule look up,
rule processing might be a different matter

>
> And new rules will added to the rules engine by admin people, whenever
> needed.
>
> Could you please suggest the alternative ideas to implement this.
>
> (We use xml based j2ee framework.)
>

As suggested have a look at the vendor offerings.

We run a proprietary system that evaluates potentially 1000's of rules
for every screen with about 2000 different screens. The total rule
base size is probably being on the order of 200,000+ rules.  We use a
mixture of XSLT and Java to evaluate XML encoded rules.  Performance
generally is sub second, although we have some data heavy screens that
have performance issues related to the data set sizes.  We'll be
fixing many of those issues by using AJAX style updating of the
screens (as opposed to swapping the entire data set back and forth for
minor updates).

-- 
Peter Hunsberger