Re: [rules-users] Declarative fact model or Java?

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(a)tsys.com Γ€: "Rules Users List" <rules-users(a)lists.jboss.org&gt; Cc: rules-users-bounces(a)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(a)gmail.com&gt; To: Rules Users List <rules-users(a)lists.jboss.org&gt; Date: 01/20/2012 06:36 AM Subject: Re: [rules-users] Declarative fact model or Java? Sent by: rules-users-bounces(a)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(a)me.com&gt; 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(a)me.com > > > On Jan 20, 2012, at 11:44 AM, Davide Sottara <dsotty(a)gmail.com&gt; 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-J... > Sent from the Drools: User forum mailing list archive at Nabble.com. > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing list rules-users(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users