I'm going to disagree that NRL is an anti-pattern. It all depends on how you use it. I've successfully designed and built custom business rule languages in the past. The key is keeping the domain well defined and narrow. Don't try to make a DSL that is a general purpose language.
For example, say I want to create a rule language for defining privacy rules for mobile phones. The first thing I do is define a set of entities the rules would need to reason over. A ficticious example might be this. addressbook name number relation time allow deny take a message The next step is to define some privacy rules a person might write. It might looks like this. deny any call not in my addressbook allow any call from family take a message for non-family before 8 am and after 6 pm Once you have enough rules to get a good idea of the scope, you can start designing the language. Writing the parser is heavily dependent on how solid the DSL is. Once you have the parser, converting to JESS is straight forward. peter On Tue, Jun 24, 2008 at 12:33 AM, Michael Smith <[EMAIL PROTECTED]> wrote: > > On Jun 23, 2008, at 6:40 PM, Barry Flower wrote: > > I am interested in using Natural Rules Language for business rules > definition and was wondering if anyone is aware of an implementation > (commercial or otherwise) that can be used with Jess. I understand that it > would need to be constrained for a specific business domain and would assume > that the NRL would have the facility to be customised (using a constraint > taxonomy or ontology). > > Cheers > Barry > > I wouldn't recommend DROOLS in general [1], but they do have some support > for creating a custom domain-specific language (DSL). If having a DSL is of > paramount importance, it is worth a gander. But... > IMO, such DSLs are usually an anti-pattern. The DSL might get you started > great guns at first and for demos -- but it will not do everything you and > the customer will want, and then you'll have two problems: the problem at > hand, and maintaining a rapidly expanding feature list for the DSL. With > the pressure to keep moving forward, the likely ad hoc development of the > DSL will become increasingly unwieldy, frustrating, and expensive to > maintain. > As a developer -- unless all of your testing and development works within an > automated testing environment, I suspect you'll find debugging and > maintaining a DROOLS-based rules engine significantly more difficult, due to > how it compiles and loads rules. Even with the automation, the Jess command > line is a powerful development environment (like any REPL). So maybe > you'll have three problems. Depends on whether you find it useful to drop > bits of code into an interpreted environment full of state or you re-run > after editing (or re-run after compiling and editing). > If you had a really large, and non-technical, set of rule writers relative > to the software development team, and a budget to pay for DSL maintenance, > then a DSL might make sense. But good language design is tough for > non-trivial cases. Pretty soon one can find that the rules need to be more > expressive than first thought, and more and more arcane syntax is needed, > and one begins to wonder why the rule developers weren't just trained on the > original rule engine's language. > It's much the same yin/yang as the issues surrounding "visual"/wizardly rule > editors. If you go this way, try to study the best commercial software > first, and only then decide if you want to roll your own. > $0.02 and change, > - Mike > [1] Unfortunately, the open sourceness of DROOLS seems to trump any and all > advantages Jess has to offer in many developers minds. Jess's current > license is an Achilles heel in many environments. The lack of an > interpreted, shell-oriented, paradigm (no REPL) is a huge loss. -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] --------------------------------------------------------------------
