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@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@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