I know there are further emails where you settle on a multiple KB approach, but here's
my advice at this stage:
1) If your rules involve tight integration between premium evaluations, then a single KB
is preferable. i.e. While evaluating premium A and B for customer C, if the partial
evaluation for A can influence B, then use a single KB. If A and B must be evaluated to
completion, then use multiple KBs. Also, if you would like to avoid the rule complexity
in preventing integration between the rules, then use multiple KBs. (Rules in one KB,
unless you explicitly specify, will just interact on their own. That's the main
feature of rulebased systems, in fact.)
2) If your premium evaluation rulesets have many common elements then a single KB is
preferable. i.e. X% of the evaluation rules are identical between evaluations, with only
the final Y% being different. Mattering on how large X is, you could have increased
efficiency by only doing that processing once.
3) If you want to scale horizontally, then multiple KBs are best. i.e. you would like to
process evaluations of premiums in parallel, on one or multiple hosts.
--- On Mon, 12/7/09, Torfox <bartosz.jankiewicz(a)gmail.com> wrote:
From: Torfox <bartosz.jankiewicz(a)gmail.com>
Subject: Re: [rules-users] Multiple packages approach
To: rules-users(a)lists.jboss.org
Date: Monday, December 7, 2009, 2:10 AM
Hi Ross,
Thank your for your response.
Here is a wider context of my application. I'm implementing
insurance
premium comparison system. So the system applies the same
fact (customer
information) to many sets of rules. Every set of rules
represents a single
insurance product. The result of execution of every rule
set is an object
describing premium value and some calculation logs. By
clearing the context
I re-initiation of this resulting object in WorkingMemory,
before the next
set of rules is activated. I don't know yet if that kind of
action is
possible in drools - does drools execute rules
package after package? I
haven't found yet an explanation of package role in the
rule execution
process.
Bye,
Bartosz
Ross H wrote:
>
> Hi Bartosz,
>
> I think the answer is "it depends", and that is in the
context of the
> application you are trying to develop. I don't quite
understand your
> statement about clearing the calculation context when
the session is
> stateless.
>
> Whichever approach, I would wrap it as a pricing
service with business
> methods, and then under the covers you can use
whatever strategy you like
> and change that without impacting your application.
>
> I'm also not sure if you are asking from a perspective
of performance, so
> is
> it better to have number of smaller KnowledgeBases or
one large one from a
> memory/response aspect, and that depends on the number
of rules,
> complexity
> of conditions, and of course your fact model.
>
> On the other hand if you want to manage the lifecycle
of your products
> independently (say the pricing rules change
frequently), and as you say
> the
> rulesets are independent, then it might be better to
have separate
> KnowledgeBases from a management perspective. How do
you deploy the rules,
> embedded, Rule Agent, BRMS ...
>
> Maybe some more info on your solution space would help
others to give you
> a
> better response.
>
> Regards Ross
>
> On Sun, Dec 6, 2009 at 7:43 PM, Torfox <bartosz.jankiewicz(a)gmail.com>
> wrote:
>
>>
>> Hi,
>>
>> I'm trying to achieve the following result. There
are many rule sets,
>> every
>> set is responsible for insurance premium
calculation and these sets are
>> independent (every set applies to a single
product). I have organized the
>> rules into packages, where package identifies
product.
>> After calculation of every rule set I have a
resulting object insurance
>> premium and calculation log.
>>
>> What is the best pattern to execute those rules.
E.g. can I put all
>> packages
>> into a single KnowledgeBase and execute
StatelessKnowledgeSession
>> providing
>> that the last rule of every rule set clears the
calculation context?
>> Or is it better to create separate KnowledgeBase
for every single
>> product?
>>
>> Thanks for the hints.
>>
>> Bartosz
>> --
>> View this message in context:
>>
http://n3.nabble.com/Multiple-packages-approach-tp69223p69223.html
>> Sent from the Drools - User mailing list archive
at
Nabble.com.
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
View this message in context:
http://n3.nabble.com/Multiple-packages-approach-tp69223p69839.html
Sent from the Drools - User mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org