[jboss-svn-commits] JBL Code SVN: r20735 - labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-DomainSpecificProcesses.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Tue Jun 24 11:38:36 EDT 2008
Author: KrisVerlaenen
Date: 2008-06-24 11:38:36 -0400 (Tue, 24 Jun 2008)
New Revision: 20735
Added:
labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-DomainSpecificProcesses/CDSSExample.bmp
labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-DomainSpecificProcesses/NotificationPalette.bmp
Modified:
labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-DomainSpecificProcesses/Chapter-DomainSpecificProcesses.xml
Log:
drools flow docs
Added: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-DomainSpecificProcesses/CDSSExample.bmp
===================================================================
(Binary files differ)
Property changes on: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-DomainSpecificProcesses/CDSSExample.bmp
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Modified: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-DomainSpecificProcesses/Chapter-DomainSpecificProcesses.xml
===================================================================
--- labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-DomainSpecificProcesses/Chapter-DomainSpecificProcesses.xml 2008-06-24 14:35:35 UTC (rev 20734)
+++ labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-DomainSpecificProcesses/Chapter-DomainSpecificProcesses.xml 2008-06-24 15:38:36 UTC (rev 20735)
@@ -1,10 +1,205 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude" >
<title>Domain-specific processes</title>
- <para></para>
+<section>
+ <title>Introduction</title>
+
+<para>One of the goals of our unified rules and processes framework is to allow users to extend the default programming constructs with domain-specific extensions that simplify development in a particular application domain. While Drools has been offering constructs to create domain-specific rule languages for some time now, this tutorial describes our first steps towards domain-specific process languages.
+</para>
+
+<para>Most process languages offer some generic action (node) construct that allows plugging in custum user actions. However, these actions are usually low-level, where the user is required to write custom code to implement the work that should be incorporated in the process. The code is also closely linked to a specific target environment, making it difficult to reuse the process in different contexts.
+</para>
+
+<para>Domain-specific languages are targeted to one particular application domain and therefore can offer constructs that are closely related to the problem the user is trying to solve. This makes the processes and easier to understand and self-documenting. We will show you how to define domain-specific work items, which represent atomic units of work that need to be executed. These work items specify the work that should be executed in the context of a process in a declarative manner, i.e. specifying what should be executed (and not how) on a higher level (no code) and hiding implementation details.
+</para>
+
+<para>So we want work items that are:
+ <orderedlist>
+ <listitem>
+ <para>domain-specific</para>
+ </listitem>
+ <listitem>
+ <para>declarative (what, not how)</para>
+ </listitem>
+ <listitem>
+ <para>high-level (no code)</para>
+ </listitem>
+ <listitem>
+ <para>customizable to the context</para>
+ </listitem>
+ </orderedlist>
+</para>
+
+<para>Users can easily define their own set of domain-specific work items and integrate them in our process language(s). For example, the next figure shows an example of a process in a healthcare context. The process includes domain-specific work items for ordering nursing tasks (e.g. measuring blood pressure), prescribing medication and notifying care providers.</para>
+
+<mediaobject>
+ <imageobject>
+ <imagedata align="center" format="BMP" role=""
+ fileref="CDSSExample.bmp"/>
+ </imageobject>
+</mediaobject>
+</section>
+
<section>
- <title>Pluggable work items</title>
+ <title>Example: Notifications</title>
+
+<para>Let's start by showing you how to include a simple work item for sending notifications. A work item represent an atomic unit of work in a declarative way. It is defined by a unique name and additional parameters that can be used to describe the work in more detail. Work items can also return information after they have been executed, specified as results. Our notification work item could thus be defined using a work definition with four parameters and no results:</para>
+
+<programlisting>
+ Name: "Notification"
+ Parameters
+ From [String]
+ To [String]
+ Message [String]
+ Priority [String]
+</programlisting>
+
+ <section>
+ <title>Creating the work definition</title>
+
+<para>All work definitions must be specified in one or more configuration files in the project classpath, where all the properties are specified as name-value pairs. Parameters and results are maps where each parameter name is also mapped to the expected data type. Note that this configuration file also includes some additional user interface information, like the icon and the display name of the work item. (We use MVEL for reading in the configuration file, which allows us to do more advanced configuration files). Our MyWorkDefinitions.conf file looks like this:</para>
+
+<programlisting>
+import org.drools.process.core.datatype.impl.type.StringDataType;
+[
+ // the Notification work item
+ [
+ "name" : "Notification",
+ "parameters" : [
+ "Message" : new StringDataType(),
+ "From" : new StringDataType(),
+ "To" : new StringDataType(),
+ "Priority" : new StringDataType(),
+ ],
+ "displayName" : "Notification",
+ "icon" : "icons/notification.gif"
+ ]
+
+ // add more work items here ...
+]
+</programlisting>
+
</section>
+ <section>
+ <title>Registering the work definition</title>
+
+<para>The Drools Configuration API can be used to register work definition files for your project using the drools.workDefinitions property, which represents a list of files containing work definitions (separated usings spaces). For example, include a drools.rulebase.conf file in the META-INF directory of your project and add the following line:</para>
+
+<programlisting>
+ drools.workDefinitions = MyWorkDefinitions.conf
+</programlisting>
+
+ </section>
+
+ <section>
+ <title>Using your new work item in your processes</title>
+
+<para>Once our work definition has been created and registered, we can start using it in our processes. The process editor contains a separate section in the palette where the different work items that have been defined for the project appear.</para>
+
+<mediaobject>
+ <imageobject>
+ <imagedata align="center" format="BMP" role=""
+ fileref="NotificationPalette.bmp"/>
+ </imageobject>
+</mediaobject>
+
+<para>Using drag and drop, a notification node can be created inside your process. The properties can be filled in using the properties view.</para>
+
+<para>Apart from the properties defined by for this work item, all work items also have these three properties:</para>
+<orderedlist>
+ <listitem>
+ <para>Parameter Mapping: Allows you map the value of a variable in the process to a parameter of the work item. This allows you to customize the work item based on the current state of the actual process instance (for example, the priority of the notification could be dependent of some process-specific information).</para>
+ </listitem>
+ <listitem>
+ <para>Result Mapping: Allows you to map a result (returned once a work item has been executed) to a variable of the process. This allows you to use results in the remainder of the process.</para>
+ </listitem>
+ <listitem>
+ <para>Wait for completion: By default, the process waits until the requested work item has been completed before continuing with the process. It is also possible to continue immediately after the work item has been requested (and not waiting for the results) by setting "wait for completion" to false.</para>
+ </listitem>
+</orderedlist>
+
+ </section>
+
+ <section>
+ <title>Executing work items</title>
+
+<para>The Drools engine contains a WorkItemManager that is responsible for executing work items whenever necessary. The WorkItemManager is responsible for delegating the work items to WorkItemHandlers that execute the work item and notify the WorkItemManager when the work item has been completed. For executing notification work items, a NotificationWorkItemHandler should be created (implementing the WorkItemHandler interface):</para>
+
+<programlisting>
+package com.sample;
+
+import org.drools.process.instance.WorkItem;
+import org.drools.process.instance.WorkItemHandler;
+import org.drools.process.instance.WorkItemManager;
+
+public class NotificationWorkItemHandler implements WorkItemHandler {
+
+ public void executeWorkItem(WorkItem workItem, WorkItemManager manager) {
+ // extract parameters
+ String from = (String) workItem.getParameter("From");
+ String to = (String) workItem.getParameter("To");
+ String message = (String) workItem.getParameter("Message");
+ String priority = (String) workItem.getParameter("Priority");
+ // send email
+ EmailService service = ServiceRegistry.getInstance().getEmailService();
+ service.sendEmail(from, to, "Notification", message);
+ // notify manager that work item has been completed
+ manager.completeWorkItem(workItem.getId(), null);
+ }
+
+ public void abortWorkItem(WorkItem workItem, WorkItemManager manager) {
+ // Do nothing, notifications cannot be aborted
+ }
+
+}
+</programlisting>
+
+<para>This WorkItemHandler sends a notification as an email and then immediate notifies the WorkItemManager that the work item has been completed. Note that not all work items can be completed directly. In cases where executing a work item takes some time, execution can continue asynchronously and the work item manager can be notified later. In these situations, it might also be possible that a work item is being aborted before it has been completed. The abort method can be used to specify how to abort such work items.</para>
+
+<para>WorkItemHandlers should be registered at the WorkItemManager, using the following API:</para>
+
+<programlisting>
+ workingMemory.getWorkItemManager().registerWorkItemHandler(
+ "Notification", new NotificationWorkItemHandler());
+</programlisting>
+
+<para>Decoupling the execution of work items from the process itself has the following advantages:</para>
+<orderedlist>
+ <listitem>
+ <para>The process is more declarative, specifying what should be executed, not how.</para>
+ </listitem>
+ <listitem>
+ <para>Changes to the environment can be implemented by adapting the work item handler. The process itself should not be changed. It is also possible to use the same process in different environments, where the work item handler is responsible for integrating with the right services.</para>
+ </listitem>
+ <listitem>
+ <para>It is easy to share work item handlers across processes and projects (which would be more difficult if the code would be embedded in the process itself).</para>
+ </listitem>
+ <listitem>
+ <para>Different work item handlers could be used depending on the context. For example, during testing or simulation, it might not be necessary to actually execute the work items. The next section shows an example of how to use specialized work item handlers during testing.</para>
+ </listitem>
+</orderedlist>
+
+ </section>
+
+</section>
+
+<section>
+ <title>Testing processes using work items</title>
+
+<para>Customizable execution depending on context,
+easier to manage changes in environment (by changing handler),
+sharing processes accross contexts (using different handlers),
+testing, simulation (custom test handlers)</para>
+
+</section>
+
+<section>
+ <title>Future</title>
+
+<para>Our process framework is based on the (already well-known) idea of a Process Virtual Machine (PVM), where the process framework can be used as a basis for multiple process languages. This allows users to more easily create their own process languages, where common services provided by the process framework (e.g. persistence, audit) can be (re)used by the process language designer. Processes are represented as a graph of nodes, each node describing a part of the process logic. Different types of nodes are used for expressing different kinds of functionality, like creating or merging parallel flows (split and join), invoking a sub process, invoking external services, etc. One of our goals is creating a truly pluggable process language, where language designers can easily plug in their own node implementations.</para>
+
+</section>
+
</chapter>
Added: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-DomainSpecificProcesses/NotificationPalette.bmp
===================================================================
(Binary files differ)
Property changes on: labs/jbossrules/trunk/drools-docs/drools-docs-flow/en/Chapter-DomainSpecificProcesses/NotificationPalette.bmp
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
More information about the jboss-svn-commits
mailing list