4:59 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users