<br> Godmar,<br> <br> We completely agree on that. It is really just a case of having the time improve the engine for the use cases you are describing. Your use case is not that different of Web Service enabled Decision Services, in terms of technical requirements.<br>
<br> []s<br> Edson<br><br> <br><br><div><span class="gmail_quote">2008/2/21, Godmar Back <<a href="mailto:godmar@gmail.com">godmar@gmail.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm replying to this thread without having read your blog post.<br> <br> When revising your design for how to represent facts, consider uses of<br> Drools. Currently, all facts need to be mapped to beans; either via<br>
custom Java classes, either static or dynamically generated ones. Mark<br> indicated that he leans towards a runtime bean generation for the<br> performance advantages that would entail. Clearly, performance is<br> important for many uses of Drools - particularly large rule bases in<br>
which facts are repeatedly inserted, updated, and retracted and in<br> which truth maintenance is performed.<br> <br> I'm however using Drools for tasks that are somewhat ad-hoc, but<br> nevertheless in my view are best expressed as rules. I collect some<br>
facts, throw them in working memory, fire all rules once, harvest the<br> results and discard the working memory. I do that repeatedly, but<br> during each iteration the structure of the facts inserted may change.<br> In such a scenario, any runtime generation would not pay off. You may<br>
say that a rule engine such as Drools is not appropriate for this<br> application, but I'd disagree - I find declarative rules the best way<br> to express the application logic I'd otherwise have to implement (I do<br>
use, for instance, insertLogical). In short, I'm using Drools not for<br> its performance in dealing with large rule bases and working memories,<br> but for the ease of expression and integration with the rest of the<br>
Java platform. Drools should support such ease of expression and<br> integration.<br> <br> - Godmar<br> <br><br> On Wed, Feb 20, 2008 at 8:35 PM, Edson Tirelli <<a href="mailto:tirelli@post.com">tirelli@post.com</a>> wrote:<br>
><br> > ... but was afraid to ask.<br> ><br> > Following up on our discussions here in the mailing list, I decided to<br> > write a blog throwing some light on this shadowy subject.<br> ><br> > <a href="http://blog.athico.com/2008/02/shadow-facts-what-you-always-wanted-to.html">http://blog.athico.com/2008/02/shadow-facts-what-you-always-wanted-to.html</a><br>
><br> > Hope things are a bit clear now. Let me know if you have suggestions,<br> > questions or (constructive) criticism. :)<br> ><br> > []s<br> > Edson<br> ><br> > --<br> > Edson Tirelli<br>
> JBoss Drools Core Development<br> > Office: +55 11 3529-6000<br> > Mobile: +55 11 9287-5646<br> > JBoss, a division of Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a><br> <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">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
><br> ><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">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</blockquote></div><br><br clear="all"><br>-- <br> Edson Tirelli<br> JBoss Drools Core Development<br> Office: +55 11 3529-6000<br> Mobile: +55 11 9287-5646<br> JBoss, a division of Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a>