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(a)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/t...
> >
> > 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/t...
> >
> > 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(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users
>
--
Ronald Brindl
Sr. Software Developer
Member of Architecture Team
The Goldensource Corporation