[jboss-svn-commits] JBL Code SVN: r20880 - labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Wed Jul 2 08:45:32 EDT 2008
Author: KrisVerlaenen
Date: 2008-07-02 08:45:32 -0400 (Wed, 02 Jul 2008)
New Revision: 20880
Added:
labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/assignment.bmp
labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/audit.bmp
labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/constraints.bmp
labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/dynamicLogging.bmp
labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/loading.bmp
labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/orderProcess.bmp
labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/validation.bmp
Modified:
labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/Chapter-RulesAndProcesses.xml
Log:
- Drools flow documentation
Modified: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/Chapter-RulesAndProcesses.xml
===================================================================
--- labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/Chapter-RulesAndProcesses.xml 2008-07-02 12:00:10 UTC (rev 20879)
+++ labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/Chapter-RulesAndProcesses.xml 2008-07-02 12:45:32 UTC (rev 20880)
@@ -9,33 +9,49 @@
<section>
<title>Why use rules in processes?</title>
<para>
+ Workflow languages that depend purely on process constructs (like nodes and connections) to describe
+ the business logic of (a part of) an application tend to be quite complex. While these workflow
+ constructs are very well suited to describe the overall control flow of an application, it can be
+ very difficult to describe complex logic and exceptional situations. Therefore, executable processes
+ tend to become very complex. We believe that, by extending a process engine with support for declarative
+ rules in combination with these regular process constructs, this complexity can be kept under control.
<orderedlist>
<listitem>
- <para>Simplicity: Complex decisions are sometimes easier to specify using rules</para>
+ <para>Simplicity: Complex decisions are usually easier to specify using a set of rules. Rules can
+ describe complex business logic more easily by using an advanced constraint language. Multiple
+ rules can be combined, each describing a part of the business logic.</para>
</listitem>
<listitem>
- <para>Separate life cycle => Agility: Change rules without having to change process</para>
+ <para>Agility: Rules and processes can have a separate life cycle. This means that for example
+ we can change the rules describing some crucial decision points without having to change the process
+ itself. Rules can be added, removed or modified to fine-tune the behaviour of the process to the
+ constantly evolving requirements and environment.</para>
</listitem>
<listitem>
- <para>Different scope: Rules can be reused accross processes or outside processes</para>
+ <para>Different scope: Rules can be reused accross processes or outside processes. Therefore, your
+ business logic is not locked inside your processes.</para>
</listitem>
<listitem>
- <para>Declarative: Focus on what instead of how, rules are additive</para>
+ <para>Declarative: Focus on describing 'what' instead of 'how'.</para>
</listitem>
<listitem>
- <para>Granularity: Easy to write rules for specific circumstances, processes should be more generic</para>
+ <para>Granularity: It is easy to write simple rules that handle specific circumstances. Processes
+ more suited to describe the overall control flow but tend to become very complex if they also need
+ to describe a lot of exceptional situations.</para>
</listitem>
<listitem>
- <para>Data-centric: Rules can easily handle large data sets</para>
+ <para>Data-centric: Rules can easily handle large data sets.</para>
</listitem>
<listitem>
- <para>Performance: Rule evaluation is optimized</para>
+ <para>Performance: Rule evaluation is optimized.</para>
</listitem>
<listitem>
- <para>Advanced condition and action language: Supports advanced features like custom functions, collections, not, exists, for all, etc.</para>
+ <para>Advanced condition and action language: Rule languages supports advanced features like custom
+ functions, collections, not, exists, for all, etc.</para>
</listitem>
<listitem>
- <para>Higher-level: Using DSLs, business editors, decision tables, decision trees, etc.</para>
+ <para>Higher-level: Using DSLs, business editors, decision tables, decision trees, etc. your business
+ logic could be described in a way that can be understood (and possibly even modified) by business users.</para>
</listitem>
</orderedlist>
</para>
@@ -44,24 +60,26 @@
<section>
<title>Why integrate rules and processes in a single engine?</title>
<para>
+ Drools Flow combines a process and a rules engine in one software product. This offers several advantages
+ (compared to trying to loosely coupling an existing process and rules product):
<orderedlist>
<listitem>
- <para>Simplicity: Easier for end user to use both rules and processes</para>
+ <para>Simplicity: Easier for end user to combine both rules and processes.</para>
</listitem>
<listitem>
- <para>Encapsulation: Sometimes close integration between processes and rules is beneficial</para>
+ <para>Encapsulation: Sometimes close integration between processes and rules is beneficial.</para>
</listitem>
<listitem>
<para>Performance: No unnecessary passing, transformation or synchronization of data</para>
</listitem>
<listitem>
- <para>Learning curve: Easier to learn one product</para>
+ <para>Learning curve: Easier to learn one product.</para>
</listitem>
<listitem>
- <para>Manageability: Easier to manage one product, rules and processes can be similar artefacts in a larger knowledge repository</para>
+ <para>Manageability: Easier to manage one product, rules and processes can be similar artefacts in a larger knowledge repository.</para>
</listitem>
<listitem>
- <para>Integration of features: Audit log, IDE, Web-based management platform, Repository, Debugging, etc.</para>
+ <para>Integration of features: We provide an integrated IDE, audit log, web-based management platform, repository, debugging, etc.</para>
</listitem>
</orderedlist>
</para>
@@ -70,19 +88,109 @@
<section>
<title>Approach</title>
<para>
+ Workflow languages describe the order in which activities should be performed using a flow chart.
+ A process engine is responsible for selecting which activities should be executed based on the current
+ state of the executing processes.
+ Rules on the other hand are composed of a set of conditions that describe when a rule is applicable
+ and an action that is executed when the rule is applicable. The rules engine is then responsible for
+ evaluating and executing the rules. It decides which rules need to be executed based on the current
+ state of the application.
</para>
+
+ <para>
+ Workflow processes are very good at describing the overall control flow of (possibly long-running)
+ applications. However, processes that are used to define complex business decisions or contain a lot
+ of exceptional situations or need to respond to various external events tend to become very complex.
+ Rules on the other hand are very good at describing complex decisions and reasoning about large amounts
+ of data or events. It is however not trivial to define long-running processes using rules.
+ </para>
+
+ <para>
+ In the past, users were forced to choose between defining their business logic using either a process
+ or rules engine. Problems that required complex reasoning about large amounts of data used a rules engine,
+ while users that wanted to focus on describing the control flow of their processes were forced to use a
+ process engine. However, businesses nowadays might want to combine both processes and rules in order to
+ be able to define all their business logic in the format that best suits their needs.
+ </para>
+
+ <para>
+ Basically, both a rules and a process engine will derive the next steps that need to be executed by
+ looking at its knowledge base (a set of rules or processes respectively) and the current known state
+ of the application (the data in the working memory or the state of the executing process instances
+ respectively). If we want to integrate rules and processes, we need an engine that can decide the next
+ steps taking into account the logic that is defined inside both the processes and the rules.
+ </para>
+
+ <section>
+ <title>Teaching a rules engine about processes</title>
+ <para>
+ It is very difficult (and probably very inefficient as well) to extend a process engine to also take
+ rules into account: the process engine would need to check for rules that might need to be executed
+ at every step and would have to keep the data that is used by the rules engine up to date. However,
+ it is not that difficult to 'teach' a rules engine about processes. If the current state of the processes
+ is also inserted as part of the data the rules engine reasons about, and we 'learn' the rules engine how
+ to derive the next steps of an executing process, the rules engine will then be able to derive the next steps
+ taking both rules and processes into account.
+ </para>
+ </section>
+
+ <section>
+ <title>Inversion of control</title>
+ <para>
+ From the process perspective, this means that there is an inversion of control. In a normal
+ proces engine, the engine is in full control and derives the next steps based on the current state of the
+ process instance. If needed, it can contact external services to retrieve additional information (e.g. invoke
+ a rules engine to request a decision), but it solely decides which steps to take, and is responsible for executing
+ these steps.
+ </para>
+
+ <para>
+ However, only our extended rules engine (that can reason about both rules and processes) is capable of deriving the next
+ steps taking both rules and processes into account. If a part of the process needs to be executed, the rules engine
+ will request the process engine to execute this step. Once this step has been performed, the process engine returns
+ control to the rules engine to again derive the next steps. This means that the control on what to do next has been
+ inverted: the process engine itself no longer decides the next step to take but our extended rules engine will be in
+ control, notifying the process engine when to execute the next step.
+ </para>
+ </section>
+
</section>
<section>
- <title>Examples</title>
+ <title>Example</title>
+ <para>
+ The drools-examples project contains a sample process (org.drools.examples.process.order)
+ that illustrates some of the advantages of being able to combine processes and rules. This
+ process describes an order application where incoming orders are validated, possible discount
+ are calculated and shipping of the goods is requested.
+ </para>
+ <mediaobject>
+ <imageobject>
+ <imagedata align="center" format="BMP" role=""
+ fileref="orderProcess.bmp"/>
+ </imageobject>
+ </mediaobject>
+
<section>
<title>Evaluating a set of rules in your process</title>
- <para>This example evaluates a set of rules as part of the process.
+ <para>Drools Flow can easily include a set of rules as part of the process.
The rules that need to be evaluated should be grouped in a ruleflow
group (using the ruleflow-group rule attribute) and a RuleSet node
- can be used to trigger the evaluation of these rules in your process.</para>
+ can be used to trigger the evaluation of these rules in your process. This example
+ uses two RuleSet nodes in the process: one for the validation of the order
+ and one for calculating the discount. For example, one of the rules for validiting
+ an order looks like this (note the ruleflow-group attribute, which makes sure that
+ this rule is evaluated as part of the RuleSet node with the same ruleflow-group):</para>
+
+ <mediaobject>
+ <imageobject>
+ <imagedata align="center" format="BMP" role=""
+ fileref="validation.bmp"/>
+ </imageobject>
+ </mediaobject>
+
</section>
<section>
@@ -91,7 +199,20 @@
in your process. For example, when a decision should be made which execution
paths should be selected at a split, rules could be used to define these
conditions. Similarly, a wait state could use a rule to define how long
- to wait.</para>
+ to wait. This example uses rules for deciding the next action after validating
+ the order. If the order contains errors, a sales representative should try to
+ correct the order. Orders with a value > 1000$ are more important and a senior
+ sales representative should follow up the order. All other orders should just
+ proceed normally. An decision node is used to select one of these alternatives,
+ and rules are used to describe the constraints for each of them:</para>
+
+ <mediaobject>
+ <imageobject>
+ <imagedata align="center" format="BMP" role=""
+ fileref="constraints.bmp"/>
+ </imageobject>
+ </mediaobject>
+
</section>
<section>
@@ -102,6 +223,14 @@
describe how to the actor based on this information. These assignment rules
will then be applied automatically whenever a new human task needs to be
executed.</para>
+
+ <mediaobject>
+ <imageobject>
+ <imagedata align="center" format="BMP" role=""
+ fileref="assignment.bmp"/>
+ </imageobject>
+ </mediaobject>
+
</section>
<section>
@@ -130,15 +259,72 @@
<section>
<title>Using rules to dynamically alter the behaviour of the process</title>
- <para>If a problem is encountered at runtime with one of the processes, new rules
- could be added at runtime to for example log additional information or handle
- specific cases of the process. Once the problem is solved (e.g. an improved
- process has been deployed), these rules can easily be removed again. Based on
- current circumstances, different strategies could be selected dynamically,
- for example based on the current load of all the services, rules could be used
- to optimize the process to the current load.</para>
+ <para>Rules can be used to dynamically fine-tune the behaviour of your processes.
+ For example, if a problem is encountered at runtime with one of the processes, new rules
+ could be added at runtime to log additional information or handle
+ specific cases of the process. Once the problem is solved or the circumstances have
+ changed, these rules can easily be removed again. Based on
+ the current status, different strategies could be selected dynamically.
+ For example, based on the current load of all the services, rules could be used
+ to optimize the process to the current load. This process contains a simple example
+ that allows you to dynamically add or remove logging for the 'Check Order' task. When the
+ 'Debugging output' checkbox in the main application window is checked, a rule is dynamically
+ loaded to add a logging statement to the console whenever the 'Check Order' task is requested.
+ Unchecking the box will dynamically remove the rule again.
+ </para>
+
+ <mediaobject>
+ <imageobject>
+ <imagedata align="center" format="BMP" role=""
+ fileref="dynamicLogging.bmp"/>
+ </imageobject>
+ </mediaobject>
+
</section>
+ <section>
+ <title>Integrated tooling</title>
+ <para>Processes and rules are integrated in the Drools Eclipse IDE. Both processes and rules
+ are simply considered as different types of business logic, but are managed almost identical.
+ For example, loading a process or a set of rules into the engine is very similar:</para>
+
+ <mediaobject>
+ <imageobject>
+ <imagedata align="center" format="BMP" role=""
+ fileref="loading.bmp"/>
+ </imageobject>
+ </mediaobject>
+
+ <para>Our audit log also contains an integrated view, showing how rules and processes are influencing
+ each other. For example, a part of the log shows how the '5% discount' rule is executed as part of the
+ 'Calculate Discount' node.</para>
+
+ <mediaobject>
+ <imageobject>
+ <imagedata align="center" format="BMP" role=""
+ fileref="audit.bmp"/>
+ </imageobject>
+ </mediaobject>
+
+ </section>
+
+ <section>
+ <title>Domain-specific rules and processes</title>
+ <para>Rules do not need to be defined using the core rule language syntax, but they also can be defined
+ using our more advanced rule editors like domain-specific languages, decision tables, guided editors, etc.
+ Our examples defines a domain-specific language for describing assignment rules, based on the type of
+ task, its properties, the process it is defined in, etc. This makes the assignment rules much more
+ understandable for non-experts.</para>
+
+ <mediaobject>
+ <imageobject>
+ <imagedata align="center" format="BMP" role=""
+ fileref="assignment.bmp"/>
+ </imageobject>
+ </mediaobject>
+
+ </section>
+
</section>
</chapter>
Added: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/assignment.bmp
===================================================================
(Binary files differ)
Property changes on: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/assignment.bmp
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/audit.bmp
===================================================================
(Binary files differ)
Property changes on: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/audit.bmp
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/constraints.bmp
===================================================================
(Binary files differ)
Property changes on: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/constraints.bmp
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/dynamicLogging.bmp
===================================================================
(Binary files differ)
Property changes on: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/dynamicLogging.bmp
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/loading.bmp
===================================================================
(Binary files differ)
Property changes on: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/loading.bmp
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/orderProcess.bmp
===================================================================
(Binary files differ)
Property changes on: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/orderProcess.bmp
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/validation.bmp
===================================================================
(Binary files differ)
Property changes on: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-RulesAndProcesses/validation.bmp
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
More information about the jboss-svn-commits
mailing list