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 > >
