[rules-dev] Determining if a class is an event or not
Edson Tirelli
tirelli at post.com
Tue Nov 13 16:18:24 EST 2007
Mike,
Good question.
Since I'm playing "devil's advocate" here, imagine the scenario:
* There is an event stream that the user wants to process with our engine.
The stream has events of types (classes) A, B and C, all of them from
package x.y.z. So, the user writes in the DRL:
import events x.y.z.*;
Although, at this time, the user is only interested in events of type A, and
so only writes rules for event type A. So, the engine will only create (at
rulebase compile time) ObjectTypeNodes for class A. Since one of the jobs of
an ESP engine is to select only the events the user is interested in, the
engine must discard events B and C. But a rules engine, only automatically
discards events, not facts, and as so, the engine must know that B and C are
events and the user is not interested in them, but using existing
ObjectTypes to determine if B and C are events, will not help in this case.
So, with regular facts, Drools does exactly what you said, but with
events, an additional verification must be made to determine at runtime if a
given class is an event class or not. That is the difference we are looking
a solution for.
Edson
2007/11/13, Anstis, Michael (M.) <manstis1 at ford.com>:
>
> Option (3) fits in best with the current way Drools exposes itself to
> users (we don't need to implement an interface for regular facts, or shadow
> facts) but would like to understand how it differs to the insertion of
> regular facts: a user imports a class but can insert a sub-class, so it
> appears this would need to perform the same type of inheritance check as
> Edson is proposing for (3) to ensure the correct ObjectTypeNode is
> selected... it could well be that (3) is no different to how regular facts
> are propagated through the network.
>
> ------------------------------
> *From:* rules-dev-bounces at lists.jboss.org [mailto:
> rules-dev-bounces at lists.jboss.org] *On Behalf Of *Edson Tirelli
> *Sent:* 12 November 2007 19:25
> *To:* Rules Dev List
> *Subject:* Re: [rules-dev] Determining if a class is an event or not
>
>
> Felipe,
>
> I see your point and maybe you are right. I will do some more research
> till tomorrow and then start implementing that. Let's see how much overhead
> solution 3 adds and if it is worth to have options 1 and/or 2.
> Just to make it clear, we are talking about use cases where the rules
> USE events, i.e., CEP/ESP use cases. All these must have NO impact on
> rulebases that do not use events, as it is today.
>
> CEP/ESP support and Temporal Reasoning are a set of features we are
> working on for the next major release. It is in early design/implementation
> phases now and we have no docs yet.
> Anyone interested in that is more than welcome to join discussions
> like the one in this thread, contribute ideas, code and docs. We are an open
> source product after all... :)
>
> Regards,
> Edson
>
> 2007/11/12, Felipe Piccolini <felipe.piccolini at bluesoft.cl>:
> >
> > Edson,
> > As I see it,
> >
> > Solutions (1) and (2) lend the responsabilitie of knowing what they
> > are doing on developers, and can be tricky...but at the end could be
> > an optimal solution...so they should exists.. solution (3) makes all the
> > work clean and easy, but can introduce over load work, so for first
> > instance I'll set up solution (3) so an advanced developer coul
> > deactivated by developer with some config API, so they could make their
> > application work faster if they know what they are doing...
> >
> > OF course i dont like to break the POJO paradigm on drools, is one of
> > the things make drools THE choice... but introduce extra check to
> > add a feature that maybe not all devs will use is something that an
> > advanced dev should decide...
> >
> > my 2 cents..
> >
> > :)
> >
> > btw: Im a little lost on this event feature (last moths Iv been working
> > on other things) so, where can I read about this event handle?..is a new
> > feature from 4.0.2?...is on the docs? Thx.
> >
> >
> > On 12-11-2007, at 13:54, Edson Tirelli wrote:
> >
> >
> > Mike, Felipe and Matthias,
> >
> > Thank you for all your feedback. It really helps to understand the
> > different point of views.
> > I will try to summarize my understanding of the issue based on your
> > comments so far and on the technical requirements of the system. First we
> > need to understand the 2 different times where the information about an
> > instance of a class (fact) being an event or not is needed:
> >
> > * At compile time: this is required to actually create the optimized
> > network (including the ObjectTypeNodes that Mike mentions). It is a must
> > have and we can't avoid it. The best way to do that IMO is using a specific
> > declarative statement in the rules files. I'm thinking about either an
> > "import event x.y.z.Event" statement, or a specific "declare event
> > x.y.z.Event". This is pure syntax to let the engine know what is an
> > event and what is not, at rulebase compilation time. If most users think a
> > syntax like "I want to declare that the x.y.z.Event instances are
> > events" is more appropriate, :) we could do it, but as it is today, I like
> > the idea of using a simple "event" keyword in import statements, the same
> > way we import static functions:
> >
> > import a.b.c.Fact; // a simple fact import
> > import function java.lang.Math.max; // a static function import
> >
> > import event x.y.z.Event; // an event import
> >
> > If we were an engine working with templates or any other type of
> > fact that did not allows inheritance, that would completely solve the
> > problem. But we work with POJOs as facts, and POJOs (being plain java)
> > support inheritance. So:
> >
> > * At runtime: even knowing, at compile time, that x.y.z.Event is an
> > event, at runtime a user may assert p.q.r.AnotherClass into working
> > memory. Now, is p.q.r.AnotherClass an event or not? We need to determine
> > that at the time the first instance of p.q.r.AnotherClass is asserted
> > into the working memory. At this time, in runtime, we create an
> > ObjectTypeNode for this fact class that previously was not known by the
> > engine. A few options on how to determine that were discussed here:
> >
> > 1. Mandate all classes that are events implement an "Event" interface. I
> > don't like this solution, as mentioned in a previous e-mail, because it
> > breaks the Drools paradigm of working with user defined domain models,
> > without contaminating them with drools specific code. Although, by your
> > comments, seems that this would be an acceptable solution.
> >
> > 2. Create a separate API (something like "session.insertEvent()") to
> > insert events into the working memory. This would also "solve" the problem,
> > but:
> > * "What happens if a user uses this API to insert a class that was not
> > declared as event at compile time?". From a technical perspective, this will
> > lead to unpredictable behavior and possibly to inconsistencies in the
> > reasoning algorithm, specially because events do not need shadow facts (they
> > are supposed to be immutable).
> > * "What happens if a user uses the regular 'session.insert()' API for a
> > class that was declared as an event at compile time?". Same as above with
> > the additional problem that the user may try to call update() or retract()
> > for that given fact, what is not allowed for events. Again, unpredictable
> > behavior.
> > My worry is that the only solution for the above 2 issues would be to
> > implement a verification routine that would validate if a fact asserted as
> > event is indeed an event according to what was declared at compile time, and
> > vice-versa. Note though, that this validation procedure would be basically
> > the same required for solution number 3 bellow, but would have to be
> > executed at every insert()/insertEvent() call, making it more costly than
> > the completely automated decision.
> >
> > 3. Implementing an automated decision procedure, analyzing the class
> > hierarchy of the inserted fact, every time a fact of a previously unknown
> > class is inserted into working memory. Due to the problems presented in the
> > previous solutions, this is still my preferred approach. Its main drawback
> > is the class hierarchy analysis that is not simple to do and at the same
> > time is a bit heavy, but would happen only when the first fact of a
> > previously unknown class is inserted into working memory.
> >
> > So, we can probably implement solution (1) and (2) as options, but
> > at this time, I can't see how to avoid implementing support for (3). But
> > having (3), is it worth to have (1) and/or (2) too, or would it only confuse
> > users?
> >
> > Thanks all for all the feedback so far.
> >
> > []s
> > Edson
> >
> > 2007/11/12, Anstis, Michael (M.) < manstis1 at ford.com>:
> > >
> > > Hi Felipe,
> > >
> > > I recall Edson saying that "Event" classes need to be ascertained at
> > > (RETE) compilation time - which, I think, rules out the API addition. I
> > > was hoping Edson, time permitting, would explain how
> > > declarative (fact-centric class) imports currently work to generate an
> > > ObjectTypeNode and therefore to understand how his proposal to create cached
> > > ObjectTypeConf instances for Event-centric classes compares. My reasoning
> > > being that if the process is similar the new event stuff should be no
> > > different; simply having two ObjectTypeNodes - one for Events and another
> > > for Facts. See attached.
> > >
> > > It's quite possible our exchanges have given Edson time to come to his
> > > own conclusion and the solution is now being coded!
> > >
> > > With kind regards,
> > >
> > > Mike
> > >
> > > ------------------------------
> > > *From:* rules-dev-bounces at lists.jboss.org [mailto:
> > > rules-dev-bounces at lists.jboss.org] *On Behalf Of *Felipe Piccolini
> > > *Sent:* 12 November 2007 13:25
> > > *To:* Rules Dev List
> > > *Subject:* Re: [rules-dev] Determining if a class is an event or not
> > >
> > > Well,
> > > IMHO for the experience I have I suggest to implement both
> > > solutions:
> > > -an API insertEvet() so the user can implement the mechanism to manage
> > >
> > > their rules knowing when a fact is an event or not.
> > > -an Interface Event so when the user cant manage the flow asserting
> > > facts, when
> > > he cant know when a fact is or not an event, then maybe he can wrap
> > > some facts on this
> > > interface and the API insert() internaly can check if the fact is an
> > > event or not and call insertEvent if
> > > necesary.
> > >
> > > :)
> > >
> > > On 08-11-2007, at 11:27, Anstis, Michael ((M.)) wrote:
> > >
> > > 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
> > > <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
> > >
> > >
> > >
> > > *Felipe Piccolini M.*
> > > felipe.piccolini at bluesoft.cl
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> >
> >
> >
> > *Felipe Piccolini M.*
> > felipe.piccolini at bluesoft.cl
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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/20071113/aea230f4/attachment.html
More information about the rules-dev
mailing list