[rules-users] Re: Re: Defining facts declaratively with TypeDeclaration and assert facts from java

Ronald Brindl rbrindl at thegoldensource.com
Tue Feb 10 02:55:20 EST 2009 

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 <rbrindl at thegoldensource.com>
> 
>> 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 <rbrindl at thegoldensource.com>
>> >
>> >> 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
>> >> rules-users at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/rules-users
>> >>
>> >
>> >
>> >
>>
>> --
>> Ronald Brindl
>> Sr. Software Developer
>> Member of Architecture Team
>> The Goldensource Corporation
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
> 
> 
> 

-- 
Ronald Brindl
Sr. Software Developer
Member of Architecture Team
The Goldensource Corporation

More information about the rules-users mailing list