Re: [rules-dev] Determining if a class is an event or not

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. 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: 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(a)sap.com&gt;: > > 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. > 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 > -- 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