Barry,

    This is usually solved using a pattern called "event abstraction". You model your "EventXStarted" and "EventXEnded" as atomic events (i.e., no duration) and write rules that depend on the start/end of the event against these atomic events. Then, you use a correlating rule to abstract these two events into an "EventX" event that has the proper duration. You write rules that depend on the correlation of the whole event against this "EventX" event.

    Drools does not offer syntax sugar for event abstraction yet, so you have to write the correlating rule as a regular rule. E.g.:

rule "correlating event X"
when
    $start : EventXStarted()
    $end : EventXEnded( id == $start.id )
then
    insert( new EventX( $start, $end ) );
end

    Obviously, inside the constructor or any helper method, you can populate additional attributes/data for EventX.

    Several CEP tools out there avoid this kind of use case by not supporting composite events (i.e., supporting only atomic events). I believe we can support that and do it well, although we still have a long way ahead. My short term goal is to be able to define such event abstractions with syntax sugar to make it easier for users. With proper tooling, this could be a drag&drop+mapping operation.

    Hope it helps,

    Edson

2010/4/14 Barry Kaplan <groups1@memelet.com>

A fusion design question:

I have events that represent intervals. Initially the intervals are
open-ended (kind a like the current state of an entity). Other events are
matched "during" the interval and correlated. At some point the interval
will be closed (eg, a specific downtime interval is closed because the
device is no online again).

All the events in this system are immutable -- so if some property of an
event changes, it is cloned and modified in working-memory. For the case of
the interval events, initially the interval is inserted open-ended, and at
some point later closed and then modified.

This does not work with fusion however, since an event's duration is
maintained by the fact-handle not the event itself. Hence a modify with a
now closed interval (ie, a finite @duration) has no effect. I'm guessing the
temporal values are maintained the handle to ensure stable values for the
behaviors that trigger based on temporal values, which is reasonable.

So I'm looking for alternative designs. Some are:
 1) Modeled the intervals as begin/end events, but that gets messy real
fast (have to correlate
     the begin/end events somehow, can't use evaluators like 'includes' or
'during', etc).
 2) Retract the interval event when it is closed (this way closed intervals
no longer correlate
     with other incoming events). But then we really have a manually
maintained state machine
     using only facts, and there can be no reasoning over a series these
interval events.
    (eg, 3 downtimes longer than 2 minutes in the last hour).

Opinions?

-barry

--
View this message in context: http://n3.nabble.com/Fusion-and-open-ended-intervals-tp719076p719076.html
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users



--
 Edson Tirelli
 JBoss Drools Core Development
 JBoss by Red Hat @ www.jboss.com