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. :)


2007/11/8, Anstis, Michael (M.) < manstis1@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@lists.jboss.org [mailto:rules-dev-bounces@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


   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


2007/11/8, Anstis, Michael (M.) <manstis1@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?



-----Original Message-----
From: rules-dev-bounces@lists.jboss.org
[mailto: rules-dev-bounces@lists.jboss.org] On Behalf Of Matthias
Sent: 08 November 2007 13:09
To: rules-dev@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
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
a.b.c.Event {...}   Then, in his DRL file he writes:package p.q.r;import
a.b.c.* ;    rule Xwhen
>     Event( ... )then    ...end   So, it is clear that a.b.c.Event should
handled as an event by the engine.   At runtime, the user asserts an object
the class x.y.z.MyEvent into the working memory. Seems clear to me (and
to the user) that MyEvent should be handled as an event, since by DRL
> a.b.c.* are all events, and by OO class hierarchy concept, since
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
is found, we need to repeat the process for each interface and each class up
the MyEvent hierarchy. Once this process is complete, we cache the results
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
work with user-defined POJOs as facts: use anotations to annotate classes
are events, or mandate users implement a specific interface for events.
>     Any better idea?    []s    Edson    --   Edson Tirelli  Software
- JBoss Rules Core Developer  Office: +55 11 3529-6000  Mobile: +55 11
>   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


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.
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
(by means of 'instanceof'). Moreover, while parsing the import statements of
rule file, it enables you to double-check whether all the "event imports"
refer to classes implementing the (empty) event interface.
In this regard, for me another question raises: Without making any
on the structure for a user defined event class, how do you make sure it has
the  required attributes of an event (which in my opinion must be a
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
the event's occurrence date (i.e. the timestamp) at least... Or how would
handle this issue?


rules-dev mailing list

rules-dev mailing list

  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

  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