[rules-users] Pattern of usage question

[Alexander Wolf]

Hey Laird, 

right now I work on a new Java WebService (with Spring) that uses Drools to accomplish complex event processing on sensor values (=events).

As I am relatively new to this, I can definitely not call it "best practice" or anything the like. But so far it seems to work ;)

- I create and delete sessions (basically a wrapper that contains some more meta-information and the knowledgeSession) as required by the service user
- Every session is identified by an integer ID and "lives" in a static list in one singleton bean. (kinda yuck, but what can you do about that?*)
- When the server is shut down, I serialize all sessions and store them in a database
- When the server is started, I recover all sessions stored in my database. 

When new events occur, they are:
1) received (REST interface)
2) session is identified
3) fact (event!) is inserted (with @timestamp)
4) fireAllRules() is called   [I never got "fireUntilHalt" to work as expected...)

* -> As I do a lot of temporal reasoning, I can not just fireAllRules() and then serialize/stop the session. Some rules fire minutes or hours after certain events if no other events occur afterwards. Therefore my knowledgeSessions live in memory eternally.


About the rule adding/changing:
- In my application, every client has his own session/kbase that is parameterized ( I do this with template, although its not really what templates were meant for in the first place I suppose...)
- I do recreate the whole knowledge base when the rules  are changed and restart the session (otherwise, it leads to funny behaviour)
- I have read at different points that one can add single rules to the kbase of a running stateful session, but I also read that it may cause problems and might be unstable (so you'd have to test it somehow)

I wouldn't mind to share more thoughts so if you got questions, don't hesitate to write directly.

- Alex


On 07.10.2013, at 21:01, Laird Nelson <ljnelson at gmail.com> wrote:

> I have several questions about using Drools in a stateless Java EE application.
> 
> (I've actually used it for years, but have always felt an impedance mismatch and finally have a moment to ask about it.  :-))
> 
> Like (I suspect) many people, I have a stateless session bean responsible for some business logic with Drools in the mix.  I'm looking to implement its—say—doWork() method with a knowledge session under the covers.
> 
> What I'm curious about is: in a rules engine, facts are sort of expected to stick around for a while (that's state; I know there are stateless sessions, but those are kind of ephemeral). You grab a bunch of facts, and over time they get inserted into the knowledge session, which sticks around in some manner.  Then, periodically, you fire all rules, and deal with the consequences.  Along comes another processing situation; you fire all rules, and deal with the consequences again.  And so on.  The fact maintenance seems stateful here while the rule processing is stateless.  How do people deploy stateless systems with this stateful concept at their core?  Which of the many possibilities is most commonly used?  Serialize/deserialize the session on each request (yuck)?  Singleton beans (yuck, I think)?  Outboard drools server with RPC (also yuck, I think)?
> 
> Next, in a dynamic business application, it's often the case that single rules need to be added to the knowledge base.  Someone wants to add in, for example, a new way of calculating fees.  They don't—at a human level—want to open up the catalog of 47,000 rules, add one, and then re-install/re-deploy the thus-changed catalog of rules.  They just—again, at a human level—want to add a new rule.  Is redeploying the catalog the only way to go here, or is there a way that I've missed to incrementally and programmatically add a rule to a KnowledgeBase?
> 
> More generally: in a stateless app, where do these concepts live?  Where do they best live, I should say?
> 
> (For completeness, I'm the author of the drools-jca project, which attempts to make Drools 5.x Java EE compatible by offloading its filesystem and threading operations into a JCA resource adapter.  I'm not convinced that's the best place for it and with Drools 6 doing different things with threads and with Java EE 7 relaxing its restrictions on filesystem access I'm looking for better patterns.)
> 
> Thanks very much for reading; looking forward to the replies.
> 
> Best,
> Laird
> 
> -- 
> http://about.me/lairdnelson
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20131014/41842fcf/attachment.html