JESS: A Question of Architecture

[Rich Halsey]

Hi All,   I have been engaged in an e-mail tag (with someone that I had worked with years ago) about the different kinds of architectures for rule-based systems.   The gentleman in question is a J2EE aficionado and is currently building a J2EE / rules-based system. Now this gentleman is definitely NOT a beginner in any sense (he worked with James Rumbaugh, the god of OMT, some years ago) but he seems to think that the ONLY way to structure a rules-based system is to have the application drive the rules and use the results in a piecemeal fashion.   In our (e-mail) conversation, I have said that an alternative way to structure the system is to use a stand-alone rules engine as the core "command & control" which reasons on the core business logic using core business data and responds to system generated events. This approach, in essence, drives the application with a core, proactive intelligence while the application code plays only a peripheral, reactive role. Where the business rules change, the corresponding application code should be easily traceable from the rules where it could be modified/eliminated (and not end up as "dead code" in the system).   One additional possibility to this approach is to use Aspect-Oriented Programming (AOP) to implement the "cross-cutting" concerns in the corresponding application code (that is driven by rules), i.e., leave the core business logic as is. There are those in the rule community (yes, you James) that feel it is a mortal sin to tamper with the coherence (understandability) of the rules, i.e., the business analysts should be able to read and comprehend the rules without all the additional esoteric baggage. Maybe this could be seen as an honorable comprmise, since the AOP would deal only with the application and not with the rules per se.   Anyone have any thoughts on this ??   Thanks,   Rich Halsey