I must say I am always surprised by the creativity of the users on how to model and solve some use cases. :) Very refreshing to hear!

   Let me comment first on the way you are heading and after that how I (Edson) would model the same problem.

   What you are doing is, what I would call, a clever way of integrating the rules engine with your application user interface by using the event listeners frameworks. This is kind of the same thing Kris developed for ruleflow groups transition control, if I'm not mistaken, but the difference is that his code being internal, allows him to use some internal APIs to overcome the walls you also hit. Using only the public APIs may not be feasible and using internal APIs may cause undesiring coupling problems for you when drools is upgraded.
   My main worry recommending you to continue in the direction you are heading is that you will face additional problems in the future. Just to mention one example, in 5.0 I am implementing support for multi-thread rules evaluation and network partitioning, and as part of this job, I'm removing access to unsafe calls to the agenda that were kind-of available in 4.0 (they were not published as public APIs, but the methods were public).

   So, how I would model your solution? Spliting "detection rules" from "action rules" and using logical asserts to make the link between then. I see other possible benefits of that approach, like multiple action options for the same problem or a single action for multiple problems, etc. Let me explain using an example. Pretend you have 2 rules for detecting overheat and overpressure respectivelly:

rule "Detection rule: overheat"
when
     Sensor( temperature > 50 )
then
     insertLogical( new Alarm( Type.OVERHEAT, "some info here") );
end

rule "Detection rule: overpressure"
when
     Sensor( pressure > 4 )
then
     insertLogical( new Alarm( Type.OVERPRESSURE, "some info here") );
end

rule "Action rule: open valve"
when
    exists( Alarm( type == Type.OVERHEAT || == Type.OVERPRESSURE ) )
then
    // inform possible solution: open valve
end

rule "Action rule: increase refrigeration power"
when
    exists( Alarm( type == Type.OVERHEAT ) )
then
    // inform possible solution: increase refrigeration power
end

   So, you see that the actions and detections being used as separate rules allow you to sugest the same solution for multiple problems or just for single problems. Also, you are free to fire your rules all the time, because what informs you about the current status of the system are the Alarm facts that are logically inserted into the working memory.
   I don't know if you are familiar with the "logical insert" feature, but if you have an overheat alarm and your temperature goes bellow the threashold (50 in my example), it will detect the change and will automatically retract the alarm fact as it is no longer true that you have an overheat.

   You may continue using listeners to update your user interface, by monitoring the Alarm fact assertions instead of the agenda events, or you can also use queries to get the alarms from working memory.

   Let us know what you think and if you want to write a use case blog, like we had the other day for a Naval Engineering use case, you are more than welcome!

http://blog.athico.com/2008/09/improving-naval-engineering-process.html  

   Cheers,
      Edson




--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com