[rules-users] Declarative fact model or Java?

Fri Jan 20 14:34:35 EST 2012

Apart from these considerations, you may also need to take into account
performance and memory differences between the two approaches.

In my Drools.5.0.1 project, I was tempted by declarative facts at first,
until I found out that at runtime you need approximately 3 times the
memory and you incur a significant performance penalty. I have to clarify
though, that even with declarative facts performance was/is in the order
of ms (milliseconds), so this issue may not carry much weight.

-Stathis

Vincent LEGENDRE wrote:
> With Guvnor, you can also use "working set" (see here ) to restrict the
> availiable fields to expose to a business user, by selecting class and/or
> fields of an existing class, and even more (businnes contraints on values,
> with rules).
>
> The only problem I see with working sets, is that you must explicitely set
> the working set to use when you create your rule (not very natural for a
> business user).
> So, if one create a new rule from Guvnor, he can access the whole object
> model. The fact model filtering is not enabled until a working set is
> associated.
>
> May be one day, for a package or a category (or a user as said in the doc
> for future devs), we will be able to set a default working set, so that
> all rule of this package will automatically associated with filterered
> model.
> But it could be a good solution for you, avoiding complex proxies,
> factories and so on ...
>
> ----- Mail original -----
>
> De: GPatel at tsys.com
> Γ€: "Rules Users List" <rules-users at lists.jboss.org>
> Cc: rules-users-bounces at lists.jboss.org
> EnvoyΓ©: Vendredi 20 Janvier 2012 18:59:02
> Objet: Re: [rules-users] Declarative fact model or Java?
>
> If you are starting from scratch, this is possible. However, I find myself
> having to expose operations from the *preexisting* technical domain into
> the business (i.e expose methods from existing technical domain code that
> has all kinds of annotations and code references to 3rd party software).
> The only way out, in that case, is to have your own separate business
> domain classes that wrap around (proxy) the existing technical domain
>
>
>
> From: Wolfgang Laun <wolfgang.laun at gmail.com>
> To: Rules Users List <rules-users at lists.jboss.org>
> Date: 01/20/2012 06:36 AM
> Subject: Re: [rules-users] Declarative fact model or Java?
> Sent by: rules-users-bounces at lists.jboss.org
>
>
>
>
> Let me mention that I've used Java classes derived from XML Schema
> as facts.
>
> If there are technical properties you'd like to hide from the rule
> programmer,
> define a "business" type and extend it with the technical properties. The
> rule programmer must make do with the "business" type, which is
> possible even if the object (fact) type is the "technical" subclass.
>
> -W
>
>
> On 20/01/2012, Stephen Masters <stephen.masters at me.com> wrote:
>> 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
>>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
> ----------------------------------------- The information contained in
> this communication (including any attachments hereto) is confidential and
> is intended solely for the personal and confidential use of the individual
> or entity to whom it is addressed. If the reader of this message is not
> the intended recipient or an agent responsible for delivering it to the
> intended recipient, you are hereby notified that you have received this
> communication in error and that any review, dissemination, copying, or
> unauthorized use of this information, or the taking of any action in
> reliance on the contents of this information is strictly prohibited. If
> you have received this communication in error, please notify us
> immediately by e-mail, and delete the original message. Thank you
> _______________________________________________
> 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
>