[jbpm-commits] JBoss JBPM SVN: r5052 - jbpm4/trunk/modules/devguide/src/main/docbook/en/modules.

do-not-reply at jboss.org do-not-reply at jboss.org
Wed Jun 17 08:36:35 EDT 2009


Author: tom.baeyens at jboss.com
Date: 2009-06-17 08:36:35 -0400 (Wed, 17 Jun 2009)
New Revision: 5052

Modified:
   jbpm4/trunk/modules/devguide/src/main/docbook/en/modules/ch03-Configuration.xml
   jbpm4/trunk/modules/devguide/src/main/docbook/en/modules/ch06-ProcessAnatomy.xml
   jbpm4/trunk/modules/devguide/src/main/docbook/en/modules/ch07-ImplementingAdvancedActivities.xml
Log:
JBPM-2306 updating dev guide

Modified: jbpm4/trunk/modules/devguide/src/main/docbook/en/modules/ch03-Configuration.xml
===================================================================
--- jbpm4/trunk/modules/devguide/src/main/docbook/en/modules/ch03-Configuration.xml	2009-06-17 12:35:36 UTC (rev 5051)
+++ jbpm4/trunk/modules/devguide/src/main/docbook/en/modules/ch03-Configuration.xml	2009-06-17 12:36:35 UTC (rev 5052)
@@ -1,76 +1,96 @@
 <chapter id="configuration">
   <title>Configuration</title>
   
-  <para>The userguide explains how to install jBPM into the most 
-  common runtime environments.  That is the most simple and convenient 
-  way to get started with jBPM. Please use those instructions.
-  These docs provide some background information for developers 
-  that want to understand more about the way how configurations are 
-  handled.  Use at your own risk :-)
-  </para>
-  <para>The jbpm.jar contains a number of default configuration 
-  files that can be imported by the user configuration file.  
-  </para>
-  <para>This way, it's easy to include 
-  or exclude features for users.  And also the configuration details are kept in 
-  the implementation so users that only import those configuration files 
-  will not be affected when we release changes in those configuration files. 
-  </para>
-  <para>Configuration files that can be imported by the user's <literal>jbpm.cfg.xml</literal>:</para>
-  <programlisting>jbpm.default.cfg.xml
-jbpm.identity.cfg.xml
-jbpm.jbossremote.cfg.xml
-jbpm.jobexecutor.cfg.xml
-jbpm.tx.hibernate.cfg.xml
-jbpm.tx.jta.cfg.xml</programlisting>
-  <para><literal>jbpm.default.cfg.xml</literal>: Contains the default configurations
-  like the services, the hibernate configuration (configured from resource jbpm.hibernate.cfg.xml), 
-  hibernate session factory, business calendar and so on.
-  </para>
-  <para>A typical configuration for standard java would look like this:
-  </para>
-  <programlisting>&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;
-
-&lt;jbpm-configuration&gt;
-
-  &lt;import resource=&quot;jbpm.default.cfg.xml&quot; /&gt;
-  &lt;import resource=&quot;jbpm.tx.hibernate.cfg.xml&quot; /&gt;
-  &lt;import resource=&quot;jbpm.jpdl.cfg.xml&quot; /&gt;
-  &lt;import resource=&quot;jbpm.identity.cfg.xml&quot; /&gt;
-  &lt;import resource=&quot;jbpm.jobexecutor.cfg.xml&quot; /&gt;
-
-&lt;/jbpm-configuration&gt;</programlisting>
-  <para>In a JTA environment, replace <literal>jbpm.tx.hibernate.cfg.xml</literal> 
-  with <literal>jbpm.tx.jta.cfg.xml</literal> </para>
-  <para>To customize any of these configurations users can just replace 
-  the import with the customized content in the <literal>jbpm.cfg.xml</literal>.
-  </para>
+  <section>
+    <title>Configuration basics</title>
+    
+    <para>The userguide explains how to install jBPM into the most 
+    common runtime environments.  That is the most simple and convenient 
+    way to get started with jBPM. Please use those instructions.
+    These docs provide some background information for developers 
+    that want to understand more about the way how configurations are 
+    handled.  Use at your own risk :-)
+    </para>
+    <para>The jbpm.jar contains a number of default configuration 
+    files that can be imported by the user configuration file.  
+    </para>
+    <para>This way, it's easy to include 
+    or exclude features for users.  And also the configuration details are kept in 
+    the implementation so users that only import those configuration files 
+    will not be affected when we release changes in those configuration files. 
+    </para>
+    <para>Configuration files that can be imported by the user's <literal>jbpm.cfg.xml</literal>:</para>
+    <itemizedlist>
+      <listitem>jbpm.default.cfg.xml</listitem>
+      <listitem>jbpm.identity.cfg.xml</listitem>
+      <listitem>jbpm.jbossremote.cfg.xml</listitem>
+      <listitem>jbpm.jobexecutor.cfg.xml</listitem>
+      <listitem>jbpm.tx.hibernate.cfg.xml</listitem>
+      <listitem>jbpm.tx.jta.cfg.xml</listitem>
+    </itemizedlist>
+    <para><literal>jbpm.default.cfg.xml</literal>: Contains the default configurations
+    like the services, the hibernate configuration (configured from resource jbpm.hibernate.cfg.xml), 
+    hibernate session factory, business calendar and so on.
+    </para>
+    <para>A typical configuration for standard java would look like this:
+    </para>
+    <programlisting>&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;
   
