Yes that's what I figured. I think it boils down to having the application operate in particular context and organising those rules for that context. ie) I might want rules around my supplier information but those rules would be different for say validating the suppliers details when you were setting them up as opposed to validating whether a particular supplier could fullfill your requirements in a given time frame. Same data to be validated but the context of how you use/validate it is different.
On 12/23/05, Michael Neale <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > > > >
