[rules-dev] Determining if a class is an event or not
Edson Tirelli
tirelli at post.com
Thu Nov 8 09:44:58 EST 2007
Matthias,
Thanks for the feedback. Since you are starting to dig into drools inner
workings, I think it is good to dig a bit more on this subject and detail my
comments, so that we can have your opinion on the broader subject of the
platform design.
> 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?
We always tried to avoid mandating the user to change its domain model to
use Drools and "contaminating" it with Drools specific classes/interfaces.
This way, different from other engines, we work with simple POJOs as facts.
There are also other reasons for that, like we want to implement support for
other fact types, like ontologies, etc, but the main one I still thing is
the one above.
So, we can have an Event interface or an annotation that the user may
use to explicit mark a Java class as an event, but IMO, we should use the
Event interface as an alternative way of doing it, and not as the only way.
A simpler solution we could go for is to mandate that the user declares
all its event classes/interfaces with a declare like statement in the DRL
instead of using the "import event" syntax. Something like that:
declare event a.b.c.Foo;
So the engine can load the class/interface a.b.c.Foo and check each
asserted fact to see if it is an a.b.c.Foo instance. That would be easier
from an engine perspective, but would be verbose from a users perspective,
since we would not be able to allow wildcards in such declaration. Would
that be better?
The other question you asked is really interesting and I also don't have
a definitive answer, but have some ideas:
> 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)?
In the paper "Discarding unused temporal information in a Production
System", by Dan Teodosiu and Günter Pollak, they state that "Events carry an
additional *implicit* attribute that represents the timestamp. The value of
this attribute is automatically set upon creation of an event to the current
value of the system-clock."
I agree with them, except for the "system-clock" part. Replace
"system-clock" by "engine-clock" and I think we get the best compromise.
We know that most real-world events are generated with an explicit
timestamp attribute, but since we may be handling events coming from
different sources without any guarantee that the sources have synchronized
clocks, we can not rely on the eventual explicit timestamp attribute for
reasoning in the engine. Not relying on that also give us the ability to
handle events that do not contain the explicit timestamp attribute.
What I am thinking is:
1. In current Drools implementation, each fact asserted into the rules
engine is wrapped in a FactHandle implementation. This FactHandle
implementation contains metadata attributes that are used by the engine
during fact manipulation and reasoning. What I'm suggesting is we derive a
new EventFactHandle implementation that would contain all event's implicit
attributes and metada we need, including the timestamp. This would allow us
to also support different semantic-models for the timestamp, and that is why
I asked you about the point-interval semantics. The easiest one would be the
point-in-time semantic, obviously.
2. We also will need to create the engine clock abstraction, and, as we
discussed previously, we will probably need 4 implementations:
- "System Clock": a clock that periodically synchronizes with the machine
clock
- "Event based clock": a clock that is updated every time a given event
arrives
- "Pseudo Clock": a generic implementation that is arbitrarily updated by
application code
- "Event Attribute Clock": a clock that is updated by a configured event
attribute
3. Every time a new event is inserted into the engine, we would then
populate the "implicit" attributes by using a configurable strategy. For
instance, if a user wants to use the explicit value of the object timestamp
as the event timestamp, the configurable strategy would simply copy the
value of the attribute to the implicit event attribute. If the user wants to
use the engine clock timestamp at assertion time as the event timestamp, the
configurable strategy would simply request the current value to the engine
clock and populate the event timestamp with this attribute.
What do you think about the above?
Thanks,
Edson
2007/11/8, Matthias <matthias.groch at sap.com>:
>
> 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 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/20071108/ac2854e1/attachment.html
More information about the rules-dev
mailing list