<br> Mike, Felipe and Matthias,<br><br> Thank you for all your feedback. It really helps to understand the different point of views.<br> 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:
<br><br>* 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:
<br><br>import a.b.c.Fact; // a simple fact import<br>import function java.lang.Math.max; // a static function import<br>
<br>import event x.y.z.Event; // an event import<br><br> 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:
<br><br>* 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:
<br><br>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.
<br><br>2. Create a separate API (something like "session.insertEvent()") to insert events into the working memory. This would also "solve" the problem, but: <br>* "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).
<br>* "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.
<br> 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.
<br><br>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.
<br><br> 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?
<br><br> Thanks all for all the feedback so far.<br><br> []s<br> Edson<br><br><div><span class="gmail_quote">2007/11/12, 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 style="">
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">Hi Felipe,</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 recall Edson saying that "Event" classes need to be
ascertained at (RETE) compilation time - which, I think, rules out the
API addition. </font></span><span><font color="#0000ff" face="Arial" size="2">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.</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">It's quite possible our exchanges have given Edson time to
come to his own conclusion and the solution is now being
coded!</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">With kind regards,</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">Mike</font></span></div><br>
<blockquote dir="ltr" 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>Felipe
Piccolini<br><b>Sent:</b> 12 November 2007 13:25<br><b>To:</b> Rules Dev
List</font><div><span class="e" id="q_1163461a218f8a0c_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_1163461a218f8a0c_3">
<div></div>Well,
<div><br></div>
<div> IMHO for the experience I have I suggest to implement both
solutions:</div>
<div><span style="white-space: pre;"></span>-an API
insertEvet() so the user can implement the mechanism to manage</div>
<div>their rules knowing when a fact is an event or not.</div>
<div><span style="white-space: pre;"></span>-an Interface
Event so when the user cant manage the flow asserting facts, when</div>
<div>he cant know when a fact is or not an event, then maybe he can wrap some
facts on this</div>
<div>interface and the API insert() internaly can check if the fact is an
event or not and call insertEvent if</div>
<div>necesary.</div>
<div><br></div>
<div>:)</div>
<div><br>
<div>
<div>On 08-11-2007, at 11:27, Anstis, Michael ((M.)) wrote:</div><br>
<blockquote type="cite">
<div style="margin: 0px;">Here's my 2 cents - as a non-contributor to Drools
codebase ;-)</div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">You could add insertEventFactTypeThingie to the
API? Then you need just</div>
<div style="margin: 0px;">check that the class has been declared as an event
in the DRL similar to</div>
<div style="margin: 0px;">what must already happen for normal DRL imports. I
personally don't have</div>
<div style="margin: 0px;">issue with implementing a marker interface (this is
what frameworks like</div>
<div style="margin: 0px;">Hibernate, EJB3 and Spring etc have been imposing
for years). What "wiring"</div>
<div style="margin: 0px;">does the POJO need to become an Event for use in
Drools? Are you trying to</div>
<div style="margin: 0px;">internalise too much at the risk of making the
event mechanism inflexible?</div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">Cheers,</div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">Mike</div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">-----Original Message-----</div>
<div style="margin: 0px;">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></div>
<div style="margin: 0px;">[<a href="mailto:rules-dev-bounces@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">mailto:rules-dev-bounces@lists.jboss.org</a>]
On Behalf Of Matthias</div>
<div style="margin: 0px;">Sent: 08 November 2007 13:09</div>
<div style="margin: 0px;">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></div>
<div style="margin: 0px;">Subject: Re: [rules-dev] Determining if a class is
an event or not</div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">Edson Tirelli <tirelli <at> <a href="http://post.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">post.com</a>>
writes:</div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<blockquote type="cite">
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;"><span>
</span>All, <span> </span>I reached a
point where I need to make a design decision and</div></blockquote>
<div style="margin: 0px;">would</div>
<div style="margin: 0px;">like your opinion about it. <span> </span>Imagine the following scenario:
<span> </span>A user has a</div>
<div style="margin: 0px;">domain model like this:package a.b.c</div>
<blockquote type="cite">
<div style="margin: 0px;">;public interface Event { ... }package
x.y.z;public class MyEvent</div></blockquote>
<div style="margin: 0px;">implements</div>
<div style="margin: 0px;">a.b.c.Event {...} <span> </span>Then, in his DRL file he
writes:package p.q.r;import</div>
<div style="margin: 0px;">event</div>
<div style="margin: 0px;">a.b.c.*;<span>
</span>rule Xwhen</div>
<blockquote type="cite">
<div style="margin: 0px;"><span>
</span>Event( ... )then<span>
</span>...end <span> </span>So, it is
clear that a.b.c.Event should</div></blockquote>
<div style="margin: 0px;">be</div>
<div style="margin: 0px;">handled as an event by the engine. <span> </span>At runtime, the user asserts an
object</div>
<div style="margin: 0px;">of</div>
<div style="margin: 0px;">the class x.y.z.MyEvent into the working memory.
Seems clear to me (and</div>
<div style="margin: 0px;">probably</div>
<div style="margin: 0px;">to the user) that MyEvent should be handled as an
event, since by DRL</div>
<div style="margin: 0px;">semantics,<span> </span></div>
<blockquote type="cite">
<div style="margin: 0px;">a.b.c.* are all events, and by OO class hierarchy
concept, since</div></blockquote>
<div style="margin: 0px;">a.b.c.Event</div>
<div style="margin: 0px;">is an event, x.y.z.MyEvent is an event too. <span> </span>My question is: how the
engine</div>
<div style="margin: 0px;">knows that MyEvent is an event, since it only has
the x.y.z.MyEvent</div>
<blockquote type="cite">
<div style="margin: 0px;"><span> </span>class as input? <span> </span>The only answer I have is that
when the first MyEvent</div></blockquote>
<div style="margin: 0px;">instance is asserted into the working memory, we
must get the class name and</div>
<div style="margin: 0px;">iterate over all event import declarations checking
for a match. In case no</div>
<div style="margin: 0px;">one</div>
<div style="margin: 0px;">is found, we need to repeat the process for each
interface and each class up</div>
<div style="margin: 0px;">in</div>
<div style="margin: 0px;">the MyEvent hierarchy. Once this process is
complete, we cache the results</div>
<div style="margin: 0px;">in</div>
<div style="margin: 0px;">the ObjectTypeConf.<span> </span></div>
<blockquote type="cite">
<div style="margin: 0px;"><span>
</span>This may be a quite heavy process to be executed each time a fact
of a</div></blockquote>
<div style="margin: 0px;">different class is asserted in the working memory
for the first time, but I</div>
<div style="margin: 0px;">can't think a different user-friendly way to solve
the question.</div>
<blockquote type="cite">
<div style="margin: 0px;"><span>
</span>The alternatives would be intrusive, IMO, breaking the drools
premise</div></blockquote>
<div style="margin: 0px;">to</div>
<div style="margin: 0px;">work with user-defined POJOs as facts: use
anotations to annotate classes</div>
<div style="margin: 0px;">that</div>
<div style="margin: 0px;">are events, or mandate users implement a specific
interface for events.</div>
<blockquote type="cite">
<div style="margin: 0px;"><span>
</span>Any better idea?<span>
</span>[]s<span>
</span>Edson<span> </span>--
<span> </span>Edson Tirelli<span> </span>Software</div></blockquote>
<div style="margin: 0px;">Engineer</div>
<div style="margin: 0px;">- JBoss Rules Core Developer<span> </span>Office: +55 11 3529-6000<span> </span>Mobile: +55 11</div>
<div style="margin: 0px;">9287-5646</div>
<blockquote type="cite">
<div style="margin: 0px;"><span>
</span>JBoss, a division of Red Hat<span> </span><at><span> </span><a href="http://www.jboss.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.jboss.com</a></div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">_______________________________________________</div>
<div style="margin: 0px;">rules-dev mailing list</div>
<div style="margin: 0px;">rules-dev <at> <a href="http://lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">lists.jboss.org</a></div>
<div style="margin: 0px;"><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></div>
<div style="margin: 0px; min-height: 14px;"><br></div></blockquote>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">Edson,</div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">I got your striving not to mandate users implement
a specific interface for</div>
<div style="margin: 0px;">events. However, why not at least introducing an
empty event interface (i.e.</div>
<div style="margin: 0px;">a</div>
<div style="margin: 0px;">marker interface, similar to the Serializable
interface in Java) the</div>
<div style="margin: 0px;">user-defined event class(es) have to implement?
This way, when inserting a</div>
<div style="margin: 0px;">MyEvent instance, you can simply check whether it
implements the event</div>
<div style="margin: 0px;">interface</div>
<div style="margin: 0px;">(by means of 'instanceof'). Moreover, while parsing
the import statements of</div>
<div style="margin: 0px;">a</div>
<div style="margin: 0px;">rule file, it enables you to double-check whether
all the "event imports"</div>
<div style="margin: 0px;">really</div>
<div style="margin: 0px;">refer to classes implementing the (empty) event
interface.</div>
<div style="margin: 0px;">In this regard, for me another question raises:
Without making any</div>
<div style="margin: 0px;">restrictions</div>
<div style="margin: 0px;">on the structure for a user defined event class,
how do you make sure it has</div>
<div style="margin: 0px;">all</div>
<div style="margin: 0px;">the<span>
</span>required attributes of an event (which in my opinion must be a</div>
<div style="margin: 0px;">timestamp,</div>
<div style="margin: 0px;">at least) and how do you access them (necessary for
temporal relationships)?</div>
<div style="margin: 0px;">Having said this, in my opinion defining an empty
event interface may not be</div>
<div style="margin: 0px;">sufficient; in addition, it must force the user to
implement a method</div>
<div style="margin: 0px;">returning</div>
<div style="margin: 0px;">the event's occurrence date (i.e. the timestamp) at
least... Or how would</div>
<div style="margin: 0px;">you</div>
<div style="margin: 0px;">handle this issue?</div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">Matthias<span> </span></div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">_______________________________________________</div>
<div style="margin: 0px;">rules-dev mailing list</div>
<div style="margin: 0px;"><a href="mailto:rules-dev@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev@lists.jboss.org</a></div>
<div style="margin: 0px;"><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></div>
<div style="margin: 0px;">_______________________________________________</div>
<div style="margin: 0px;">rules-dev mailing list</div>
<div style="margin: 0px;"><a href="mailto:rules-dev@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev@lists.jboss.org</a></div>
<div style="margin: 0px;"><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></div>
</blockquote></div><br>
<div><span style="word-spacing: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-size-adjust: none; font-stretch: normal; text-transform: none; color: rgb(0, 0, 0); text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate; border-spacing: 0px;">
<div><span style="text-decoration: underline;"><span>
</span></span>
<div><font size="3"><span style="font-size: 13px;"><b style="font-weight: bold; font-size: 13px;"><span style="font-weight: bold; font-size: 13px;">Felipe
Piccolini M.</span></b></span></font></div>
<div><a href="mailto:felipe.piccolini@bluesoft.cl" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"><span style="color: rgb(0, 0, 238);">felipe.piccolini@bluesoft.cl</span></a></div><br></div>
<div><br></div><br></span></div><br></div></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>