[rules-users] Pattern of usage question

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<https://code.google.com/p/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