In addition to "Jess In Action", I am also reading Ramnivas Laddad's book on AspectJ. As mentioned in the post, I am beginning to see another dimension to rules engineering (using AOP) and I appreciate your expert insight. You are confirming what I have suspected - AOP and rules can play together very well.
As long as I am not being obnoxious, I would also like to point out another problem I have seen out here on various projects in "rules world" - the total lack of "control flow architectures". For example, where there exists a need for a large number of rules with extremely complex interdependencies, the potential for a "forward chain-reaction" (like an ammo dump going off) seems to pop up around every corner. Obviously, a programmatic way to inhibit this forward chaining is very desirable and doable. Unfortunately, this may not paint the whole picture. The required control may have to be composed of a combinatorial series of (procedural) steps which take on an ordered sequential, conjunctive, or disjunctive nature not unlike a work flow tree. So, now we have a deterministic control layer laid on top of a non-deterministic rules system. My advice to the last project that I was on was to "approach this like two porcupines making love - very carefully". At last report, they have now recognized the problem and are beginning to understand how to formulate some simple rule-based solutions. W/r/t control flow architectures, I have been looking at a system called "Micro Workflow" by Dragos Manolescu. At some point, I intend to incorporate his ideas/code into a rule-based solution for this problem. Again, hope I haven't been too obnoxious. Thanks, Rich Halsey ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, October 26, 2003 11:34 AM Subject: Re: JESS: A Question of Architecture > I think Rich Halsey wrote: > > > 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. > > That's a pretty old-fashioned view. Jess can be used in several > alternative ways: as a module off to the side, but also as an > event-handler, as a central controller, or a co-process. Of course > IBM's take on rules involves event-driven architectures. > > > > 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). > > Yes, like the HVAC controller in Jess in Action. > > > > 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. > > Ramnivas Laddad's book on AspectJ does this for a banking application > using Jess as the example rule engine. It's a clever and powerful > technique. > > > > > Anyone have any thoughts on this ?? > > I think the objection based on understanding the rules separately is a > straw-man argument. If there's a problem there, then it's simply a > code readability/encapsulation issue. If the rules are acting on > well-encapsulated business objects, there's no reason at all why > readability should suffer whether the rule engine is used in an active > or reactive way. Indeed, trying to strictly separate rules from > application objects will obfuscate both the rules and the application > logic. > > Now, if the argument is that the rules should represent "pure logic," > well, arguments about "pure logic" or "pure object orientation" or > other such things are just silly, IMO. The clearest, simplest, best > design for an application always involves some compromise between > these high-minded principles and our reality. > > > > --------------------------------------------------------- > Ernest Friedman-Hill > Science and Engineering PSEs Phone: (925) 294-2154 > Sandia National Labs FAX: (925) 294-2234 > PO Box 969, MS 9012 [EMAIL PROTECTED] > Livermore, CA 94550 http://herzberg.ca.sandia.gov > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
