3:51 a.m.
Hi folks,
I quite like the clean separation provided by maintaining a declarative fact model rather
than a Java model. In particular to me, it seems to make it easier to manage rules in
Guvnor separate from my runtime environment. However I can also see how maintaining a Java
model simplifies some activities, avoiding having to map between and external Java model
and an internal representation, and making it easy to modify facts from within a knowledge
session.
Is there anybody out there who has experience doing a number of projects both ways, and
has developed an opinion on whether one is preferable the other? Or is there perhaps more
of a decision tree pertaining to which is better in particular situations?
And on a side-note, is there anything out there that helps with mapping between Java beans
and declarative facts? I was wondering about hacking up some AOP aspects to enable me to
annotate a Java model in a slightly JPA/ORM style to help with mapping/marshalling between
the two.
Thanks for any thoughts.
Steve
stephen.masters(a)me.com
5:43 a.m.
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.
6:16 a.m.
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> 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
7:35 a.m.
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> 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> 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
11:59 a.m.
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>
To: Rules Users List <rules-users(a)lists.jboss.org>
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> 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> 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
12:26 p.m.
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>
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>
To: Rules Users List <rules-users(a)lists.jboss.org>
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> 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> 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
1:34 p.m.
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(a)tsys.com
Γ: "Rules Users List" <rules-users(a)lists.jboss.org>
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>
To: Rules Users List <rules-users(a)lists.jboss.org>
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> 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> 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
12:18 p.m.
In alternative, if you want total decoupling, you can define /interfaces/
that your classes extend, and write the rules against the interfaces, rather
than the classes. This might help when you have different formats and
improves the portability of your rule base.
The classes would have to implement interfaces statically, so it can be done
conveniently if you need to create your fact classes anyway. The drawback is
that you can't to that so easily if you don't have access to the source
code. We provided "traits" to add interfaces (a) to individual instances
rather than whole classes, or (b) to attach an interface to a class which
does not implement it.
One bit which is missing, now that I realize, is the possibility to have
declared classes implement DECLARED*** interfaces statically (anyone willing
to open a JIRA request? I'm feeling lazy right now :) )
D.
[Beware: arguable and debatable content below:]
Remark : In a perfect world, the rules should just process "logical facts",
i.e. data stored within pure beans. Behavior (methods) other
assertions/retractions/updates should be provided in a controlled way,
either using different, dedicated facts or globals. If this level of
"purity" can be attained, among other things, debugging and rule analysis
becomes much more feasible.
--
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.
4694
days inactive
4694
days old
7 comments
6 participants
participants (6)
-
Davide Sottara -
GPatel＠tsys.com -
rouvas＠mm.di.uoa.gr -
Stephen Masters -
Vincent LEGENDRE -
Wolfgang Laun