[rules-users] Multiple packages approach

Tue Dec 8 06:19:27 EST 2009

The other factor to consider is how you do your premium calculations. If
they are mainly in the rules and with many common elements then Greg's
points 1 and 2 apply.

On the other hand if the calculations are mainly in java code or lookups and
your rules coordinate the use of this code then other factors will determine
your choice, particularly the multi product/brand/channel combinations.

The key determining factor in all of this is probably the %commonality
between rules.

On Tue, Dec 8, 2009 at 1:58 AM, Greg Barton <greg_barton at yahoo.com> wrote:

> 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 at gmail.com> wrote:
>
> > From: Torfox <bartosz.jankiewicz at gmail.com>
> > Subject: Re: [rules-users] Multiple packages approach
> > To: rules-users at 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 at 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 at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/rules-users
> > >>
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users at 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 at lists.jboss.org
>
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20091208/8d296bee/attachment.html 