10:54 a.m.
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(a)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(a)lists.jboss.org [mailto:
rules-dev-bounces(a)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(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org<rules-dev-bounces@lists.jboss.org>]
On Behalf Of Matthias
Sent: 08 November 2007 13:09
To: rules-dev(a)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.Event should
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
*Felipe Piccolini M.*
felipe.piccolini(a)bluesoft.cl
_______________________________________________
rules-dev mailing list
rules-dev(a)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