Funny you should mention that, I have not got my head around packages yet. Maybe it&#39;s just a namespace thing - I&#39;m still learning.<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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. </div>
<div><br></div><div>The problem with Drools is that it is just so flexible :-)</div><div><br></div><div>In summary I&#39;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. </div>
<div><br></div><div>Happy for others to shoot me down, so I can learn more too.</div><div><br><div class="gmail_quote">On Mon, Dec 7, 2009 at 6:10 PM, Torfox <span dir="ltr">&lt;<a href="mailto:bartosz.jankiewicz@gmail.com">bartosz.jankiewicz@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Hi Ross,<br>
<br>
Thank your for your response.<br>
<br>
Here is a wider context of my application. I&#39;m implementing insurance<br>
premium comparison system. So the system applies the same fact (customer<br>
information) to many sets of rules. Every set of rules represents a single<br>
insurance product. The result of execution of every rule set is an object<br>
describing premium value and some calculation logs. By clearing the context<br>
I re-initiation of this resulting object in WorkingMemory, before the next<br>
set of rules is activated. I don&#39;t know yet if that kind of action is<br>
possible  in drools - does drools execute rules package after package? I<br>
haven&#39;t found yet an explanation of package role in the rule execution<br>
process.<br>
<br>
Bye,<br>
Bartosz<br>
<div><div></div><div class="h5"><br>
<br>
Ross H wrote:<br>
&gt;<br>
&gt; Hi Bartosz,<br>
&gt;<br>
&gt; I think the answer is &quot;it depends&quot;, and that is in the context of the<br>
&gt; application you are trying to develop. I don&#39;t quite understand your<br>
&gt; statement about clearing the calculation context when the session is<br>
&gt; stateless.<br>
&gt;<br>
&gt; Whichever approach, I would wrap it as a pricing service with business<br>
&gt; methods, and then under the covers you can use whatever strategy you like<br>
&gt; and change that without impacting your application.<br>
&gt;<br>
&gt; I&#39;m also not sure if you are asking from a perspective of performance, so<br>
&gt; is<br>
&gt; it better to have number of smaller KnowledgeBases or one large one from a<br>
&gt; memory/response aspect, and that depends on the number of rules,<br>
&gt; complexity<br>
&gt; of conditions, and of course your fact model.<br>
&gt;<br>
&gt; On the other hand if you want to manage the lifecycle of your products<br>
&gt; independently (say the pricing rules change frequently), and as you say<br>
&gt; the<br>
&gt; rulesets are independent, then it might be better to have separate<br>
&gt; KnowledgeBases from a management perspective. How do you deploy the rules,<br>
&gt; embedded, Rule Agent, BRMS ...<br>
&gt;<br>
&gt; Maybe some more info on your solution space would help others to give you<br>
&gt; a<br>
&gt; better response.<br>
&gt;<br>
&gt; Regards Ross<br>
&gt;<br>
&gt; On Sun, Dec 6, 2009 at 7:43 PM, Torfox &lt;<a href="mailto:bartosz.jankiewicz@gmail.com">bartosz.jankiewicz@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; Hi,<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m trying to achieve the following result. There are many rule sets,<br>
&gt;&gt; every<br>
&gt;&gt; set is responsible for insurance premium calculation and these sets are<br>
&gt;&gt; independent (every set applies to a single product). I have organized the<br>
&gt;&gt; rules into packages, where package identifies product.<br>
&gt;&gt; After calculation of every rule set I have a resulting object insurance<br>
&gt;&gt; premium and calculation log.<br>
&gt;&gt;<br>
&gt;&gt; What is the best pattern to execute those rules. E.g. can I put all<br>
&gt;&gt; packages<br>
&gt;&gt; into a single KnowledgeBase and execute StatelessKnowledgeSession<br>
&gt;&gt; providing<br>
&gt;&gt; that the last rule of every rule set clears the calculation context?<br>
&gt;&gt; Or is it better to create separate KnowledgeBase for every single<br>
&gt;&gt; product?<br>
&gt;&gt;<br>
&gt;&gt; Thanks for the hints.<br>
&gt;&gt;<br>
&gt;&gt; Bartosz<br>
&gt;&gt; --<br>
&gt;&gt; View this message in context:<br>
&gt;&gt; <a href="http://n3.nabble.com/Multiple-packages-approach-tp69223p69223.html" target="_blank">http://n3.nabble.com/Multiple-packages-approach-tp69223p69223.html</a><br>
&gt;&gt; Sent from the Drools - User mailing list archive at Nabble.com.<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; rules-users mailing list<br>
&gt;&gt; <a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
&gt;&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; rules-users mailing list<br>
&gt; <a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
&gt;<br>
&gt;<br>
<br>
</div></div><font color="#888888">--<br>
View this message in context: <a href="http://n3.nabble.com/Multiple-packages-approach-tp69223p69839.html" target="_blank">http://n3.nabble.com/Multiple-packages-approach-tp69223p69839.html</a><br>
</font><div><div></div><div class="h5">Sent from the Drools - User mailing list archive at Nabble.com.<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</div></div></blockquote></div><br></div>