Another point to think about is if you are planning on allowing rules to change in a running system. With DRL files, you will be updating them as one item, so you version control it as one items, test it, approve it etc... So you may break down the rules such that rules that change at different times are seperate.
On 12/23/05, Paul Smith <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > > > > > > > > > > >
