Thank you for your insight! Now everything is a bit clearer! I will keep you up to date once we implement things (which is not decided yet at all, we are just evaluating, and i am afraid, we will not find enough use cases to advocate a rule engine for the next release. However, there will ever be a release after that, and people will become more familiar with the concepts of rule engines...) In the meantime i will keep exploring things and try to get smarter. ;)
Thanks a lot, ron. Edson Tirelli wrote: > Ronald, > > I guess the problem is on the definition of: "access to the generated > classes"... :) it is possible to have access to the class instance (public > API) and to the generated bytecode (internal API, maybe require some > hacking). But it seems to me that you want a tighter integration: > > "I also still have the problem, that there SHOULD be the possibility to > intercept attribute access to the facts, to make lazy loading of > attributes from the database possible." > > This is an old dream I have: to enable Drools to process different > formats of facts directly without mapping them into a javabean model > before insertion into the working memory. This is possible from a LHS > perspective (requires someone to implement the format providers), but we > never did it because of the implications on the RHS. It is easier to > understand this if we see an example. Just for simplicity, lets think > about an XML entity: > > <person name="Bob" age="40"> > <address>999 Some Street</address> > </person> > > Drools has abstractions that allow the engine to reason over any format > of data. It is composed of 2 parts: ObjectType interface + FieldAccessor > interface. Using specific implementations that know how to interpret an > XML entity as a fact object type (lets say XMLObjectType) and how to read > fields from it (XMLFieldAccessor), one could write rules like: > > when > Person( name == "Bob", age > 30 ) > then > // RHS: do something > end > > Does not matter if Person in the above example is an XML document, a > javabean, a template, etc. This works with the current architecture, we > just don't have the XML* implementations. > > The problem is in the RHS. The RHS is a java or MVEL code block. As it > is > today, it is a gray box for the engine. We parse things in there, we > extract information, we do some minor rewritings, but that is all. Now > imagine that in the above rule, the user wants to change the address of > the user. How would you do that? Expose some XML API to it? in this case, > the rule would not be independent of format anymore and we would lose most > of the value in such flexibility. Add support to some kind of code > injection using AOP? Create an unifying model?! > > It may be feasible, but not simple and will require quite some work. > Since we have a lot on our plates already, we prioritized other things up > to now. > > What you want to do, it seems to me, that is related to that, where > the > engine would access your database tables on-demand and read/write fields, > or in a simpler case, would use your maps/lists-based model directly > (easier). > > In any case, if you don't want to go down this route, that will > require > quite some work but we would be happy to help in case you want, the > simpler solution is as you already realized, to generate your model as a > set of interfaces and have your implementations do the magic behind the > scenes. In this case, you users would write their rules against the > interfaces and everything would work, but the interface generation would > have to be built as a batch, compile time process on your side. I don't > think you can tweak type declarations to do that. > > I am interested to know how you progress on this, so keep us posted > plz... :) > > Cheers, > Edson > > 2009/2/9 Ronald Brindl <[email protected]> > >> Thank you! >> >> I already saw that piece of documentation (i am looking at trunk), and >> that was what lead me into that direction. >> However, is there some possibility to get access to the generated >> classes? I >> mean, our application (and the domain model classes) is potentially >> distributed among several JVM's. So what i am looking for is that the DRL >> declarations are generated in our application during startup, then they >> are deployed to guvnor to allow business user use the facts, and then >> have the generated classes at the application side again, to feed the >> facts. Is this possible somehow, or am i going in the wrong direction? >> >> I also still have the problem, that there SHOULD be the possibility to >> intercept attribute access to the facts, to make lazy loading of >> attributes from the database possible. >> So maybe the better solution is to generate interfaces, give them to >> guvnor and implement the access logic to incoming messages and existing >> messages in the db with a proxy. >> I dont want to go via XML in any way if i can avoid it... >> >> However, i will have a look at the spots you pointed out and see, what i >> find there... >> >> Thank you, >> ron. >> >> Edson Tirelli wrote: >> >> > Ronald, >> > >> > Last week I wrote the docs for TypeDeclaration. So, you may try the >> > docs >> > first hand and provide me feedback! ;) >> > >> > >> >> https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/docs/drools-expert/html/ch06.html#d0e3047 >> > >> > The API was promoted from drools-core to drools-api after M5 was >> > released, so you need trunk to use it. >> > >> > >> >> https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/ >> > >> > Regarding your questions, I believe this is probably the easiest way >> of >> > doing it, but not the only one. Just to mention another way would be to >> > generate a JAXB domain model from your database and upload it as a jar >> > to Guvnor. >> > >> > If you want to dive into Drools internals and see how the classes >> > are >> > generated, take a look at org.drools.factmodel.ClassDefinition in >> > drools-core as your starting point. From there you can navigate through >> > the code searching for the references. IMO though, you don't need to go >> > down this route. >> > >> > Regarding the pipeline, if you want to customize it for your needs, >> you >> > just need to create an intermediate step or use smooks to map from one >> > model into the other. I think mark did not added a step to map from an >> > external model into a type declared model yet. Contributions welcome. >> > >> > Hope this helps, >> > Edson >> > >> > >> > >> > 2009/2/6 Ronald Brindl <[email protected]> >> > >> >> Referring to threads >> >> http://thread.gmane.org/gmane.comp.java.drools.devel/2860 >> >> Dynamic Facts: how to get jar wih Facts declared in drl >> >> http://thread.gmane.org/gmane.comp.java.drools.devel/2595 >> >> TypeDeclaration plugin heirarchy >> >> >> >> I am just in the process of evaluating the possibilities of using >> Drools. >> >> >> >> Our use case is the following: >> >> We have a dynamic metamodel, which gets generated from database during >> >> application initialisation phase. Then a runtime model gets >> >> instantiated, which is fed from incoming messages (files, jms, etc.) >> >> Both models are highly generic, basically maps of maps (lists of >> >> lists, for model instances) >> >> >> >> Now, i would like to publish the metamodel to Guvnor as fact model, so >> >> that business rules users can use it there and define >> >> >> >> In the last 2 days i dived into the sources, read the mailing list >> >> entries above, documentation and so on, but i still don't have a clear >> >> vision on how to accomplish that. >> >> >> >> Our first approach was to use TypeDeclaration, i.e. to dynamically >> create >> >> DRL that defines the fact types as defined in our metamodel, but i >> >> don't have a clue on how to assert data for those types, since i don't >> >> have >> the >> >> resulting java classes available in Java. >> >> (There was also some confusion: in the documentation (M5) it says, >> >> bytecode is generated for declaratively defined Facts, but i could not >> >> find anything in the code, where this byte code is generated) >> >> >> >> Our next approach was to generate interfaces as Fact types and create >> >> proxies to access the data. This would also allow us to implement >> another >> >> use case, that demands access to messages already stored in the >> >> database with the same id as the incoming messages, and compare what >> >> fields are new and to provide merging of new and old data. >> >> >> >> I also had a quick look at the new Pipeline concept, but as far as i >> >> understand that, it builds on a statically defined FactModel. >> >> >> >> Then i dived a little bit more into the code and saw code generation >> >> for accessing Java class facts, which also might be a reasonable >> >> solution >> for >> >> us. >> >> >> >> However, what i was asking myself was, if there is some entry point >> >> for functionality like that, some existing API. >> >> >> >> Thank you, >> >> ron. >> >> >> >> >> >> -- >> >> Ronald Brindl >> >> Sr. Software Developer >> >> Member of Architecture Team >> >> The Goldensource Corporation >> >> >> >> _______________________________________________ >> >> rules-users mailing list >> >> [email protected] >> >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> > >> > >> > >> >> -- >> Ronald Brindl >> Sr. Software Developer >> Member of Architecture Team >> The Goldensource Corporation >> >> _______________________________________________ >> rules-users mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-users >> > > > -- Ronald Brindl Sr. Software Developer Member of Architecture Team The Goldensource Corporation _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
