[rules-users] Declarative fact model or Java?

[Stephen Masters]

Hi Davide,

Thanks for your thoughts. The application is just a service which takes an XML request, converts that into a fact and inserts that into the working memory. Based on rule evaluations, it responds to the client with more XML indicating whether the requested action is permitted.

On of the key aims of the project is to enable management of some rules by 'the business' through Guvnor. The current 1-1 mapping you mention is partly what put me off using Java models, as it leads to 'technical' attributes being present in the Guvnor fact model, which are not relevant to the business. The more I can keep the fact model within Guvnor minimal, the better.

So following your logic, given that:
There is no legacy model to deal with.
~80% of what is going on will be within Drools, with the Java code just to insert/update facts and marshal XML.
I would really like to avoid a 1-1 mapping of Java classes to DRL facts.
... I think I'll stick with DRL facts.

Given that I'm not too sure exactly what I want out of it yet, I'm not sure how much I could contribute to a spec, but I'd be happy to help out with things. If only by testing out early code and providing feedback. If there's anything you think I might be able to help out with, feel free to ping me an email.

Many thanks,

Steve
stephen.masters at me.com


On Jan 20, 2012, at 11:44 AM, Davide Sottara <dsotty at gmail.com> wrote:

Hi Steve, 
let me share my thoughts on this. 

You will probably want to use a Java model when it's already available :) Or
when you're using the rule engine to implement the business logic layer of
your application, processing data coming from an external source.

A DRL model, instead, is definitely recommended for "temporary" facts, or
data structures which are used by the rules to do their computations. 
The main problem with DRL fact classes is that they're quite cumbersome to
use outside the rule engine. On the other hand, you will be sure that the
declared types will correspond to an implementation fully compatible and
optimized for the rule engine.

Very roughly : if the rule engine is a component in a larger architecture,
use java classes. If you're building a rule-based application - i.e. DRL is
your programming language and Drools is your execution environment, go for
DRL.

As for mapping, we have added this very experimental feature lately:

http://blog.athico.com/2011/12/new-feature-spotlight-traits-part-1.html
http://blog.athico.com/2011/12/dynamic-typing-in-rules-traits-part-2.html

I have plans to use annotations to improve the mapping, avoiding the 1-1
correspondence between fields, so if you want to contribute, if only to the
specifications, let us know :)

Best
Davide

--
View this message in context: http://drools.46999.n3.nabble.com/rules-users-Declarative-fact-model-or-Java-tp3675001p3675181.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
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/20120120/d567f94c/attachment.html