[jboss-svn-commits] JBL Code SVN: r34192 - labs/jbossrules/trunk/drools-docs/drools-docs-expert/src/main/docbook/en-US/Chapter-Rule_Engine.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Mon Jul 26 10:43:39 EDT 2010
Author: ge0ffrey
Date: 2010-07-26 10:43:38 -0400 (Mon, 26 Jul 2010)
New Revision: 34192
Removed:
labs/jbossrules/trunk/drools-docs/drools-docs-expert/src/main/docbook/en-US/Chapter-Rule_Engine/Chapter-Rule_Engine.xml
labs/jbossrules/trunk/drools-docs/drools-docs-expert/src/main/docbook/en-US/Chapter-Rule_Engine/Section-What_is_a_Rule_Engine.xml
labs/jbossrules/trunk/drools-docs/drools-docs-expert/src/main/docbook/en-US/Chapter-Rule_Engine/Section-Why_use_a_Rule_Engine.xml
Log:
JBRULES-2591 docs which are both duplicate and dead
Deleted: labs/jbossrules/trunk/drools-docs/drools-docs-expert/src/main/docbook/en-US/Chapter-Rule_Engine/Chapter-Rule_Engine.xml
===================================================================
--- labs/jbossrules/trunk/drools-docs/drools-docs-expert/src/main/docbook/en-US/Chapter-Rule_Engine/Chapter-Rule_Engine.xml 2010-07-26 14:31:28 UTC (rev 34191)
+++ labs/jbossrules/trunk/drools-docs/drools-docs-expert/src/main/docbook/en-US/Chapter-Rule_Engine/Chapter-Rule_Engine.xml 2010-07-26 14:43:38 UTC (rev 34192)
@@ -1,19 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<chapter version="5.0"
- xsi:schemaLocation="http://docbook.org/ns/docbook http://www.docbook.org/xml/5.0/xsd/docbook.xsd http://www.w3.org/1999/xlink http://www.docbook.org/xml/5.0/xsd/xlink.xsd"
- xml:base="./" xmlns="http://docbook.org/ns/docbook" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xlink="http://www.w3.org/1999/xlink"
- xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:ns="http://docbook.org/ns/docbook">
- <title>The Rule Engine</title>
-
- <xi:include href="Section-What_is_a_Rule_Engine.xml" />
- <xi:include href="Section-Why_use_a_Rule_Engine.xml" />
- <!--xi:include href="Section-Rules.xml" />
- <xi:include href="Section-Rete_Algorithm.xml" /-->
- <!--xi:include href="Section-The_Drools_Rule_Engine.xml" /-->
- <!--xi:include href="Chapter-Rule_Engine/Section-Rule_Base.xml" />
- <xi:include href="Chapter-Rule_Engine/Section-Working_Memory.xml" />
- <xi:include href="Chapter-Rule_Engine/Section-Agenda.xml" />
- <xi:include href="Chapter-Rule_Engine/Section-Event_Model.xml" /-->
-
-</chapter>
Deleted: labs/jbossrules/trunk/drools-docs/drools-docs-expert/src/main/docbook/en-US/Chapter-Rule_Engine/Section-What_is_a_Rule_Engine.xml
===================================================================
--- labs/jbossrules/trunk/drools-docs/drools-docs-expert/src/main/docbook/en-US/Chapter-Rule_Engine/Section-What_is_a_Rule_Engine.xml 2010-07-26 14:31:28 UTC (rev 34191)
+++ labs/jbossrules/trunk/drools-docs/drools-docs-expert/src/main/docbook/en-US/Chapter-Rule_Engine/Section-What_is_a_Rule_Engine.xml 2010-07-26 14:43:38 UTC (rev 34192)
@@ -1,182 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<section version="5.0"
- xsi:schemaLocation="http://docbook.org/ns/docbook http://www.docbook.org/xml/5.0/xsd/docbook.xsd http://www.w3.org/1999/xlink http://www.docbook.org/xml/5.0/xsd/xlink.xsd"
- xml:base="../" xmlns="http://docbook.org/ns/docbook" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xlink="http://www.w3.org/1999/xlink"
- xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:ns="http://docbook.org/ns/docbook">
- <title>What is a Rule Engine?</title>
-
- <section>
- <title>Introduction and Background</title>
-
- <para>Artificial Intelligence (A.I.) is a very broad research area that
- focuses on "Making computers think like people" and includes disciplines
- such as Neural Networks, Genetic Algorithms, Decision Trees, Frame Systems
- and Expert Systems. Knowledge representation is the area of A.I. concerned
- with how knowledge is represented and manipulated. Expert Systems use
- Knowledge representation to facilitate the codification of knowledge into
- a knowledge base which can be used for reasoning, i.e., we can process
- data with this knowledge base to infer conclusions. Expert Systems are
- also known as Knowledge-based Systems and Knowledge-based Expert Systems
- and are considered to be "applied artificial intelligence". The process of
- developing with an Expert System is Knowledge Engineering. EMYCIN was one
- of the first "shells" for an Expert System, which was created from the
- MYCIN medical diagnosis Expert System. Whereas early Expert Systems had
- their logic hard-coded, "shells" separated the logic from the system,
- providing an easy to use environment for user input. Drools is a Rule
- Engine that uses the rule-based approach to implement an Expert System and
- is more correctly classified as a Production Rule System.</para>
-
- <para>The term "Production Rule" originates from formal grammars where it
- is described as "an abstract structure that describes a formal language
- precisely, i.e., a set of rules that mathematically delineates a (usually
- infinite) set of finite-length strings over a (usually finite) alphabet"
- (<citetitle><link xlink:href="http://en.wikipedia.org/wiki/Formal_grammar">Wikipedia</link></citetitle>).</para>
-
- <para>Business Rule Management Systems build additional value on top of a
- general purpose Rule Engine by providing business user focused systems for
- rule creation, management, deployment, collaboration, analysis and end
- user tools. Further adding to this value is the fast evolving and popular
- methodology "Business Rules Approach", which is a helping to formalize the
- role of Rule Engines in the enterprise.</para>
-
- <para>The term Rule Engine is quite ambiguous in that it can be any system
- that uses rules, in any form, that can be applied to data to produce
- outcomes. This includes simple systems like form validation and dynamic
- expression engines. The book "How to Build a Business Rules Engine (2004)"
- by Malcolm Chisholm exemplifies this ambiguity. The book is actually about
- how to build and alter a database schema to hold validation rules. The
- book then shows how to generate VB code from those validation rules to
- validate data entry. This, while a very valid and useful topic for some,
- caused quite a surprise to this author, unaware at the time in the
- subtleties of Rules Engines' differences, who was hoping to find some
- hidden secrets to help improve the Drools engine. JBoss jBPM uses
- expressions and delegates in its Decision nodes which control the
- transitions in a Workflow. At each node it evaluates ther is a rule set
- that dictates the transition to undertake, and so this is also a Rule
- Engine. While a Production Rule System is a kind of Rule Engine and also
- an Expert System, the validation and expression evaluation Rule Engines
- mentioned previously are not Expert Systems.</para>
-
- <para>A Production Rule System is Turing complete, with a focus on
- knowledge representation to express propositional and first order logic in
- a concise, non-ambiguous and declarative manner. The brain of a Production
- Rules System is an Inference Engine that is able to scale to a large
- number of rules and facts. The Inference Engine matches facts and data
- against Production Rules - also called Productions or just Rules - to
- infer conclusions which result in actions. A Production Rule is a two-part
- structure using First Order Logic for reasoning over knowledge
- representation.</para>
-
- <programlisting role="JAVA">when
- <conditions>
-then
- <actions>;</programlisting>
-
- <para>The process of matching the new or existing facts against Production
- Rules is called <indexterm>
- <primary>Pattern Matching</primary>
- </indexterm> Pattern Matching, which is performed by the <indexterm>
- <primary>Inference Engine</primary>
- </indexterm> Inference Engine. There are a number of algorithms used for
- Pattern Matching by Inference Engines including:</para>
-
- <itemizedlist>
- <listitem>
- <para>Linear</para>
- </listitem>
-
- <listitem>
- <para>Rete</para>
- </listitem>
-
- <listitem>
- <para>Treat</para>
- </listitem>
-
- <listitem>
- <para>Leaps</para>
- </listitem>
- </itemizedlist>
-
- <para>Drools implements and extends the <indexterm>
- <primary>Rete</primary>
- </indexterm> Rete algorithm;<indexterm>
- <primary>Leaps</primary>
- </indexterm> Leaps used to be provided but was retired as it became
- unmaintained. The Drools <indexterm>
- <primary>Rete</primary>
- </indexterm> Rete implementation is called ReteOO, signifying that
- Drools has an enhanced and optimized implementation of the Rete algorithm
- for object oriented systems. Other Rete based engines also have marketing
- terms for their proprietary enhancements to Rete, like RetePlus and Rete
- III. The most common enhancements are covered in "Production Matching for
- Large Learning Systems (Rete/UL)" (1995) by Robert B. Doorenbos.</para>
-
- <para>The Rules are stored in the <indexterm>
- <primary>Production Memory</primary>
- </indexterm> Production Memory and the facts that the Inference Engine
- matches against are kept in the <indexterm>
- <primary>WorkingMemory</primary>
- </indexterm> Working Memory. Facts are asserted into the Working Memory
- where they may then be modified or retracted. A system with a large number
- of rules and facts may result in many rules being true for the same fact
- assertion; these rules are said to be in conflict. The Agenda manages the
- execution order of these conflicting rules using a Conflict Resolution
- strategy.</para>
-
- <figure>
- <title>High-level View of a Rule Engine</title>
-
- <mediaobject>
- <imageobject>
- <imagedata align="center" contentdepth="300px" contentwidth="540px"
- fileref="images/Chapter-Rule_Engine/rule-engine-inkscape.png"
- format="PNG"></imagedata>
- </imageobject>
- </mediaobject>
- </figure>
-
- <para>There are two methods of execution for a rule system: Forward
- Chaining and Backward Chaining; systems that implement both are called
- Hybrid Rule Systems. Understanding these two modes of operation is the key
- to understanding why a Production Rule System is different and how to get
- the best from it. Forward chaining is "data-driven" and thus reactionary,
- with facts being asserted into working memory, which results in one or
- more rules being concurrently true and scheduled for execution by the
- Agenda. In short, we start with a fact, it propagates and we end in a
- conclusion. Drools is a forward chaining engine.</para>
-
- <figure>
- <title>Forward Chaining</title>
-
- <mediaobject>
- <imageobject>
- <imagedata align="center"
- fileref="images/Chapter-Rule_Engine/Forward_Chaining.png"
- format="PNG"></imagedata>
- </imageobject>
- </mediaobject>
- </figure>
-
- <para>Backward chaining is "goal-driven", meaning that we start with a
- conclusion which the engine tries to satisfy. If it can't it then searches
- for conclusions that it can satisfy; these are known as subgoals, that
- will help satisfy some unknown part of the current goal. It continues this
- process until either the initial conclusion is proven or there are no more
- subgoals. Prolog is an example of a Backward Chaining engine; Drools plans
- to provide support for Backward Chaining in a future release.</para>
-
- <figure>
- <title>Backward Chaining</title>
-
- <mediaobject>
- <imageobject>
- <imagedata align="center"
- fileref="images/Chapter-Rule_Engine/Backward_Chaining.png"
- format="PNG"></imagedata>
- </imageobject>
- </mediaobject>
- </figure>
- </section>
-</section>
Deleted: labs/jbossrules/trunk/drools-docs/drools-docs-expert/src/main/docbook/en-US/Chapter-Rule_Engine/Section-Why_use_a_Rule_Engine.xml
===================================================================
--- labs/jbossrules/trunk/drools-docs/drools-docs-expert/src/main/docbook/en-US/Chapter-Rule_Engine/Section-Why_use_a_Rule_Engine.xml 2010-07-26 14:31:28 UTC (rev 34191)
+++ labs/jbossrules/trunk/drools-docs/drools-docs-expert/src/main/docbook/en-US/Chapter-Rule_Engine/Section-Why_use_a_Rule_Engine.xml 2010-07-26 14:43:38 UTC (rev 34192)
@@ -1,279 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<section version="5.0"
- xsi:schemaLocation="http://docbook.org/ns/docbook http://www.docbook.org/xml/5.0/xsd/docbook.xsd http://www.w3.org/1999/xlink http://www.docbook.org/xml/5.0/xsd/xlink.xsd"
- xml:base="../" xmlns="http://docbook.org/ns/docbook" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xlink="http://www.w3.org/1999/xlink"
- xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:ns="http://docbook.org/ns/docbook">
- <title>Why use a Rule Engine?</title>
-
- <para>Some frequently asked questions:</para>
-
- <orderedlist>
- <listitem>
- <para>When should you use a rule engine?</para>
- </listitem>
-
- <listitem>
- <para>What advantage does a rule engine have over hand coded
- "if...then" approaches?</para>
- </listitem>
-
- <listitem>
- <para>Why should you use a rule engine instead of a scripting framework,
- like <indexterm>
- <primary>BeanShell</primary>
- </indexterm> BeanShell?</para>
- </listitem>
- </orderedlist>
-
- <para>We will attempt to address these questions below.</para>
-
- <section>
- <title>Advantages of a Rule Engine</title>
-
- <itemizedlist>
- <listitem>
- <para>Declarative Programming</para>
-
- <para>Rule engines allow you to say "What to do", not "How to do
- it".</para>
-
- <para>The key advantage of this point is that using rules can make it
- easy to express solutions to difficult problems and consequently have
- those solutions verified. Rules are much easier to read than
- code.</para>
-
- <para>Rule systems are capable of solving very, very hard problems,
- providing an explanation of how the solution was arrived at and why
- each "decision" along the way was made (not so easy with other of AI
- systems like neural networks or the human brain - I have no idea why I
- scratched the side of the car).</para>
- </listitem>
-
- <listitem>
- <para>Logic and Data Separation</para>
-
- <para>Your data is in your domain objects, the logic is in the rules.
- This is fundamentally breaking the OO coupling of data and logic,
- which can be an advantage or a disadvantage depending on your point of
- view. The upshot is that the logic can be much easier to maintain as
- there are changes in the future, as the logic is all laid out in
- rules. This can be especially true if the logic is cross-domain or
- multi-domain logic. Instead of the logic being spread across many
- domain objects or controllers, it can all be organized in one or more
- very distinct rules files.</para>
- </listitem>
-
- <listitem>
- <para>Speed and Scalability</para>
-
- <para>The Rete algorithm,the Leaps algorithm, and their descendants such as
- Drools' ReteOO, provide very efficient ways of matching
- rule patterns to your domain object data. These are especially
- efficient when you have datasets that change in small portions as the
- rule engine can remember past matches. These algorithms are battle
- proven.</para>
- </listitem>
-
- <listitem>
- <para>Centralization of Knowledge</para>
-
- <para>By using rules, you create a repository of knowledge (a
- knowledge base) which is executable. This means it's a single point of
- truth, for business policy, for instance. Ideally rules are so
- readable that they can also serve as documentation.</para>
- </listitem>
-
- <listitem>
- <para>Tool Integration</para>
-
- <para>Tools such as Eclipse (and in future, Web based user interfaces)
- provide
- ways to edit and manage rules and get immediate feedback, validation
- and content assistance. Auditing and debugging tools are also
- available.</para>
- </listitem>
-
- <listitem>
- <para>Explanation Facility</para>
-
- <para>Rule systems effectively provide an "explanation facility" by
- being able to log the decisions made by the rule engine along with why
- the decisions were made.</para>
- </listitem>
-
- <listitem>
- <para>Understandable Rules</para>
-
- <para>By creating object models and, optionally, Domain Specific
- Languages that model your problem domain you can set yourself up to
- write rules that are very close to natural language. They lend
- themselves to logic that is understandable to, possibly nontechnical,
- domain experts as they are expressed in their language, with all the
- program plumbing, the technical know-how being hidden
- away in the usual code.</para>
- </listitem>
- </itemizedlist>
- </section>
-
- <section>
- <title>When should you use a Rule Engine?</title>
-
- <para>The shortest answer to this is "when there is no satisfactory
- traditional programming approach to solve the problem.". Given that short
- answer, some more explanation is required. The reason why there is no
- "traditional" approach is possibly one of the following: <itemizedlist>
- <listitem>
- <para>The problem is just too fiddle for traditional code.</para>
-
- <para>The problem may not be complex, but you can't see a
- non-fragile way of building a solution for it.</para>
- </listitem>
-
- <listitem>
- <para>The problem is beyond any obvious algorithmic
- solution.</para>
-
- <para>It is a complex problem to solve, there are no obvious
- traditional solutions, or basically the problem isn't fully
- understood.</para>
- </listitem>
-
- <listitem>
- <para>The logic changes often</para>
-
- <para>The logic itself may even be simple but
- the rules change quite often. In many organizations software
- releases are few and far between and pluggable rules can help provide the
- "agility" that is needed and expected in a reasonably safe
- way.</para>
- </listitem>
-
- <listitem>
- <para>Domain experts (or business analysts) are readily available,
- but are nontechnical.</para>
-
- <para>Domain experts often possess a wealth of knowledge about business
- rules and processes. They typically are nontechnical, but can be
- very logical. Rules can allow them to express the logic in their own
- terms. Of course, they still have to think critically and be capable
- of logical thinking. Many people in nontechnical positions do
- not have training in formal logic, so be careful and work with them,
- as by codifying business knowledge in rules, you will often expose
- holes in the way the business rules and processes are currently
- understood.</para>
- </listitem>
- </itemizedlist></para>
-
- <para>If rules are a new technology for your project teams, the overhead
- in getting going must be factored in. It is not a trivial technology, but
- this document tries to make it easier to understand.</para>
-
- <para>Typically in a modern OO application you would use a rule engine to
- contain key parts of your business logic,
- <emphasis>especially the really messy parts</emphasis>. This is
- an inversion of the OO concept of encapsulating all the logic inside your
- objects. This is not to say that you throw out OO practices, on the
- contrary in any real world application, business logic is just one part of
- the application. If you ever notice lots of conditional statements
- such as "if" and "switch", an
- overabundance of strategy patterns and other messy logic in your code
- that just doesn't feel right: that would be a place for rules.
- If there is some such logic and you keep coming back to fix it, either
- because you got it wrong, or the logic or your understanding changes: think
- about using rules. If you are faced with tough problems for which there are
- no algorithms or patterns: consider using rules.</para>
-
- <para>Rules could be used embedded in your application or perhaps as a
- service. Often a rule engine works best as "stateful" component, being
- an integral part of an application. However, there have been
- successful cases of creating reusable rule services which are
- stateless.</para>
-
- <para>For your organization it is important to decide about the process you
- will use for updating rules in systems that are in production. The options
- are many, but different organizations have different requirements.
- Frequently, rules maintenance is out of the control of the application
- vendors or project developers.</para>
- </section>
-
- <section>
- <title>When not to use a Rule Engine</title>
-
- <para>To quote a Drools mailing list regular: <blockquote><attribution>Dave Hamu</attribution>
-<para>It seems to me
- that in the excitement of working with rules engines, that people forget
- that a rules engine is only one piece of a complex application or
- solution. Rules engines are not really intended to handle workflow or
- process executions nor are workflow engines or process management tools
- designed to do rules. Use the right tool for the job. Sure, a pair of
- pliers can be used as a hammering tool in a pinch, but that's not what
- it's designed for.</para>
-</blockquote></para>
-
- <para>As rule engines are dynamic (dynamic in the sense that the rules can
- be stored and managed and updated as data), they are often looked at as a
- solution to the problem of deploying software. (Most IT departments seem to
- exist for the purpose of preventing software being rolled out.) If this is
- the reason you wish to use a rule engine, be aware that rule engines work
- best when you are able to write declarative rules. As an alternative, you
- can consider data-driven designs (lookup tables), or script processing
- engines where the scripts are managed in a database and are able to be
- updated on the fly.</para>
- </section>
-
- <section>
- <title>Scripting or Process Engines</title>
-
- <para>Hopefully the preceding sections have explained when you may want to
- use a rule engine.</para>
-
- <para>Alternatives are script-based engines that provide the drive
- for "changes on the fly", and there are many such solutions.</para>
-
- <para>Alternatively Process Engines (also capable of workflow) such as
- jBPM allow you to graphically (or programmatically) describe steps in a
- process. Those steps can also involve decision points which are in
- themselves a simple rule. Process engines and rules often can work nicely
- together, so they are not mutually exclusive.</para>
-
- <para>One key point to note with rule engines is that some rule engines
- are really scripting engines. The downside of scripting engines is that
- you are tightly coupling your application to the scripts. If they are
- rules, you are effectively calling rules directly and this may cause more
- difficulty in future maintenance, as they tend to grow in complexity over
- time. The upside of scripting engines is that they can be easier to
- implement initially, producing results quickly, and are conceptually
- simpler for imperative programmers.</para>
-
- <para>Many people have also implemented data-driven systems successfully
- in the past (where there are control tables that store meta-data that
- changes your applications behavior) - these can work well when the
- control can remain very limited. However, they can quickly grow out of
- control if extended too much (such that only the original creators can
- change the applications behavior) or they cause the application to
- stagnate as they are too inflexible.</para>
- </section>
-
- <section>
- <title>Strong and Loose Coupling</title>
-
- <para>No doubt you have heard terms like "tight coupling" and "loose
- coupling" in systems design. Generally people assert that "loose" or
- "weak" coupling is preferable in design terms, due to the added
- flexibility it affords. Similarly, you can have "strongly coupled" and
- "weakly coupled" rules. Strongly coupled in this sense means that one rule
- "firing" will clearly result in another rule firing, and so on; in other
- words,
- there is a clear (probably obvious) chain of logic. If your rules are all
- strongly coupled, the chances are that the will turn out to be inflexible,
- and, more significantly, that a rule engine is an overkill. A clear chain
- can be hard coded, or implemented using a Decision Tree. This is not to
- say that strong
- coupling is inherently bad, but it is a point to keep in mind when
- considering a rule engine and the way you capture the rules. "Loosely"
- coupled rules should result in a system that allows rules to be changed,
- removed and added without requiring changes to other, unrelated
- rules.</para>
- </section>
-</section>
More information about the jboss-svn-commits
mailing list