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 <[email protected]> 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
