Re: JESS: A Question of Architecture

[Rich Halsey]

I have to say first that my preferred architectural choice w/r/t rules engines is that they stand alone, i.e., they are not some micro-managed J2EE object which seems to be a constraint that is very difficult to live with.   If we consider the possibility of interlocking rules engine, i.e., a network of distributed rules engine that constitute the command and control of an enterprise environment, then the J2EE architecture pales in comparison. Now we would have distributed intelligence and as Dr. Friedman-Hill pointed out the rules engine processes can be implemented in a number of ways. This why I find J2EE so constraining - it just doesn't give you many choices. And OBTW, you can forget about using any multi-threaded facts in the working memory of the rules engine which is passivated by J2EE. It seems to me that J2EE is like a Porsche (beautiful car) with a Briggs & Stratton lawn-mower engine. I may be wrong, but these are my impressions.     ----- Original Message ----- From: Chandra Mouleeswaran To: [EMAIL PROTECTED] Sent: Monday, October 27, 2003 9:24 AM Subject: Re: JESS: A Question of Architecture Going back to your question on architectural choices, there's nothing like a centralized rule engine that watches over all objects/services (J2EE or otherwise). People often overlook the need to monitor applications in building and deploying traditional message-passing architectures. At this junction, it is not very useful to have a rule engine sit behind some remote object with a very localized view of the world! A rule engine with a working memory that spans the entire network is a very powerful concept! Chandra Email: [EMAIL PROTECTED] Do you Yahoo!? Exclusive Video Premiere - Britney Spears