-  <para>The jbpm.jar contains also following hibernate mapping configuration files:</para>
-  <programlisting>jbpm.execution.hbm.xml
-jbpm.history.hbm.xml
-jbpm.identity.hbm.xml
-jbpm.repository.hbm.xml
-jbpm.task.hbm.xml
-jbpm.jpdl.hbm.xml</programlisting>
-  <para>These all map the java domain model objects to a relational database.
-  </para>
-  <para>Other various configuration files that are included in jbpm.jar:</para>
-  <programlisting>jbpm.task.lifecycle.xml
-jbpm.variable.types.xml
-jbpm.wire.bindings.xml
-jbpm.jpdl.activities.xml
-jbpm.jpdl.eventlisteners.xml</programlisting>
-
-  <para>To get started on the parsing for the configuration files, see
-  </para>
-  <itemizedlist>
-    <listitem>class org.jbpm.pvm.internal.env.JbpmConfigurationParser</listitem>
-    <listitem>resource modules/pvm/src/main/resources/jbpm.wire.bindings.xml</listitem>
-    <listitem>package modules/pvm/src/main/java/org/jbpm/pvm/internal/wire/binding</listitem>
-  </itemizedlist>
+  &lt;jbpm-configuration&gt;
   
-  <section>
+    &lt;import resource=&quot;jbpm.default.cfg.xml&quot; /&gt;
+    &lt;import resource=&quot;jbpm.tx.hibernate.cfg.xml&quot; /&gt;
+    &lt;import resource=&quot;jbpm.jpdl.cfg.xml&quot; /&gt;
+    &lt;import resource=&quot;jbpm.identity.cfg.xml&quot; /&gt;
+    &lt;import resource=&quot;jbpm.jobexecutor.cfg.xml&quot; /&gt;
+  
+  &lt;/jbpm-configuration&gt;</programlisting>
+  
+    <para>When you want to change the configuration, first consider 
+    to change an import with one of the other provided importable 
+    configuration files. 
+    </para>
+  
+    <para>For example, in a JTA environment, replace the import of 
+     <literal>jbpm.tx.hibernate.cfg.xml</literal> 
+    with <literal>jbpm.tx.jta.cfg.xml</literal> 
+    </para>
+    
+    <para>The second way to define a more customized configuration is to 
+    specify configuration items directly into the <literal>jbpm.cfg.xml</literal>.
+    For an example, see <xref linkend="customizingtheidentitycomponent" /> below.
+    The more you customize, the more likely you are doing things we didn't 
+    anticipate.
+    </para>
+    
+    <para>The jbpm.jar contains also following hibernate mapping configuration files:</para>
+    <programlisting>jbpm.execution.hbm.xml
+  jbpm.history.hbm.xml
+  jbpm.identity.hbm.xml
+  jbpm.repository.hbm.xml
+  jbpm.task.hbm.xml
+  jbpm.jpdl.hbm.xml</programlisting>
+    <para>These all map the java domain model objects to a relational database.
+    </para>
+    <para>Other various configuration files that are included in jbpm.jar:</para>
+    <programlisting>jbpm.task.lifecycle.xml
+  jbpm.variable.types.xml
+  jbpm.wire.bindings.xml
+  jbpm.jpdl.activities.xml
+  jbpm.jpdl.eventlisteners.xml</programlisting>
+  
+    <para>Normally it is not necessary to dive into the parsing itself.  It's most 
+    a matter of figuring out how to specify the configuration that you want :-)
+    But just in case: To get started on the parsing for the configuration files, see
+    </para>
+    <itemizedlist>
+      <listitem>class org.jbpm.pvm.internal.env.JbpmConfigurationParser</listitem>
+      <listitem>resource modules/pvm/src/main/resources/jbpm.wire.bindings.xml</listitem>
+      <listitem>package modules/pvm/src/main/java/org/jbpm/pvm/internal/wire/binding</listitem>
+    </itemizedlist>
+  </section>
+  
+  <section id="customizingtheidentitycomponent">
     <title>Customizing the identity component</title>
     <para>There are 2 identity components that we support out of the box:
     </para>

