Yes you need some sort of flushable cache to be able to change the RuleBase at runtime. But you don't want to be reloading the rulebase each time. Just call .newWorkingMemory() each time you need a fresh WM to use (sometimes people keep WMs hanging around - not for performance but because the rule engine is stateful in their case).
As for DRLs, Geoffrey said it well. You can use XML entities to break apart your DRL files if needed. A rulebase can be made up of multiple rulesets, but as you observed, most scenarious are one DRL to one ruleset, to one rulebase (but this is not necessarily the case). You certainly want to have seperate rulebases for different parts of your system if they are using rules in totally different ways. On 12/22/05, Paul Smith <[EMAIL PROTECTED]> wrote: > > Thanks Geoffrey, that's just what I was looking for. Just been doing > some further reading and it seems that the way I have currently > organised it seems to be correct. The only thing I may do additional > is getting the RuleBases bound into JNDI so that I can potentially > update them at runtime. > > Thanks again for the response. > > On 12/22/05, Geoffrey Wiseman <[EMAIL PROTECTED]> wrote: > > On 12/21/05, Paul Smith <[EMAIL PROTECTED]> wrote: > > > > > > Is there logically a concept that you have a drl file > > > > > that is just logic for a particular context of the application in one > > > drl file and separate logic in another drl file. > > > > > > I'm not sure if I'm reading this the way you intended. If you have two > sets > > of rules that are logically disjoint, that you expect to run at > different > > points of the application, then, yes, I'd make these entirely distinct > > rulesets and load them in entirely distinct rulebases, so that they > could be > > invoked separately. You could do this with rule filters, IIRC, but I > > wouldn't be inclined to; if you can make these kinds of partitions, it > > limits the size of the rete graph, simplifying the processing. > > > > The second level of division I'd see is this: are there rules that are > > re-usable from one RuleBase to another in segments smaller than the > > rulebase? That is, does one rulebase consist of rules ABCD and the next > > CDEF? If so, then it's helpful to have C and D declared in different > files > > han AB and EF, because they are more easily reused. > > > > Finally, any level below that seems largely organizational; there are > some > > implication level concerns around things like functions and imports at a > > ruleset level, but at this level it's more about those concerns and the > > sheer aesthetics than anything else. > > > > Does that answer your question? > > > > 2. I am presuming that RuleBase instance/s should be loaded up at > > > application initialisation and then a new WorkingMemory created when > > > the rules are to be fired. Not sure if this is the case or not as the > > > code examples are not clear on this. I'm just looking at it from a > > > performance optimisation perspective. > > > > > > This has some caching value, yes -- working memories are likely to be > > distinct on a per-use basis, but rule bases can be shared. Due to the > > performance overhead involved in creating a rulebase from .drl, caching > can > > be considered useful, although as in other uses of caching, this is a > > tradeoff against memory consumption and updatability that you should > > consider. > > > > - Geoffrey > > > > -- > > Geoffrey Wiseman > > > > >
