Thanks Sujit. All we need are some screen shots in action and we can put it up as an article !
Looks good. I can see you have implemented to the SPI, which is fine as it gives you maximum dynamic ness, and is a valid approach, especially for python which is always interpreted. If people are interested, we can put it on the drools site as a possibly utility when working with Drools 2 rulebases and python. On 12/29/05, Sujit Pal <[EMAIL PROTECTED]> wrote: > > Hi, > > Thanks for the interest. The code is temporarily available for download > here (I need the space for some future plans, future == couple weeks > :-)). If you think its worthwhile, maybe it can find a permanent home on > the Drools site. And if you do decide to use this as a base for a future > Drools API, please feel free. > > http://home.comcast.net/~sujit.pal/pluto.tar.gz > > There is a dbi-doc.txt in wiki format which explains the design, along > with 2 .png files detailing the class diagram and schema design. > > You can build the database using the file generated using ant schema. > There are 2 .sql files for the schema, one for postgresql and the other > for mysql. > > You can run the junit tests for the API using: > ant clean compile compile-test test > > The web application is designed with resin, but it should work for other > application servers too. You may need to tweak the deploy target to tell > it the correct location of your application server. > > Comments to some of the posts: > Michael Neale> We want to store rules atomically, and add in things like > versioning, access control and so on. Of course, it needs to be generic. > We need a rule repository API, and then tools that use it (ie the web > interface can be a component that people can use, or they can use the > API directly to store rules). > sujit> The project provides an API, although it is not as comprehensive > as you expected in your email. For example, version control and access > control is not covered, although it should be fairly easy to add in. > However, there are facilities to list all rulesets in the database, load > a ruleset by name, save/update a ruleset and clone rulesets. The web > interface uses the same API. > > Paul Smith> To have the added flexibility to modify to rules without a > redeploy would be a big advantage. Not sure how you would source > control the rule bases if they are all stored in a database but I > certainly like the idea. > sujit> Yes, not having to redeploy was one of the considerations. > Although, looking back on it, I ended up re-inventing some wheels > already done by the Drools team. Perhaps a better way to do this would > be to marry the two, ie use the database to store the data, then > generate a .drl file on demand and run it through the provided Drools API. > > I am also looking for feedback on what you think I've done wrong, or > stuff you think I could have done better. > > Thanks > -sujit > > Michael Neale wrote: > > We want to release a rule repository API with the Drools 3.0 version. > > > > This is something that could be contributed towards that if you are > happy to > > ! > > > > The idea is to have a foundation API, which provides all repository > > functionality, including versioning, searching, checkin/out etc, which > can > > be used to deploy rules into running systems. A web based user interface > is > > one front end to this API, as will be any plug ins - or custom > applications > > for people with special needs for their environment. It sounds like you > are > > a lot of the way there. > > > > I was initially trying the Java Content Repository API, but decided it > will > > be easier to use hibernate directly - out of the box we can include > HSQLDB > > (so people can get up and running without a seperate database server) > but of > > course MySQL, Oracle and SQL Server, DB etc can be supported thanks to > > hibernate. > > > > Please do share it ! > > > > > > Michael > > JBoss Inc. > > > > > > On 12/28/05, Paul Smith <[EMAIL PROTECTED]> wrote: > > > >>Yes, I'd certainly be interested in taking a look too. I'm keen to do > >>some proof of concept work in the near future using drools in our EAM > >>system. To have the added flexibility to modify to rules without a > >>redeploy would be a big advantage. Not sure how you would source > >>control the rule bases if they are all stored in a database but I > >>certainly like the idea. > >> > >>On 12/28/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> > >>>I'd definately be interested in looking at your code. > >>> > >>>Scott > >>> > >>>-----Original Message----- > >>>From: Sujit Pal <[EMAIL PROTECTED]> > >>>To: user@drools.codehaus.org > >>>Sent: Tue, 27 Dec 2005 09:16:40 -0800 > >>>Subject: Re: [drools-user] setting application-data with spring drools > >>> > >>> > >>>Hi, > >>> > >>>I've just finished building a small proof-of-concept that uses a > >> > >>database to store rules and provides a simplified interface to the > Drools > >>engine to the client. The client calls named rulesets using the > interface > >>and the rules are loaded from the database. > >> > >>>There is also a web interface to maintain the rules. The rulesets are > >> > >>stored atomically, ie as normalized data instead of as a .drl file (CLOB > >>data). The web interface is built using Spring MVC. The database object > >>abstraction is built using Hibernate. The body of the conditions and > >>consequences are scriptable using Python or extendable using small Java > >>classes. I did the Petstore example using both approaches to illustrate > the > >>usage. > >> > >>>If there is interest in this sort of thing, please let me know. I would > >> > >>be happy to write up this stuff with the code, perhaps in the user > stories > >>section of the drools site. > >> > >>>Thanks > >>>Sujit > >>> > >>>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: user@drools.codehaus.org > >>>>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 > >> > >>>>> > >>>>> > > >>>________________________________________________________________________ > >>>Check Out the new free AIM(R) Mail -- 2 GB of storage and > >> > >>industry-leading spam and email virus protection. > >> > >>> > > >
