Another advantage to using a rule engine is that you can easily build state
machines which can remember previous states. In a stateless server this may
not make sense but in other contexts it does.
In other words, a rule engine is *both* rules (if/then/else) and working
memory (data structures) that happen to be fused together in an elegant (and
flexible) way.
If you are familiar with component/interface based programming you may have
read Clemens Szyperski's excellent book:
http://www.amazon.com/exec/obidos/ASIN/0201178885/qid=974488627/sr=1-4/102-1
051266-0806544
In this book he mentions many of the problems/challenges associated with
object oriented designs including threading and call graph dependencies. He
briefly mentions that possible ways to solve these problems may very well
rest in other programming paradigms such as the functional or declarative
models.
Disclaimer: This is my interpretation having read the book a while back and
not having it in front of me, I could be misstating his point D-;
In any case, you can view a call stack as being a form of intermediate state
which is *not* generally available to the running program so it cannot make
decisions based on that state.
Rule based systems, in my view, encourage the "flattening" of this state
into the working memory so that it can be used to prevent, for example, two
incompatible scenarios from running concurrently depending on the actual
objects involved in each.
In procedural languages, this usually translates into synchronization blocks
on objects (or sets of objects) and carefull orchestration of threads. In
rule based systems, this is often expressed as control/phase facts and/or
rules/patterns.
For most simple systems or data validation this is not necessarily a problem
but is something to consider if you can envision your design scaling to
handle more complexity in the furture.
alan
> -----Original Message-----
> From: Vicken Kasparian [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 17, 2000 7:46 AM
> To: 'Peter Frederick'; Jess-Users@Sandia. Gov
> Subject: RE: JESS: JESS vs IF-THEN statements
>
>
> My rule of thumb is the following:
>
> 1. If you can flow-chart on a piece of paper the logic that
> you are trying
> to implement, then you should be able to implement your rules using
> if/then/else procedural logic else, you will be better off
> using a rule
> engine.
>
> 2. Another reason why you may want to use Jess (a rule
> engine) is if the
> logic that you are implementing will change frequently. Using
> a rule engine,
> you will get a good separation between your application and
> the logic. With
> a rule engine, you will be able to change the logic of your
> application
> without needing to alter the application itself.
>
> 3. Another reason for using a rule engine is taking advantage
> of inferencing
> (forward and/or backward chaining) and conflict resolution.
> Although a lot
> of rule base applications that I have seen do not really need
> inferencing,
> it is there if you need it.
>
> _________
> Vicken Kasparian
> Voice: 941-756-6000 ext. 3550
> Fax : 941-758-3800
> http://www.cheetahtech.com
> mailto:[EMAIL PROTECTED]
>
> > -----Original Message-----
> > From: Peter Frederick [SMTP:[EMAIL PROTECTED]]
> > Sent: Friday, November 17, 2000 10:04 AM
> > To: Jess-Users@Sandia. Gov
> > Subject: JESS: JESS vs IF-THEN statements
> >
> > I know that Jess is an extremely powerful tool for
> rule-based reasoning
> > but, on a small scale with relatively simple IF/THEN/ELSE
> style rules, is
> > there a point at which the advantages of Jess are
> outweighed by the level
> > of
> > effort needed to learn it?
> > The project I am working on targeted rule-based reasoning
> as one of its
> > methods but I am concerned that it might be 'overkill'.
> Has anyone else
> > been in this situation and what would you recommend?
> >
> > Yours,
> >
> > Pete Frederick
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > 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]
> ---------------------------------------------------------------------
>
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
