<br> Michael,<br><br> 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:
<br><br>* we can use some "declaration statement" in the DRL like the ones I described<br>* we can make the classes implement a markup-interface like Matthias was suggesting<br>* we can use keywords, like iLog uses, writing "event" in every pattern that represents an event
<br><br> 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).
<br><br> The idea here is to discuss exactly the benefits and disadvantages of each approach. :)<br><br> []s<br> Edson<br><br><div><span class="gmail_quote">2007/11/8, Anstis, Michael (M.) <<a href="mailto:manstis1@ford.com">
manstis1@ford.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">I can turn that question around...</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">If the user has written objects MyFact and MyEvent is it
fair to expect them to have to declare it in the DRL?</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">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?</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">This is much more interesting than (my) work
;-)</font></span></div><br>
<blockquote style="margin-right: 0px;">
<div dir="ltr" align="left" lang="en-us">
<hr>
<font face="Tahoma" size="2"><b>From:</b> <a href="mailto:rules-dev-bounces@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev-bounces@lists.jboss.org</a>
[mailto:<a href="mailto:rules-dev-bounces@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev-bounces@lists.jboss.org</a>] <b>On Behalf Of </b>Edson
Tirelli<br><b>Sent:</b> 08 November 2007 14:54<br><b>To:</b> Rules Dev
List</font><div><span class="e" id="q_1161fe99cf371b70_1"><font face="Tahoma" size="2"><br><b>Subject:</b> Re: [rules-dev] Determining if a class is an event or
not<br></font></span></div><br></div><div><span class="e" id="q_1161fe99cf371b70_3">
<div></div><br> Michael,<br><br> 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.<br> Anyway, the API would solve this part of the
problem, but the whole scenario is: <br> 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): <br><br>import event
a.b.c.Foo; (or)<br>import event a.b.c.*;<br><br>or explicit
saying:<br><br>declare event a.b.c.Foo;<br> <br> 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? <br><br>session.insert(); for regular
facts<br>session.insertEvent(); for events<br><br>
[]s<br> Edson<br><br>
<div><span class="gmail_quote">2007/11/8, Anstis, Michael (M.) <<a href="mailto:manstis1@ford.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">manstis1@ford.com </a>>:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Here's
my 2 cents - as a non-contributor to Drools codebase ;-)<br><br>You could
add insertEventFactTypeThingie to the API? Then you need just <br>check that
the class has been declared as an event in the DRL similar to<br>what must
already happen for normal DRL imports. I personally don't have<br>issue with
implementing a marker interface (this is what frameworks like <br>Hibernate,
EJB3 and Spring etc have been imposing for years). What "wiring"<br>does the
POJO need to become an Event for use in Drools? Are you trying
to<br>internalise too much at the risk of making the event mechanism
inflexible? <br><br>Cheers,<br><br>Mike<br><br>-----Original
Message-----<br>From: <a href="mailto:rules-dev-bounces@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev-bounces@lists.jboss.org</a><br>[mailto:<a href="mailto:rules-dev-bounces@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
rules-dev-bounces@lists.jboss.org</a>] On Behalf Of Matthias<br>Sent: 08
November 2007 13:09<br>To: <a href="mailto:rules-dev@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev@lists.jboss.org</a><br>Subject:
Re: [rules-dev] Determining if a class is an event or not <br><br>Edson
Tirelli <tirelli <at> <a href="http://post.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">post.com</a>>
writes:<br><br>><br>><br>> All,
I reached a point where I need to make a design decision
and<br>would<br>like your opinion about it. Imagine the
following scenario: A user has a <br>domain model like
this:package a.b.c<br>> ;public interface Event { ... }package
x.y.z;public class MyEvent<br>implements<br>a.b.c.Event {...}
Then, in his DRL file he writes:package p.q.r;import<br>event<br>a.b.c.*
; rule Xwhen<br>> Event(
... )then ...end So, it is clear that
a.b.c.Event should<br>be<br>handled as an event by the engine.
At runtime, the user asserts an object<br>of<br>the class x.y.z.MyEvent into
the working memory. Seems clear to me (and <br>probably<br>to the user) that
MyEvent should be handled as an event, since by DRL<br>semantics,<br>>
a.b.c.* are all events, and by OO class hierarchy concept,
since<br>a.b.c.Event<br>is an event, x.y.z.MyEvent is an event
too. My question is: how the engine <br>knows that MyEvent is an
event, since it only has the x.y.z.MyEvent<br>> class as
input? The only answer I have is that when the first
MyEvent<br>instance is asserted into the working memory, we must get the
class name and <br>iterate over all event import declarations checking for a
match. In case no<br>one<br>is found, we need to repeat the process for each
interface and each class up<br>in<br>the MyEvent hierarchy. Once this
process is complete, we cache the results <br>in<br>the
ObjectTypeConf.<br>> This may be a quite heavy
process to be executed each time a fact of a<br>different class is asserted
in the working memory for the first time, but I<br>can't think a different
user-friendly way to solve the question. <br>> The
alternatives would be intrusive, IMO, breaking the drools
premise<br>to<br>work with user-defined POJOs as facts: use anotations to
annotate classes<br>that<br>are events, or mandate users implement a
specific interface for events. <br>> Any better
idea? []s Edson --
Edson Tirelli Software<br>Engineer<br>- JBoss Rules Core
Developer Office: +55 11 3529-6000 Mobile: +55
11<br>9287-5646<br>> JBoss, a division of Red
Hat <at> <a href="http://www.jboss.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.jboss.com</a><br>><br>><br>>
_______________________________________________<br>> rules-dev mailing
list<br>> rules-dev <at> <a href="http://lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">lists.jboss.org </a><br>> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>><br><br><br>Edson,<br><br>I
got your striving not to mandate users implement a specific interface for
<br>events. However, why not at least introducing an empty event interface
(i.e.<br>a<br>marker interface, similar to the Serializable interface in
Java) the<br>user-defined event class(es) have to implement? This way, when
inserting a <br>MyEvent instance, you can simply check whether it implements
the event<br>interface<br>(by means of 'instanceof'). Moreover, while
parsing the import statements of<br>a<br>rule file, it enables you to
double-check whether all the "event imports" <br>really<br>refer to classes
implementing the (empty) event interface.<br>In this regard, for me another
question raises: Without making any<br>restrictions<br>on the structure for
a user defined event class, how do you make sure it has
<br>all<br>the required attributes of an event (which in my
opinion must be a<br>timestamp,<br>at least) and how do you access them
(necessary for temporal relationships)?<br>Having said this, in my opinion
defining an empty event interface may not be <br>sufficient; in addition, it
must force the user to implement a method<br>returning<br>the event's
occurrence date (i.e. the timestamp) at least... Or how
would<br>you<br>handle this
issue?<br><br>Matthias<br><br>_______________________________________________
<br>rules-dev mailing list<br><a href="mailto:rules-dev@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
https://lists.jboss.org/mailman/listinfo/rules-dev</a>
<br><br>_______________________________________________<br>rules-dev mailing
list<br><a href="mailto:rules-dev@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
https://lists.jboss.org/mailman/listinfo/rules-dev</a><br><br><br></blockquote></div><br><br clear="all"><br>-- <br> Edson Tirelli<br> Software
Engineer - JBoss Rules Core Developer<br> Office: +55 11
3529-6000<br> Mobile: +55 11 9287-5646 <br> JBoss, a
division of Red Hat @ <a href="http://www.jboss.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.jboss.com</a>
</span></div></blockquote></div>
<br>_______________________________________________<br>rules-dev mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">
https://lists.jboss.org/mailman/listinfo/rules-dev</a><br><br><br clear="all"></blockquote></div><br><br clear="all"><br>-- <br> Edson Tirelli<br> Software Engineer - JBoss Rules Core Developer<br> Office: +55 11 3529-6000
<br> Mobile: +55 11 9287-5646<br> JBoss, a division of Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a>