On the other side, spring would be a fine way of wiring up an application to the drools engine. This really has nothing to do with the POJO rule module though.
You can use spring to inject a RuleBase into you spring managed beans, or even a working memory, depending on your needs. No specific support is required in Drools to do this of course. On 12/25/05, Mark Proctor <[EMAIL PROTECTED]> wrote: > > 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 > >> > >> > >> > >> > >> > > > > > > > > >
