[jboss-svn-commits] JBL Code SVN: r14159 - labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Sat Aug 11 13:33:09 EDT 2007
Author: mark.proctor at jboss.com
Date: 2007-08-11 13:33:08 -0400 (Sat, 11 Aug 2007)
New Revision: 14159
Modified:
labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Rules.xml
labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-The_Drools_Rule_Engine.xml
labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-What_is_a_Rule_Engine.xml
labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Why_use_a_Rule_Engine.xml
Log:
JBRULES-1059 Online typos in Section 1
Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Rules.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Rules.xml 2007-08-11 15:27:39 UTC (rev 14158)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Rules.xml 2007-08-11 17:33:08 UTC (rev 14159)
@@ -84,7 +84,7 @@
</listitem>
</itemizedlist>
- <para>'forall' and 'accumulate' will be added shortley.
+ <para>'forall' and 'accumulate' will be added shortly.
The following Field Constraints are allowed:</para>
<itemizedlist>
@@ -216,9 +216,9 @@
<para>10 == 2 * 5</para>
- <para>Expressions that evaluate against one or more variables, the facts, are
- "open statements", in that we cannot determine whether the statement is
- true until we have a variable instance to evaluate against:</para>
+ <para>Expressions that evaluate against one or more variables, the facts,
+ are "open statements", in that we cannot determine whether the statement
+ is true until we have a variable instance to evaluate against:</para>
<para>Person.sex == "male"</para>
@@ -249,15 +249,15 @@
<para>So in Java we can say that a simple proposition is of the form
'variable' 'operator' 'value' - where we often refer to 'value' as being a
literal value - a proposition can be thought as a field constraint.
- Further to this propositions can be combined with conjuntive and
- disjuntive connectives, which is the logic theorists way of saying
+ Further to this propositions can be combined with conjunctive and
+ disjunctive connectives, which is the logic theorists way of saying
'&&' and '||'. The following shows two open propositional
statements connected together with a single disjunctive connective.</para>
<programlisting>
- <![CDATA[
+
person.getEyeColor().equals("blue") || person.getEyeColor().equals("green")
- ]]>
+
</programlisting>
<para>This can be expressed using a disjunctive Conditional Element
@@ -265,9 +265,9 @@
represent the two possible logic outcomes.</para>
<programlisting>
- <![CDATA[
+
Person( eyeColour == "blue" ) || Person( eyeColor == "green" )
- ]]>
+
</programlisting>
<para>Disjunctive field constraints connectives could also be used -
@@ -275,21 +275,21 @@
result in multiple rule generation.</para>
<programlisting>
- <![CDATA[
+
Person( eyeColour == "blue"||"green" )
- ]]>
+
</programlisting>
- <para>Propositional Logic is not Turing complete, limiting the problems
- you can define, because it cannot express criteria
- for the structure of data. First Order Logic (FOL), or Predicate Logic,
- extends Propositional Logic with two new quantifier concepts to allow
- expressions defining structure - specifically universal and existential
- quantifiers. Universal quantifiers allow you to check that something is
- true for everything; normally supported by the 'forall' conditional
- element, but not yet implemented in Drools 3.0. Existential quantifiers
- check for the existence of something, in that it occurs at least once -
- this is supported with 'not' and 'exists' conditional elements.</para>
+ <para>Propositional Logic is not Turing complete, limiting the problems
+ you can define, because it cannot express criteria for the structure of
+ data. First Order Logic (FOL), or Predicate Logic, extends Propositional
+ Logic with two new quantifier concepts to allow expressions defining
+ structure - specifically universal and existential quantifiers. Universal
+ quantifiers allow you to check that something is true for everything;
+ normally supported by the 'forall' conditional element, but not yet
+ implemented in Drools 3.0. Existential quantifiers check for the existence
+ of something, in that it occurs at least once - this is supported with
+ 'not' and 'exists' conditional elements.</para>
<para>Imagine we have two classes - Student and Module. Module represents
each of the courses the Student attended for that semester, referenced by
@@ -300,23 +300,23 @@
for the specified criteria.</para>
<programlisting>
- <![CDATA[
+
public class Student {
private String name;
private List modules;
...
}
- ]]>
+
</programlisting>
<programlisting>
- <![CDATA[
+
public class Module {
private String name;
private String studentName;
private int score;
- ]]>
+
</programlisting>
<para>Java is Turing complete in that you can write code, among other
@@ -324,30 +324,30 @@
should return a List of students who have failed the semester.</para>
<programlisting>
- <![CDATA[
+
List failedStudents = new ArrayList();
for ( Iterator studentIter = students.iterator(); studentIter.hasNext() {
Student student = ( Student ) studentIter.next();
for ( Iterator it = student.getModules.iterator(); it.hasNext(); ) {
Module module = ( Module ) it.next();
- if ( module.getScore() < 40 ) {
+ if ( module.getScore() < 40 ) {
failedStudents.add( student ) ;
break;
}
}
}
- ]]>
+
</programlisting>
<para>Early SQL implementations were not Turing complete as they did not
- provide quantifiers to access the structure of data. Modern SQL
- engines do allow nesting of SQL, which can be combined with keywords like
- 'exists' and 'in'. The following show SQL and a Rule to return a set of Students who
- have failed the semester.</para>
+ provide quantifiers to access the structure of data. Modern SQL engines do
+ allow nesting of SQL, which can be combined with keywords like 'exists'
+ and 'in'. The following show SQL and a Rule to return a set of Students
+ who have failed the semester.</para>
<programlisting>
-<![CDATA[
+
select
*
from
@@ -359,19 +359,19 @@
Modules m
where
m.student_name = s.name and
- m.score < 40
+ m.score < 40
)
-]]>
+
</programlisting>
<para></para>
<programlisting>
-<![CDATA[
+
rule "Failed_Students"
when
- exists( $student : Student() && Module( student == $student, score < 40 ) )
-]]>
+ exists( $student : Student() && Module( student == $student, score < 40 ) )
+
</programlisting>
<para></para>
Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-The_Drools_Rule_Engine.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-The_Drools_Rule_Engine.xml 2007-08-11 15:27:39 UTC (rev 14158)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-The_Drools_Rule_Engine.xml 2007-08-11 17:33:08 UTC (rev 14159)
@@ -8,13 +8,13 @@
<para>Drools is split into two main parts: Authoring and Runtime.</para>
<para>The authoring process involves the creation of DRL or XML files for
- rules which are fed into a parser - defined by an Antlr 3 grammer. The
- parser checks for correctly formed grammer and produces an intermediate
+ rules which are fed into a parser - defined by an Antlr 3 grammar. The
+ parser checks for correctly formed grammar and produces an intermediate
structure for the "descr"; where the "descr" indicates the AST that
"describes" the rules. The AST is then passed to the Package Builder which
produces Packages. Package Builder also undertakes any code generation and
compilation that is necessary for the creation of the Pacakge. A Packge
- object is self contained and deployeable, in that it's a serialized object
+ object is self contained and deployable, in that it's a serialized object
consisting of one or more rules.</para>
<figure>
@@ -110,7 +110,7 @@
PackageBuilderErrors errors = builder.getErrors();</programlisting>
</example>
- <para>PackagBuilder is configurable using PackageBuilderConfiguration
+ <para>PackageBuilder is configurable using PackageBuilderConfiguration
class.</para>
<figure>
@@ -485,7 +485,7 @@
<programlisting>List list = new ArrayList();
session.setGlobal("list", list); </programlisting>
- <para>f a rule evaluates on a global before you set it you will get a
+ <para>If a rule evaluates on a global before you set it you will get a
NullPointerException.</para>
</section>
@@ -518,8 +518,7 @@
<para>Drools 4.0 has full support for Shadow Facts implemented as
transparent lazy proxies. Shadow facts are enable by default and are not
- visible from external code, not even inside code blocks on rules.
- </para>
+ visible from external code, not even inside code blocks on rules.</para>
<para>Although shadow facts are a great way of ensuring the engine
integrity, they add some overhead to the the reasoning process. As so,
@@ -715,7 +714,7 @@
</figure>
<para>The Agenda is a RETE feature. During a Working Memory Action rules
- may become fully matched and legible for execution; a single Working
+ may become fully matched and elegible for execution; a single Working
Memory Action can result in multiple eligible rules. When a rule is fully
matched an Activation is created, referencing the Rule and the matched
facts, and placed onto the Agenda. The Agenda controls the execution order
@@ -959,7 +958,7 @@
<para>If you have followed this far, you will note that truth
maintenance, like logical assertions, allows rules to behave a little
like a human would, and can certainly make the rules more
- managable.</para>
+ manageable.</para>
</section>
<section>
@@ -989,7 +988,7 @@
concern.</para>
<para>There are three types of event listeners -
- WorkingMemoryEventListener, AgendEventListener
+ WorkingMemoryEventListener, AgendaEventListener
RuleFlowEventListener.</para>
<figure>
Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-What_is_a_Rule_Engine.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-What_is_a_Rule_Engine.xml 2007-08-11 15:27:39 UTC (rev 14158)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-What_is_a_Rule_Engine.xml 2007-08-11 17:33:08 UTC (rev 14159)
@@ -119,7 +119,7 @@
matches against the <indexterm>
<primary>WorkingMemory</primary>
</indexterm> Working Memory. Facts are asserted into the Working Memory
- where they may then be modiied or retracted. A system with a large number
+ 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 conflicuting rules using a Conflict Resolution
@@ -196,7 +196,7 @@
for conclusions that it can, known as 'sub goals', 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 sub goals.
- Prolog is an example of a Backward Chaining engine; Drools will adding
+ Prolog is an example of a Backward Chaining engine; Drools will be adding
support for Backward Chaining in its next major release.</para>
<figure>
Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Why_use_a_Rule_Engine.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Why_use_a_Rule_Engine.xml 2007-08-11 15:27:39 UTC (rev 14158)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-Why_use_a_Rule_Engine.xml 2007-08-11 17:33:08 UTC (rev 14159)
@@ -10,17 +10,15 @@
</listitem>
<listitem>
- <para>What advantage does a rules engine have over hand coded "if...then"
- approaches?</para>
+ <para>What advantage does a rules 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>
+ like <indexterm>
<primary>BeanShell</primary>
- </indexterm>
- BeanShell?</para>
+ </indexterm> BeanShell?</para>
</listitem>
</orderedlist>
@@ -36,32 +34,30 @@
<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 then code).
- </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 then
+ code).</para>
- <para>Rule systems are capable of solving very, very hard problems,
- providing an explination 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>
+ <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 layed out in
- rules. This can be espically 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>
+ 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>
@@ -78,7 +74,7 @@
<listitem>
<para>Centralization of Knowledge</para>
- <para>By using rules, you create a repository of knowlegde (a
+ <para>By using rules, you create a repository of knowledge (a
knowledgebase) 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>
@@ -97,21 +93,20 @@
<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>
+ 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
+ <para>By creating object models and optionally Domain Specific
Languages that model your problem domain you can set yourself up to
- write rules that look 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. (as all the program plumbing,
- the "How", is in the usual code, hidden away).
- </para>
+ write rules that look 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. (as all the
+ program plumbing, the "How", is in the usual code, hidden
+ away).</para>
</listitem>
</itemizedlist>
</section>
@@ -122,56 +117,52 @@
<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>
+ "traditional" approach is possibly one of the following: <itemizedlist>
<listitem>
<para>The problem is just too fiddly for traditional code.</para>
-
- <para>The problem may not be complex, but you can't see a
- non-fragile way of building it.
- </para>
+
+ <para>The problem may not be complex, but you can't see a
+ non-fragile way of building it.</para>
</listitem>
-
+
<listitem>
<para>The problem is beyond any obvious algorithm based
- solution.
- </para>
-
+ 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>
+ understood.</para>
</listitem>
-
+
<listitem>
<para>The logic changes often</para>
-
+
<para>The logic itself may be simple (but doesn't have to be) but
the rules change quite often. In many organizations software
releases are few and far between and rules can help provide the
- "agility" that is needed and expected in a reasonably
- safe way.</para>
+ "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 are often 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 "soft" 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>
+
+ <para>Domain experts are often 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 "soft" 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>
+ </itemizedlist></para>
- <para>If rules are a new technology for your project teams,
- the overhead in getting going must be factored in. Its not a trivial
- technology, but this document tries to make it easier to understand.</para>
+ <para>If rules are a new technology for your project teams, the overhead
+ in getting going must be factored in. Its 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 (what that means of course
@@ -179,24 +170,24 @@
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 "if", "else", "switch", an
- over abundance of strategy patterns and/or other messy logic in your code that
- just doesn't feel right (and you keep coming back to fix it - either because
- you got it wrong, or the logic/your understanding changes) - think about
- using rules. If you are faced with tough problems of which there are no
- algorithms or patterns for, consider using rules.
- </para>
+ the application. If you ever notice lots of "if", "else", "switch", an
+ over abundance of strategy patterns and/or other messy logic in your code
+ that just doesn't feel right (and you keep coming back to fix it - either
+ because you got it wrong, or the logic/your understanding changes) - think
+ about using rules. If you are faced with tough problems of which there are
+ no algorithms or patterns for, consider using rules.</para>
<para>Rules could be used embedded in your application or perhaps as a
service. Often rules work best as "stateful" component - hence they are
often an integral part of an application. However, there have been
- successful cases of creating reusable rule services which are stateless.</para>
+ successful cases of creating reusable rule services which are
+ stateless.</para>
<para>In your organization it is important to think 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 - often
- they are out of the control of the application vendors/project teams).
- </para>
+ will use for updating rules in systems that are in production (the options
+ are many, but different organizations have different requirements - often
+ they are out of the control of the application vendors/project
+ teams).</para>
</section>
<section>
@@ -225,17 +216,17 @@
<section>
<title>Scripting or Process Engines</title>
- <para>Hopefully the preceeding sections have explained when you may want
- to use a rule engine.</para>
+ <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 dynamicness
- for "changes on the fly" (there are many solutions here). </para>
+ for "changes on the fly" (there are many solutions here).</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 point which are in themselves a simple
- rule. Process engines and rules often can work nicely together, so its not
- an either-or proposition.</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 point which are in
+ themselves a simple rule. Process engines and rules often can work nicely
+ together, so it is not an either-or proposition.</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
@@ -259,21 +250,20 @@
<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 etc.; in other words there is a clear
- (probably obvious) chain of logic. If your rules are all strongly coupled,
- the chances are that the rules will have future inflexibility, and more
- significantly, that perhaps a rule engine is overkill (as the logic is a
- clear chain of rules - and can be hard coded. [A Decision Tree may be in order]).
- This is not to say that strong or weak coupling is inherently bad, but it is a
- point to keep in mind when considering a rule engine and in how 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
- rules that are unrelated.
- </para>
-
+ 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 etc.; in other words
+ there is a clear (probably obvious) chain of logic. If your rules are all
+ strongly coupled, the chances are that the rules will have future
+ inflexibility, and more significantly, that perhaps a rule engine is
+ overkill (as the logic is a clear chain of rules - and can be hard coded.
+ [A Decision Tree may be in order]). This is not to say that strong or weak
+ coupling is inherently bad, but it is a point to keep in mind when
+ considering a rule engine and in how 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 rules that are
+ unrelated.</para>
</section>
-</section>
+</section>
\ No newline at end of file
More information about the jboss-svn-commits
mailing list