[rules-users] Multiple packages approach

[Torfox]

Excelent! Thanks for your input.

I suppose separate KnowledgeBase-s are the best pattern in this scenario. I
got the point, the the product identification is required since the rules
are executed in the same space, no matter what package name is. This would
complicate my rules a lot. When executing a KnowledgeBase with a single
product that problem is not relevant. I thought about multi-channel and
brand differences and that is one of the reasons I love drools. Eg. when
there is a special discount for a broker X in channel Y all I have to do is
to add additional file with rules that apply this change only. I organize
rules in folders corresponding with packages.

I haven't thought about using RuleFlow yet :)

I've also came to the conclusion that separating rules into many
KnowledgeBases has an additional advantage, when a calculation for a single
product fails for an unknown reason. It allows other calculations to finish
their job.

Bye,
Bartosz


Ross H wrote:
> 
> Funny you should mention that, I have not got my head around packages yet.
> Maybe it's just a namespace thing - I'm still learning.
> 
> I think there may be two parts to this problem. How do your rules know
> that
> it is product x for the common customer information, I suppose you might
> have the product id in the rules! Of course for future flexibility you
> might
> want to consider multi-brand, multi-channel differences in pricing as
> well,
> so that can complicate the picture. Even worse you might have to consider
> date effective pricing and grandfathering of rules as the business changes
> their pricing rules.
> 
> So it depends yet again, if you want to get a set of prices from a single
> set of customer info, you need to differentiate based on conditions. On
> one
> hand you could have a single KnowledgeBase with rules that have complex
> conditions regarding product etc, or you can manage multiple
> KnowledgeBases
> and submit the same customer info to them to get your set of prices and
> use
> your app to manage this.
> 
> Even more interesting is to have your pricing service route and transform
> the customer information as necessary to call different KnowlegeBases
> depending on the context. You could even use a RuleFlow to manage this for
> you and use different ruleflow agendas.
> 
> The problem with Drools is that it is just so flexible :-)
> 
> In summary I'm probably in favour of separating out KnowledgeBases and
> having the app know the context. This may result in some duplication but
> gives a degree of flexibility for changes and independence and simplifies
> your rulesets.
> 
> Happy for others to shoot me down, so I can learn more too.
> 
> On Mon, Dec 7, 2009 at 6:10 PM, Torfox <bartosz.jankiewicz at gmail.com>
> wrote:
> 
>>
>> 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
> 
> 

-- 
View this message in context: http://n3.nabble.com/Multiple-packages-approach-tp69223p69914.html
Sent from the Drools - User mailing list archive at Nabble.com.