Modified: jbpm4/trunk/modules/devguide/src/main/docbook/en/modules/ch06-ProcessAnatomy.xml
===================================================================
--- jbpm4/trunk/modules/devguide/src/main/docbook/en/modules/ch06-ProcessAnatomy.xml	2009-06-17 12:35:36 UTC (rev 5051)
+++ jbpm4/trunk/modules/devguide/src/main/docbook/en/modules/ch06-ProcessAnatomy.xml	2009-06-17 12:36:35 UTC (rev 5052)
@@ -18,7 +18,12 @@
     <mediaobject><imageobject><imagedata align="center" fileref="images/process.anatomy.classes.png"/></imageobject></mediaobject>
   </figure>
   
-  <para>Next we'll show a series of example diagram structures that can be formed 
+  <para>By separating the structure of a process from the behaviour of the activities, 
+  any process model can be formed in the PVM.  It's up to the activity implementations 
+  to use this structure.  Activities can also impose restrictions on the diagram 
+  structures they can support.  Typically activities that control process concurrency
+  will impose restrictions on the process model structures that they can support.  
+  Next we'll show a series of example diagram structures that can be formed 
   with the PVM process model.
   </para>
   

Modified: jbpm4/trunk/modules/devguide/src/main/docbook/en/modules/ch07-ImplementingAdvancedActivities.xml
===================================================================
--- jbpm4/trunk/modules/devguide/src/main/docbook/en/modules/ch07-ImplementingAdvancedActivities.xml	2009-06-17 12:35:36 UTC (rev 5051)
+++ jbpm4/trunk/modules/devguide/src/main/docbook/en/modules/ch07-ImplementingAdvancedActivities.xml	2009-06-17 12:36:35 UTC (rev 5052)
@@ -12,16 +12,10 @@
     </para>
   </section>
 
-  <!-- ### SUB PROCESSES ################################################## -->
-  <section>
-    <title>Sub processes</title>
-    <para>TODO: sub processes</para>
-  </section>
-  
   <!-- ### DEFAULT PROCEED BEHAVIOUR ###################################### -->
   <section id="implicitproceedbehaviour">
     <title>Implicit proceed behaviour</title>
-    <para>When an <literal>Activity</literal> is used as activity behaviour, it can 
+    <para>An <literal>ActivityBehaviour</literal> can 
     explicitely propagate the execution with following methods:
     </para>
     <itemizedlist>
@@ -31,7 +25,15 @@
       <listitem><literal>execute(Activity)</literal></listitem>
       <listitem><literal>createExecution(*)</literal></listitem>
     </itemizedlist>
-    <para>When <literal>Activity</literal> implementations used for activity behviour 
+    
+    <para>As a side note, some of these methods are not exposed in the 
+    interfaces, but only in the implementation.  Those methods are still 
+    in 'incubation'.  So if you want to use those, you can use them at your 
+    own risk by casting the ActivityExecution interface to the implementation
+    class ExecutionImpl. 
+    </para>
+    
+    <para>When <literal>ActivityBehaviour</literal> implementations used for activity behviour 
     don't call any of the following execution propagation methods, then, after 
     the activity is executed, the execution will apply the implicit proceed behaviour. 
     </para>
@@ -50,13 +52,13 @@
   <!-- ### FUNCTIONAL ACTIVITIES ################################ -->
   <section id="functionalactivities">
     <title>Functional activities</title>
-    <para>Activities that also can be used as event listeners are called functional 
+    <para>ActivityBehaviours that also can be used as event listeners are called functional 
     activities. Examples of automatic activities are sending an email, doing a database 
     update, generating a pdf, calculating an average, etc.  All of these are automatic 
     activities that do not change the execution flow.  Here's how such activities can 
     be implemented:  
     </para>
-    <programlisting>public class FunctionalActivity implements Activity, EventListener {
+    <programlisting>public class FunctionalActivity implements ActivityBehaviour, EventListener {
     public void execute(ActivityExecution execution) {
       perform(execution);
     }
@@ -95,8 +97,10 @@
     for the Process Virtual Machine to operate.  Two more levels of asynchonous 
     execution complement this default behaviour: 
     <link linkend="asynchronouscontinuations">Asynchronous continuations</link>
-    and the <link linkend="architecture">asynchronous command service</link>.
+    and in the future we'll also provide a way to invoke service methods asynchronously.
     </para>
+    <para>TODO: update the example that is now commented</para>
+    <!-- 
     <para>The next process will show the basics concretely.  It has three wait states 
     and four automatic activities.
     </para>
@@ -171,6 +175,7 @@
       <title>The second signal brought the execution all the way to 'wait 3'.</title>
       <mediaobject><imageobject><imagedata align="center" fileref="images/ch04.automatic.wait3.png"/></imageobject></mediaobject>
     </figure>
+     -->
     <para>The benefits of using this paradigm is that the same process definition 
     can be executed in <link linkend="clientexecutionmode">client execution mode</link> 
     (in-memory without persistence) as well as in <link linkend="persistentexecutionmode">




More information about the jbpm-commits mailing list