[rules-dev] Determining if a class is an event or not
Edson Tirelli
tirelli at post.com
Fri Nov 9 06:49:11 EST 2007
Michael,
No, it is good to "speak loud" about the problem so I can think more
about it while doing it. :)
The problem is related to class inheritance. At compile time we know that
a.b.c.Foo is an event and we create an ClassObjectTypeConf for it, that says
it is an event. At runtime, though, the user can insert instances (facts) of
absolutely any class in the working memory... even classes for which there
are no rules for. So, at runtime, when a fact of a class that was never seen
before is inserted into working memory, we need to create a
ClassObjectTypeConf for it, where we do a series of analysis (for instance,
at this time we decide if a shadow proxy is needed for it or not), and at
this time, we need to determine if this fact of a new "unknown" class (lets
say x.y.z.Bar) is an event or not (i.e, is it a subclass of a.b.c.Foo?).
So, back to my original e-mail, I can do that hierarchy analysis to
transparently determine that, but it is a costly operation. The other
alternative is assume that the user is explicit naming all event classes,
but that will not work for automatically generated classes (like when using
some XML binding frameworks). The last alternative is what your suggested of
having a specific API for that, but wouldn't we need to create a checking
algorithm anyway to prevent users mistakes?
So, that is the dillemma... :)
[]s
Edson
2007/11/9, Anstis, Michael (M.) <manstis1 at ford.com>:
>
> Hi Edson,
>
> Sorry if I'm causing more pain and grief than you ever intended your
> original posting to cause.
>
> Now I understand (more) the use case for Events I can better appreciate
> your original dilemma. If you need the information to optimise the RETE
> network at compile-time why do you need to perform the check when a Fact is
> inserted; couldn't you have a new ObjectTypeNode that is specific to Event
> classes? If my lack of knowledge is more of a hindrance let me know and I'll
> revert to being a passive observer.
>
> Cheers,
>
> Mike
>
> ------------------------------
> *From:* rules-dev-bounces at lists.jboss.org [mailto:
> rules-dev-bounces at lists.jboss.org] *On Behalf Of *Edson Tirelli
> *Sent:* 08 November 2007 15:50
> *To:* Rules Dev List
> *Subject:* Re: [rules-dev] Determining if a class is an event or not
>
>
> Michael,
>
> The engine *must* know, at rulebase compile time, what classes
> represent events. When I say it is for optimization purposes, is because
> events are "light-weight" facts with special characteristics, but that occur
> in huge volumes, and so, the engine will never scale without knowing they
> are events. The way we can make the engine aware that a given class is an
> event may vary:
>
> * we can use some "declaration statement" in the DRL like the ones I
> described
> * we can make the classes implement a markup-interface like Matthias was
> suggesting
> * we can use keywords, like iLog uses, writing "event" in every pattern
> that represents an event
>
> Besides what I commented in a previous e-mail regarding the markup
> interfaces, having the declaration statement in the DRL has an additional
> benefit of making clear to third-parties reading the rules that those are
> event classes (that carry special characteristics).
>
> The idea here is to discuss exactly the benefits and disadvantages of
> each approach. :)
>
> []s
> Edson
>
> 2007/11/8, Anstis, Michael (M.) < manstis1 at ford.com>:
> >
> > I can turn that question around...
> >
> > If the user has written objects MyFact and MyEvent is it fair to expect
> > them to have to declare it in the DRL?
> >
> > I don't know what Events are to do in Drools so don't which is the more
> > reasonable approach. Is it just for network optimisation as you say, or will
> > Drools be calling into members?
> >
> > This is much more interesting than (my) work ;-)
> >
> > ------------------------------
> > *From:* rules-dev-bounces at lists.jboss.org [mailto:
> > rules-dev-bounces at lists.jboss.org] *On Behalf Of *Edson Tirelli
> > *Sent:* 08 November 2007 14:54
> > *To:* Rules Dev List
> > *Subject:* Re: [rules-dev] Determining if a class is an event or not
> >
> >
> > Michael,
> >
> > Yes, the session.insertEvent() API is something other engines (like
> > iLog JRules) have. I initially discarded that idea, but since you mentioned,
> > we may need to reconsider it.
> > Anyway, the API would solve this part of the problem, but the whole
> > scenario is:
> > The engine must know at the compile time exactly what
> > classes/interfaces used in rules are events, so that it can optimize the
> > network. That is achievable by using any of the syntaxes bellow (I'm not
> > sure which one to use yet):
> >
> > import event a.b.c.Foo; (or)
> > import event a.b.c.*;
> >
> > or explicit saying:
> >
> > declare event a.b.c.Foo;
> >
> > Once the user declared that something is an event, do you think it
> > is fair/acceptable to force the user to use a different API to insert events
> > into the engine?
> >
> > session.insert(); for regular facts
> > session.insertEvent(); for events
> >
> > []s
> > Edson
> >
> > 2007/11/8, Anstis, Michael (M.) <manstis1 at ford.com >:
> > >
> > > Here's my 2 cents - as a non-contributor to Drools codebase ;-)
> > >
> > > You could add insertEventFactTypeThingie to the API? Then you need
> > > just
> > > check that the class has been declared as an event in the DRL similar
> > > to
> > > what must already happen for normal DRL imports. I personally don't
> > > have
> > > issue with implementing a marker interface (this is what frameworks
> > > like
> > > Hibernate, EJB3 and Spring etc have been imposing for years). What
> > > "wiring"
> > > does the POJO need to become an Event for use in Drools? Are you
> > > trying to
> > > internalise too much at the risk of making the event mechanism
> > > inflexible?
> > >
> > > Cheers,
> > >
> > > Mike
> > >
> > > -----Original Message-----
> > > From: rules-dev-bounces at lists.jboss.org
> > > [mailto: rules-dev-bounces at lists.jboss.org] On Behalf Of Matthias
> > > Sent: 08 November 2007 13:09
> > > To: rules-dev at lists.jboss.org
> > > Subject: Re: [rules-dev] Determining if a class is an event or not
> > >
> > > Edson Tirelli <tirelli <at> post.com> writes:
> > >
> > > >
> > > >
> > > > All, I reached a point where I need to make a design decision
> > > and
> > > would
> > > like your opinion about it. Imagine the following scenario: A user
> > > has a
> > > domain model like this:package a.b.c
> > > > ;public interface Event { ... }package x.y.z;public class MyEvent
> > > implements
> > > a.b.c.Event {...} Then, in his DRL file he writes:package p.q.r
> > > ;import
> > > event
> > > a.b.c.* ; rule Xwhen
> > > > Event( ... )then ...end So, it is clear that a.b.c.Eventshould
> > > be
> > > handled as an event by the engine. At runtime, the user asserts an
> > > object
> > > of
> > > the class x.y.z.MyEvent into the working memory. Seems clear to me
> > > (and
> > > probably
> > > to the user) that MyEvent should be handled as an event, since by DRL
> > > semantics,
> > > > a.b.c.* are all events, and by OO class hierarchy concept, since
> > > a.b.c.Event
> > > is an event, x.y.z.MyEvent is an event too. My question is: how the
> > > engine
> > > knows that MyEvent is an event, since it only has the x.y.z.MyEvent
> > > > class as input? The only answer I have is that when the first
> > > MyEvent
> > > instance is asserted into the working memory, we must get the class
> > > name and
> > > iterate over all event import declarations checking for a match. In
> > > case no
> > > one
> > > is found, we need to repeat the process for each interface and each
> > > class up
> > > in
> > > the MyEvent hierarchy. Once this process is complete, we cache the
> > > results
> > > in
> > > the ObjectTypeConf.
> > > > This may be a quite heavy process to be executed each time a fact
> > > of a
> > > different class is asserted in the working memory for the first time,
> > > but I
> > > can't think a different user-friendly way to solve the question.
> > > > The alternatives would be intrusive, IMO, breaking the drools
> > > premise
> > > to
> > > work with user-defined POJOs as facts: use anotations to annotate
> > > classes
> > > that
> > > are events, or mandate users implement a specific interface for
> > > events.
> > > > Any better idea? []s Edson -- Edson Tirelli Software
> > > Engineer
> > > - JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11
> > > 9287-5646
> > > > JBoss, a division of Red Hat <at> www.jboss.com
> > > >
> > > >
> > > > _______________________________________________
> > > > rules-dev mailing list
> > > > rules-dev <at> lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-dev
> > > >
> > >
> > >
> > > Edson,
> > >
> > > I got your striving not to mandate users implement a specific
> > > interface for
> > > events. However, why not at least introducing an empty event interface
> > > (i.e.
> > > a
> > > marker interface, similar to the Serializable interface in Java) the
> > > user-defined event class(es) have to implement? This way, when
> > > inserting a
> > > MyEvent instance, you can simply check whether it implements the event
> > > interface
> > > (by means of 'instanceof'). Moreover, while parsing the import
> > > statements of
> > > a
> > > rule file, it enables you to double-check whether all the "event
> > > imports"
> > > really
> > > refer to classes implementing the (empty) event interface.
> > > In this regard, for me another question raises: Without making any
> > > restrictions
> > > on the structure for a user defined event class, how do you make sure
> > > it has
> > > all
> > > the required attributes of an event (which in my opinion must be a
> > > timestamp,
> > > at least) and how do you access them (necessary for temporal
> > > relationships)?
> > > Having said this, in my opinion defining an empty event interface may
> > > not be
> > > sufficient; in addition, it must force the user to implement a method
> > > returning
> > > the event's occurrence date (i.e. the timestamp) at least... Or how
> > > would
> > > you
> > > handle this issue?
> > >
> > > Matthias
> > >
> > > _______________________________________________
> > > rules-dev mailing list
> > > rules-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-dev
> > >
> > > _______________________________________________
> > > rules-dev mailing list
> > > rules-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-dev
> > >
> > >
> > >
> >
> >
> > --
> > Edson Tirelli
> > Software Engineer - JBoss Rules Core Developer
> > Office: +55 11 3529-6000
> > Mobile: +55 11 9287-5646
> > JBoss, a division of Red Hat @ www.jboss.com
> >
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> >
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3529-6000
> Mobile: +55 11 9287-5646
> JBoss, a division of Red Hat @ www.jboss.com
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20071109/8cc35a4f/attachment.html
More information about the rules-dev
mailing list