This is usually solved using a pattern called "event abstraction". You
model your "EventXStarted" and "EventXEnded" as atomic events (i.e.,
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"
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"
$start : EventXStarted()
$end : EventXEnded( id == $start.id )
insert( new EventX( $start, $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,
2010/4/14 Barry Kaplan <groups1(a)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
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
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
(eg, 3 downtimes longer than 2 minutes in the last hour).
View this message in context:
Sent from the Drools - User mailing list archive at Nabble.com
rules-users mailing list
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com