yes you can load the DRL from wherever you like, database, or file system for instance.
Just rememeber that with rule engines, you generally cache the RuleBase (as it is called in drools) for performance. So you will need a way to refresh this cache. Part of Drools 3.0 will be to have a rule repository that runtime systems can use, which will take care of rule versions, caching, and release into production (of course it is optional, people are free to use their own solutions to meet their needs). Regarding Peters comments on changes to rules at runtime: I general, if you rule invocations are stateless, which means each time you call the rules it is a new WorkingMemory, then it is quite easy to swap out rules at runtime. Any processes running using the old rules will continue as normal, and the new calls will use the new rules. Many typical uses of rule engines work this way, but there are cases where it is stateful, in which case it is more complex (for instance, you can add rules to an existing working memory). Its good to get feedback on common ways that people use rules, as we work on the APIs for Drools 3.0, it would be good to include the common use cases in a high level API to make it easier for people to get started. Michael. On 12/16/05, Sinha, Amitesh <[EMAIL PROTECTED]> wrote: > > We are trying to use drools for our business rule implementation in the > J2EE framework. Is there a way we can define the rules outside the .ear > file, so that new rules can be added without rebuilding the new jar/ear? > > > > Thanks and Regards, > > Amitesh Sinha > > Technical Architect > Telecom Business Unit > Patni Computer Systems > [EMAIL PROTECTED] > -----Original Message----- > From: Peter Lin [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 15, 2005 8:38 AM > To: [email protected] > Subject: Re: [drools-dev] Still New to this - Dynamic Loading of rules > > within the field of rule engines and business rules, it is common to > deploy > new rules to a production system assuming the new rules have been > tested/verified. > > altering existing rules is a challenging issue. There are a couple of > reasons for this. > > 1. the system may be running, which means modifying the rule could have > potentially negative effect > 2. the system needs to be able to handle ruleset changes gracefully > 3. should the system simply create a new instance of the rule engine and > deploy the new ruleset > > There are a couple of different approaches to solving these kinds of > issues: > > 1. spawn a new rule engine instance and load the rules. have all new > requests go to the new engine instance and allow the existing engines to > finish. once they are finished, get rid of them > > 2. explicitly have a fact in the rule to turn it off/on. for example: > > rule1 > if (active) > if .. blah blah blah (the actual rule logic) > > by having a rule specific pattern to turn it off/on, one can easily > assert a > fact to deactivate the rule. when that happens, all activations for that > rule will be removed from the agenda. which means it's safe to remove > the > rule and deploy the modified version > > 3. go with a scheduled approach, such that if the rule engine is busy, > wait > until it is idle. the primary draw back of this approach that a > production > system might not ever be idle > > 4. go with a scheduled approach such that one the current process is > done, > the engine is no longer available. this is safe and allows current > processes > to finish > > In terms of deploying changes to the object model, that generally is > lower > risk, so additions to an object generally can be deployed. Assuming of > course the change has been tested and verified to be good. The critical > factor of dynamic deployment is rule validation. If you have a good > validation process, deploying new or modifying rules "can" be > manageable. > Getting to that point takes experience and patience. > > peter lin > > > > On 12/15/05, Keith Marshall <[EMAIL PROTECTED]> wrote: > > > > > > As we are still new, and eager to prove this concept for use on a > > current project, we are looking into the rule file itself and where it > > may be located and loaded from. We are also interested to know more > > about the dynamic use or loading of the rule file at runtime. Is > > possible to architect such that the rules are able to be dynamically > > loaded at runtime? The burning question is are we able to change rules > > and have the application be affected the new rule? If so some insight > > would be greatly appreciated. > > > > > > > > Keith A. Marshall > > Ext: 1089 > > > > >
