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]
--------------------------------------------------------------------

Reply via email to