Here is the quick answer, its xmas eve here :)
Drools can be used in Spring and we want to encourage as much spring
integration a possible. What is not practical is the current pojo side.
The reason being is that pojo's only support standard monolithic
<conditions>....</conditions> - this is the same as a jess testnode and
a jrules evaluate node. These are constraints that are not specific a
particularly fact; what we refer to as a column in the tuple, where the
tuple is really just a Fact[]. If we want to take Drools to the next
level we are going to have to move beyond this. It would be possible to
layer the existing spring pojo implementation on drools 3.0 but you
would basically be labotomising all the power of drools, someone is by
all means welcome to do this and we will add it to an unsupported
contributors area - but it is simply something that I don't want to have
to maintain and support in the main build.
So what do I mean by this?
AlphaNodes are constraints on fields for a specific fact. In rule
engines its encourages to build up your rules and constraints one fact
at a time - this maximises the amount of possible sharing. JoinNodes
must alwayss have a Column and its AlphaNodes feeding in to the right side.
This is a Column with two constraints
Person( name == "mark", partyLocation:location == "London" )
We can only place Not, Exist and OR at the head of Column constraints -
this also includes Accumualate and Forall which will be added in 3.1.
The reason for this is we need a right input to make these work; with
testnodes there is no right input it simply takes the results of a join.
Pupil( x:name, age == 15 )
Not ( Results( name == x, average < 50 ) )
Here we have two columns the first does a binding and the latter checks
none-existence using the binding to correctly constrain the cross products.
If this was a pojo we couldn't get the compact way of assigning bindings
and head conditional operators would not be possible.
So the approach now is to have the compiler compile down the drls to
real classes with src jars - so at least people can see and debug the
produced java classes.
Hope that makes sense.
Mark
Hamu, Dave wrote:
Mark & Drools Community:
I am interested in the question of using rules engines (Drools, in
particular, with frameworks such as the Spring Framework), which
Leonardo discussed in his e-mail (below). Can someone elaborate more
fully on the reason that Drools or other rules engines cannot be used
within the Spring framework. I understand that a key feature of Spring
is that it is a pojo framework and that it uses the "Hollywood
Principle". I have not had any hands-on experience with Spring, but
there are many aspects of the framework that I have gleaned from my
readings that make Spring very attractive to me.
I have long been critical of Struts, because it is needlessly complex
and unfortunately so heavily reliant on EJB's. In contrast, I favor the
concepts advocated by Rod Johnson which are exploited in Spring. I
realize that that this is a bit tangential from the Drools community's
focus, however, there is an inherent elegance in pairing a rules engine
with an application framework.
So, I would like to encourage some discussion on the following topics:
1) Practical approaches for using Drools with Application Frameworks
2) Problems with using Drools with Application Frameworks
3) Using Drools along with Workflow and/or BPM (some ideas about where
Drools is going as part of the JBOSS stack would be beneficial)
I am working with a very novel application framework concept that is an
original product within the team that I work with at Avnet. The
framework is a command-controller/front-controller framework based on
concepts published on sun.java.com. This framework has some interesting
features:
1) It is readily extended to invoke a rules engine on demand (we have
not exploited this yet, but we have some prototype code for this)
2) It is easy to implement workflow within the framework (and we have
exploited this to a limited extent)
The chief problem with our in-house designed framework is that it is not
an open-source product and not supported by vast number of developers
(just our team). On the one hand, it would be interesting to see our
framework adopted by a community of developers (although this may not be
practical), or alternately, it might be beneficial for us to replace the
our core framework with a framework that is widely supported in the Java
Community.
Thanks in advance for your thoughts on Drools and Application
Frameworks.
Happy Holidays!
- Dave
-----Original Message-----
From: Mark Proctor [mailto:[EMAIL PROTECTED]
Sent: Friday, December 23, 2005 7:25 PM
To: [email protected]
Subject: Re: [drools-user] setting application-data with spring drools
It is simply not possible to support the power of a rule engines in the
current pojo/spring approach. Drools 2.5 now compiles rules down to
pojos, it is possible to reference these pojo's interfaces and unit test
those - we produce the a src jar for these rules so you can also debug
them.
Mark
Leonardo Susatyo wrote:
Is it true that Spring for Drools will not be supported in the future?
If so, what will be the alternative b/c i kind of like the spring
approach for easier unit testing
thanks
--- Geoffrey Wiseman <[EMAIL PROTECTED]>
wrote:
On 12/20/05, Leonardo Susatyo <[EMAIL PROTECTED]>
wrote:
Could anyone please tell me how can I define application-data in
rulebase if i'm using drools-spring?
My knowledge in this area is pretty dated; when we last tried to do
that, we were on 2.0, possibly not even final, and we couldn't do it;
application data didn't seem to be working with annotated rules, and
it was suggested that injection of rules via Spring was a preferred
route for this approach; we ended up moving to that, althogh there
are instances where this is not very well suited.
For instance, if your rules are meant to be parameterized by a
processing data, this is something that can be passed in on a
per-invocation basis with Application Data but cannot easily be
injected.
I can't speak to whether or not this has been resolved, and I should
point out (before Mark does) that Spring/Drools is deprecated in the
Drools 3.0line, so that's something to consider.
ps: i saw a defect DROOLS 322, is it related?
Codehaus Jira is down, or at least not responding to my attempts to
access it at the moment, so I can't say.
--
Geoffrey Wiseman
__________________________________________
Yahoo! DSL -- Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
