The rules consulting experience of all times is to go on a rules project where the staff is migrating from a COBOL environment (after 10-15 years) to a PC/Java/rules environment (and their experience with this stuff is ZERO!) and where the management has said to all. "since you all have so much experience in the programming field, this can't be that hard !! I don't know anything about polymorphism, control flow, or forward chaining but the vendor has assured me that it can be done - I SAW The DEMO !!!!" <TeeHeeHeeHee>
----- Original Message ----- From: "Govoni, Darren" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 20, 2004 11:12 AM Subject: RE: JESS: A Different Rule Programming Technique My initial feeling is that the syntax of rule languages and scripting is perhaps less of a barrier to overcome than being a qualified Java developer who understands OOP, UML, frameworks and the like. Of course, that is if you're not already one. :) Generally speaking there is more overhead in a programming language to do things than a scripting or rule language, IMHO. -----Original Message----- From: [EMAIL PROTECTED] on behalf of Rich Halsey Sent: Fri 2/20/2004 11:33 AM To: Martin Griss Cc: [EMAIL PROTECTED] Subject: Re: JESS: A Different Rule Programming Technique My fundamental objective in using this approach would be to employ Java programmers writing the "conditions and actions" of rules in an object-oriented manner. Hopefully, this approach would preclude the need for people to be expert in the syntax of the rules language (of the engine being used) - the modeling could be done in UML and "rules" written in Java. There would still be a need for a person that is highly qualified in "rule architecture" to weave together rule sets (as you mentioned), control flow, or multiple engines for a system, but I feel that more Java programmers would be empowered to participate in rules projects by using this technique. My view on rules engineering is that (minimally) 3 main engineering artifacts should be available in this environment: (1) a goal tree to explain the control flow logic for rule set execution, (2) decision (situation) tables to express the completeness of a rule, and (3) an inferencing model to understand the chaining effects within rule sets. I don't forsee any problems integrating these artifacts with this programming technique. I started down this path by investigating a Model Driven Rules Architecture (MDrA) view and I am still encouraged by what I see. Thank you for the reply. OBTW - Some years ago, I purchased your book on software engineering and I enjoyed it. ----- Original Message ----- From: "griss" <[EMAIL PROTECTED]> To: "Rich Halsey" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, February 20, 2004 10:03 AM Subject: Re: JESS: A Different Rule Programming Technique > Yes, I like this simplified, structured paradigm. One still needs perhaps > to organize groups of rules into distinct rule sets, perhaps using multiple > instances of the RETE engine, rather than running all rules in one engine. > > In our context-aware agent work, we have used a very similar approach to > integrating rules and UML statemachines for complex protocols in Jade agent > systems, and have also sketched a way to also include machine learning (ala > WEKA). > > In the statemachine case, incoming events (e.g., agent messages) trigger > transitions to other states, if the event "matches" some template (match is > the predicate, on the event class). Jade provides a simple template > language, allowing AND and OR of basic templates, which we have extended by > using Jess rules as predicates over the events. If the match predicate > succeeds, than an action method is called on the body. > > In the machine learning case (applied to an email management system), > incoming emails are classified into different sets, and a match predicate > is defined for that class of email. This predicate is then used in a Jess > rule to determine if an action (a tree of actions) is run. > > --On Friday, February 20, 2004 9:10 AM -0600 Rich Halsey > <[EMAIL PROTECTED]> wrote: > > > > > Hi All, > > > > I am looking at a new technique for rules programming where "mere > > mortals" can build rule-based systems. Essentially, the technique uses > > UML-defined base classes to define a core predicate (that can also call > > other methods to define conditional tests) and a core action (that can > > also call other methods to accomplish desired actions). This technique > > relies on the Rete algorithm for matching of these rule objects and > > user-defined "data objects" which are passed to the rule objects for > > inspection. If the objects pass the conditional testing by the rule > > object's predicate, then the RHS is invoked to call the rule object's > > action method. > > It would seem that this technique could be used by all the OPS-like rules > > engines (JESS/JRules/OPSJ/JEOPS) out there and would enable ordinary Java > > programmers to write rules in an object-oriented manner for a > > Rete-enabled environment. This technique should not inhibit > > forward/backward chaining in any way and also allow for control flow > > logic to be incorporated into the system. > > Anybody have any thoughts ????? > > > > > > > > > > > > "Life, liberty, and the pursuit of those who threaten it" > > > > Martin Griss, PhD > > Director, Software Engineering Program, CMU West Coast > Adjunct Professor, UC Santa Cruz > > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
