Author: tom.baeyens(a)jboss.com Date: 2008-10-29 12:08:20 -0400 (Wed, 29 Oct 2008) New Revision: 2662 Added: jbpm4/trunk/modules/manual/ jbpm4/trunk/modules/manual/.project jbpm4/trunk/modules/manual/pom.xml jbpm4/trunk/modules/manual/src/ jbpm4/trunk/modules/manual/src/main/ jbpm4/trunk/modules/manual/src/main/diagrams/ jbpm4/trunk/modules/manual/src/main/diagrams/diagrams.mdzip jbpm4/trunk/modules/manual/src/main/diagrams/images.ppt jbpm4/trunk/modules/manual/src/main/docbook/ jbpm4/trunk/modules/manual/src/main/docbook/en/ jbpm4/trunk/modules/manual/src/main/docbook/en/images/ jbpm4/trunk/modules/manual/src/main/docbook/en/images/apis.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/ch04.execution.states.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/ch09.persistent.process.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/class.diagram.process.definition.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/class.diagram.process.execution.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/composite.node.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.automatic.wait1.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.automatic.wait2.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.automatic.wait3.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.concurrency.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.loan.archive.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.loan.end.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.loan.evaluate.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/initial.in.composite.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/interceptors.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/loan.db.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/loan.execution.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.ab.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.anatomy.classes.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.automatic.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.loan.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.propagate.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.structure.classes.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/self.transition.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/transactions.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.inheritence.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.into.composite.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.out.of.composite.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.to.inner.png jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.to.outer.png jbpm4/trunk/modules/manual/src/main/docbook/en/master.xml jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch01-Introduction.xml jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch02-ExecutionModes.xml jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch03-Architecture.xml jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch04-ImplementingBasicActivities.xml jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch05-ProcessAnatomy.xml jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch06-ImplementingAdvancedActivities.xml jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch07-Variables.xml jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch08-Timers.xml jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch09-AsynchronousContinuations.xml jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch10-SoftwareLogging.xml jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-DelegationClasses.xml jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-Environment.xml jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-History.xml jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-Persistence.xml jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-ProcessLanguages.xml jbpm4/trunk/modules/manual/src/main/tutorial/ jbpm4/trunk/modules/manual/src/main/tutorial/docbook.properties jbpm4/trunk/modules/manual/src/main/tutorial/en/ jbpm4/trunk/modules/manual/src/main/tutorial/en/images/ jbpm4/trunk/modules/manual/src/main/tutorial/en/images/composite.decision.png jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.attach.src.png jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.ex01.png jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.new.project.png jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.remove.src.png jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.select.project.dir.png jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.unzipped.png jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.workspace.dir.png jbpm4/trunk/modules/manual/src/main/tutorial/en/images/ex01.basic.process.png jbpm4/trunk/modules/manual/src/main/tutorial/en/images/pvm.unzipped.png jbpm4/trunk/modules/manual/src/main/tutorial/en/images/sequence.2.png jbpm4/trunk/modules/manual/src/main/tutorial/en/images/sequence.png jbpm4/trunk/modules/manual/src/main/tutorial/en/images/tasks.png jbpm4/trunk/modules/manual/src/main/tutorial/en/images/transition.decision.png jbpm4/trunk/modules/manual/src/main/tutorial/en/master.xml jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ExamplesToIncorporate.xml jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ch01-GettingStarted.xml jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ch02-BasicProcessExecution.xml jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ch03-BasicProcessPersistence.xml jbpm4/trunk/modules/manual/target/ jbpm4/trunk/modules/manual/target/docbook/ jbpm4/trunk/modules/manual/target/docbook/publish/ jbpm4/trunk/modules/manual/target/docbook/publish/en/ jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/ jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/ jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/codehighlight.css jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/docnav.css jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/documentation.css jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/extensions.css jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/jbossorg.css jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/reports.css jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/ jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/apis.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/bg.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/ch04.execution.states.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/ch09.persistent.process.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/class.diagram.process.definition.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/class.diagram.process.execution.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/community/ jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/community/title_hdr.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/composite.node.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.automatic.wait1.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.automatic.wait2.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.automatic.wait3.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.concurrency.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.loan.archive.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.loan.end.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.loan.evaluate.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/initial.in.composite.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/interceptors.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/jbpm.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/loan.db.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/loan.execution.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.ab.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.anatomy.classes.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.automatic.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.loan.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.propagate.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.structure.classes.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/self.transition.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transactions.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.inheritence.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.into.composite.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.out.of.composite.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.to.inner.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.to.outer.png jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/index.html jbpm4/trunk/modules/manual/target/docbook/staging/ jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/ jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/MANIFEST.MF jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/maven/ jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/maven/org.jbpm.jbpm4/ jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/maven/org.jbpm.jbpm4/docbook-style/ jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/maven/org.jbpm.jbpm4/docbook-style/pom.properties jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/maven/org.jbpm.jbpm4/docbook-style/pom.xml jbpm4/trunk/modules/manual/target/docbook/staging/css/ jbpm4/trunk/modules/manual/target/docbook/staging/css/css/ jbpm4/trunk/modules/manual/target/docbook/staging/css/css/codehighlight.css jbpm4/trunk/modules/manual/target/docbook/staging/css/css/docnav.css jbpm4/trunk/modules/manual/target/docbook/staging/css/css/documentation.css jbpm4/trunk/modules/manual/target/docbook/staging/css/css/extensions.css jbpm4/trunk/modules/manual/target/docbook/staging/css/css/jbossorg.css jbpm4/trunk/modules/manual/target/docbook/staging/css/css/reports.css jbpm4/trunk/modules/manual/target/docbook/staging/images/ jbpm4/trunk/modules/manual/target/docbook/staging/images/images/ jbpm4/trunk/modules/manual/target/docbook/staging/images/images/apis.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/bg.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/ch04.execution.states.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/ch09.persistent.process.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/class.diagram.process.definition.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/class.diagram.process.execution.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/community/ jbpm4/trunk/modules/manual/target/docbook/staging/images/images/community/title_hdr.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/composite.node.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.automatic.wait1.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.automatic.wait2.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.automatic.wait3.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.concurrency.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.loan.archive.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.loan.end.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.loan.evaluate.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/initial.in.composite.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/interceptors.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/jbpm.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/loan.db.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/loan.execution.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.ab.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.anatomy.classes.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.automatic.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.loan.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.propagate.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.structure.classes.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/self.transition.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transactions.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.inheritence.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.into.composite.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.out.of.composite.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.to.inner.png jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.to.outer.png jbpm4/trunk/modules/manual/target/docbook/work/ Modified: jbpm4/trunk/.project jbpm4/trunk/modules/jpdl/src/main/resources/org/jbpm/jpdl/jpdl.xsd jbpm4/trunk/pom.xml Log: re-introducing the pvm documentation, that should eventually become the full jbpm documentation Modified: jbpm4/trunk/.project =================================================================== --- jbpm4/trunk/.project 2008-10-29 14:48:35 UTC (rev 2661) +++ jbpm4/trunk/.project 2008-10-29 16:08:20 UTC (rev 2662) @@ -1,6 +1,6 @@ <?xml version="1.0" encoding="UTF-8"?> <projectDescription> - <name>svn-jbpm4</name> + <name>jbpm4</name> <comment></comment> <projects> </projects> Modified: jbpm4/trunk/modules/jpdl/src/main/resources/org/jbpm/jpdl/jpdl.xsd =================================================================== --- jbpm4/trunk/modules/jpdl/src/main/resources/org/jbpm/jpdl/jpdl.xsd 2008-10-29 14:48:35 UTC (rev 2661) +++ jbpm4/trunk/modules/jpdl/src/main/resources/org/jbpm/jpdl/jpdl.xsd 2008-10-29 16:08:20 UTC (rev 2662) @@ -248,6 +248,12 @@ <annotation><documentation>Waits while a sub process instance is being executed and continues when the sub process instance ends. </documentation></annotation> + <!-- take into account the following situation: + Unlike in jBPM 3, a process-state should not signal the newly created + process instance. The signal in jBPM 3 is probably historically there + because in the beginning there was no initial attribute on the process + definition. + --> <complexType> <sequence> <element ref="tns:transition" minOccurs="0" maxOccurs="unbounded" /> Added: jbpm4/trunk/modules/manual/.project =================================================================== --- jbpm4/trunk/modules/manual/.project (rev 0) +++ jbpm4/trunk/modules/manual/.project 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,17 @@ +<?xml version="1.0" encoding="UTF-8"?> +<projectDescription> + <name>pvm-manual</name> + <comment></comment> + <projects> + </projects> + <buildSpec> + <buildCommand> + <name>org.maven.ide.eclipse.maven2Builder</name> + <arguments> + </arguments> + </buildCommand> + </buildSpec> + <natures> + <nature>org.maven.ide.eclipse.maven2Nature</nature> + </natures> +</projectDescription> Added: jbpm4/trunk/modules/manual/pom.xml =================================================================== --- jbpm4/trunk/modules/manual/pom.xml (rev 0) +++ jbpm4/trunk/modules/manual/pom.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,97 @@ +<?xml version="1.0" encoding="UTF-8"?> + + <!-- ====================================================================== --> + <!-- --> + <!-- JBoss, the OpenSource J2EE webOS --> + <!-- --> + <!-- Distributable under LGPL license. --> + <!-- See terms of license at http://www.gnu.org. --> + <!-- --> + <!-- ====================================================================== --> + + <!-- $Id$ --> + +<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> + + <modelVersion>4.0.0</modelVersion> + + <name>JBoss jBPM4 - PVM Manual</name> + <groupId>org.jbpm.jbpm4</groupId> + <artifactId>jbpm-manual</artifactId> + <packaging>pom</packaging> + + <!-- Parent --> + <parent> + <groupId>org.jbpm.jbpm4</groupId> + <artifactId>jbpm</artifactId> + <version>4.0.0-SNAPSHOT</version> + <relativePath>../../pom.xml</relativePath> + </parent> + + <dependencies> + <dependency> + <groupId>org.jbpm.jbpm4</groupId> + <artifactId>jbpm-pvm</artifactId> + <version>${version}</version> + </dependency> + </dependencies> + + <build> + <!-- ### PLUGINS ###################################################### --> + <plugins> + + <plugin> + <groupId>org.jboss.maven.plugins</groupId> + <artifactId>maven-jdocbook-plugin</artifactId> + <version>2.1.2</version> + <extensions>true</extensions> + + <executions> + <execution> + <phase>package</phase> + <goals> + <goal>resources</goal> + <goal>generate</goal> + </goals> + </execution> + </executions> + + <dependencies> + <dependency> + <groupId>org.jboss</groupId> + <artifactId>jbossorg-docbook-xslt</artifactId> + <version>1.1.0</version> + </dependency> + <dependency> + <groupId>org.jbpm.jbpm4</groupId> + <artifactId>docbook-style</artifactId> + <version>1.0.0</version> + <type>jdocbook-style</type> + </dependency> + </dependencies> + + <configuration> + <sourceDocumentName>master.xml</sourceDocumentName> + <masterTranslation>en</masterTranslation> + <imageResource> + <directory>${basedir}/src/main/docbook/en</directory> + <includes> + <include>images/*.png</include> + </includes> + </imageResource> + <formats> + <format> + <formatName>html_single</formatName> + <stylesheetResource>classpath:/xslt/org/jboss/xhtml-single.xsl</stylesheetResource> + <finalName>index.html</finalName> + </format> + </formats> + </configuration> + + </plugin> + + </plugins> + </build> + +</project> \ No newline at end of file Property changes on: jbpm4/trunk/modules/manual/pom.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/diagrams/diagrams.mdzip =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/diagrams/diagrams.mdzip ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/diagrams/images.ppt =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/diagrams/images.ppt ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/apis.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/apis.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/ch04.execution.states.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/ch04.execution.states.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/ch09.persistent.process.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/ch09.persistent.process.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/class.diagram.process.definition.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/class.diagram.process.definition.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/class.diagram.process.execution.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/class.diagram.process.execution.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/composite.node.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/composite.node.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.automatic.wait1.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.automatic.wait1.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.automatic.wait2.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.automatic.wait2.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.automatic.wait3.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.automatic.wait3.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.concurrency.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.concurrency.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.loan.archive.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.loan.archive.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.loan.end.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.loan.end.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.loan.evaluate.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/execution.loan.evaluate.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/initial.in.composite.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/initial.in.composite.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/interceptors.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/interceptors.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/loan.db.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/loan.db.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/loan.execution.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/loan.execution.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.ab.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.ab.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.anatomy.classes.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.anatomy.classes.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.automatic.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.automatic.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.loan.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.loan.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.propagate.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.propagate.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.structure.classes.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/process.structure.classes.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/self.transition.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/self.transition.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/transactions.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/transactions.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.inheritence.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.inheritence.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.into.composite.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.into.composite.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.out.of.composite.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.out.of.composite.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.to.inner.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.to.inner.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.to.outer.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/images/transition.to.outer.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/docbook/en/master.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/docbook/en/master.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/docbook/en/master.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,38 @@ +<?xml version="1.0" encoding="UTF-8"?> + +<!DOCTYPE book [ + <!ENTITY ch01-Introduction SYSTEM "modules/ch01-Introduction.xml"> + <!ENTITY ch02-ExecutionModes SYSTEM "modules/ch02-ExecutionModes.xml"> + <!ENTITY ch03-Architecture SYSTEM "modules/ch03-Architecture.xml"> + <!ENTITY ch04-ImplementingBasicActivities SYSTEM "modules/ch04-ImplementingBasicActivities.xml"> + <!ENTITY ch05-ProcessAnatomy SYSTEM "modules/ch05-ProcessAnatomy.xml"> + <!ENTITY ch06-ImplementingAdvancedActivities SYSTEM "modules/ch06-ImplementingAdvancedActivities.xml"> + <!ENTITY ch07-Variables SYSTEM "modules/ch07-Variables.xml"> + <!ENTITY ch08-Timers SYSTEM "modules/ch08-Timers.xml"> + <!ENTITY ch09-AsynchronousContinuations SYSTEM "modules/ch09-AsynchronousContinuations.xml"> + <!ENTITY ch10-SoftwareLogging SYSTEM "modules/ch10-SoftwareLogging.xml"> +]> + +<book lang="en"> + + <bookinfo> + <title>The Process Virtual Machine</title> + <subtitle>A library for building executable state machines. It can + serve as the foundation for any form of BPM, workflow and orchestration. + </subtitle> + </bookinfo> + + <toc /> + + &ch01-Introduction; + &ch02-ExecutionModes; + &ch03-Architecture; + &ch04-ImplementingBasicActivities; + &ch05-ProcessAnatomy; + &ch06-ImplementingAdvancedActivities; + &ch07-Variables; + &ch08-Timers; + &ch09-AsynchronousContinuations; + &ch10-SoftwareLogging; + +</book> \ No newline at end of file Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/master.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch01-Introduction.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch01-Introduction.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch01-Introduction.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,131 @@ +<chapter id="introduction"> + <title>Introduction</title> + + <section> + <title>License and EULA</title> + <para>The Process Virtual Machine component is distributed under the terms of the + GNU Lesser General Public License (LGPL) and the JBoss End User License Agreement (EULA). + See <ulink url="../../../lgpl.html">the full LGPL license text</ulink> and <ulink url="../../../JBossORG-EULA.txt">the + full End User License Agreement</ulink>. + </para> + </section> + + <section> + <title>Sources</title> + <para>The source code for this component can be found in the jBPM SVN repository: + </para> + <ulink url="https://anonsvn.jboss.org/repos/jbpm/jbpm4/pvm/">https:... + </section> + + <section> + <title>JVM version</title> + <para>jbpm-pvm.jar requires a JVM version 5 or higher. + </para> + </section> + + <section> + <title>Library dependencies</title> + <para>For building and executing processes the jbpm-pvm.jar does not have any other + dependencies then on the JVM. If you're using DB persistence, then there is a dependency + on hibernate and it's dependencies. More information about the optional depedencies can + be found in the <ulink url="../../lib/optional-dependencies.html">lib directory</ulink>. + </para> + </section> + + <section> + <title>What is it</title> + <para>In essence, the Process Virtual Machine is a framework specifying executable + graphs. A process definition represents an execution flow and has a structure that + be represented graphically as a diagram. + </para> + <figure id="example.process.graph"> + <title>Example process definition</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/process.loan.png"/></imageobject></mediaobject> + </figure> + <para>Typically, process definitions are static. A process definition is composed of + nodes and transitions. The runtime behaviour of a node is encapsulated in a so called + Activity and it's decoupled from the process graph structure. + </para> + <figure id="class.diagram.process.definition"> + <title>Process structure class diagram</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/class.diagram.process.definition.png"/></imageobject></mediaobject> + </figure> + <para>The Process Virtual + Machine doesn't contain any such activity implementations. It only provides the + execution environment and an activity API to write <literal>Activity</literal> + implementations as Java components. Activities can also be wait states. This means + that the node control flow goes outside the process system. For example a human task + or invoking an service asynchronously. + </para> + <para>Many executions can be started for one process definition. An execution is a pointer + that keeps track of the current node. + </para> + <figure id="example.execution"> + <title>Example execution</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/loan.execution.png"/></imageobject></mediaobject> + </figure> + <para>To represent concurrent paths of execution, there is + a hierarchical parent-child relation between so that one process instance can cope with concurrent + paths of execution. + </para> + <figure id="class.diagram.process.execution"> + <title>Execution class diagram</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/class.diagram.process.execution.png"/></imageobject></mediaobject> + </figure> + </section> + + <section> + <title>Features</title> + <para>The key features of this library are + <itemizedlist> + <listitem>Create executable processes that are based on a diagram structure</listitem> + <listitem>Runtime behaviour of the nodes can be provided as Activity implementations</listitem> + <listitem>Activities can be wait states</listitem> + <listitem>There are no constraints on the process graph structure</listitem> + <listitem>Processes diagrams can be based on composition (aka block structured)</listitem> + <listitem>Processes diagrams can be a mix of graph based and composition</listitem> + <listitem>During wait states, the runtime state of a process execution can be persisted</listitem> + <listitem>Persistence is optional</listitem> + </itemizedlist> + </para> + </section> + + <section> + <title>Purpose</title> + <para>The Process Virtual Machine is designed in such a way that it's easy to build + workflow, BPM, orchestration and other graph based execution langauges on top + of it. Examples of languages that have been built on top of this library: + </para> + <itemizedlist> + <listitem>jPDL: Workflow language that combines powerful human task capabilities with easy binding to Java.</listitem> + <listitem>BPEL: Web-Service orchestration (to be exact for the purists: BPEL is a WSDL service orchestration language)</listitem> + <listitem>Pageflow: To describe navigation handling in a web application, pages can be seen as nodes and the nagivation between the pages as transitions.</listitem> + <listitem>XPDL: A graph based process language standardized by the Workflow Management Coalition (WfMC)</listitem> + </itemizedlist> + <para>Even while the nature of these languages is already very diverse, these are + all examples of general purpose workflow languages. The real power of the + Process Virtual Machine is that it's very easy to build Domain Specific Languages (DSL) + with it. For instance, it's very easy to build a very simple (and dedicated) workflow + language to specify approvals related to documents in a document management system. + </para> + <para>BPM as a discipline refers to the management level effort to optimise efficiency + of an organisation by analysing and optimising the procedures of how people and systems + work together. In designing the Process Virtual Machine and the jPDL language + in particular, we have spend great care on facilitating the link between BPM analysis + notations and executable process languages. Here are the most known modeling notations: + </para> + <itemizedlist> + <listitem>BPMN: OMG latest notation for modeling business processes. + This is a modeling notation that is targetted explicitely to be bound + to executable processes. + </listitem> + <listitem>UML activity diagrams: OMG notation for modeling business + processes. Mostly used in business context.</listitem> + <listitem>UML state diagrams: OMG modeling notation for defining technical + state machines. More used in a technical context.</listitem> + <listitem>EPC: Event driven process chains. Rich notation for modeling + business processes driven by SAP and IDS Scheer.</listitem> + </itemizedlist> + </section> + +</chapter> Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch01-Introduction.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch02-ExecutionModes.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch02-ExecutionModes.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch02-ExecutionModes.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,396 @@ +<chapter id="executionmodes"> + <title>Execution modes</title> + + <para>There are basically three process execution modes: object, persistent + and embedded. For the persistent and embedded execution modes, the process + execution has to participate in a transaction. In that case, the process + execution has to take place inside of an Environment. The environment will be + used to bind process execution updates to a transaction in the application + transaction. The environment can be used to bind to e.g. a JDBC connection, + JTA, BMT, Spring transactions and so on. + </para> + + <section id="objectexecutionmode"> + <title>Object execution mode</title> + <para>Object execution mode is the simplest form of working with the Process + Virtual Machine. This means working with the process definition and execution + objects directly through the client API. Let's show this by an example. We + start by creating a <literal>ClientProcessDefinition</literal> that looks like this: + </para> + + <para>Object execution mode is the simplest form of working with the Process + Virtual Machine. This means working with the process definition and execution + objects directly through the client API. Let's show this by an example. We + start by creating a <literal>ClientProcessDefinition</literal> that looks like this: + </para> + <figure id="loan.process"> + <title>The loan process</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/process.loan.png"/></imageobject></mediaobject> + </figure> + <programlisting>ClientProcessDefinition processDefinition = ProcessFactory.build("loan") + .node("submit loan request").initial().behaviour(AutomaticActivity.class) + .transition().to("evaluate") + .node("evaluate").behaviour(WaitState.class) + .transition("approve").to("wire money") + .transition("reject").to("end") + .node("wire money").behaviour(AutomaticActivity.class) + .transition().to("archive") + .node("archive").behaviour(WaitState.class) + .transition().to("end") + .node("end").behaviour(WaitState.class) +.done();</programlisting> + <para>The <literal>ProcessFactory</literal> is a helper class that provides convenience + for building an object graph that represents a process definition. + <literal>AutomaticActivity</literal> is a pass-through activity without anything + happening and <literal>WaitState</literal> will wait until an external signal is given. Both + activity implementations will be covered in more depth later. + </para> + <para>The <literal>processDefinition</literal> object serves as a factory for process + instance objects. A process instance represents one execution of the process definition. + More precise, the process instance is the main path of execution. + </para> + <programlisting>ClientExecution execution = processDefinition.startProcessInstance();</programlisting> + <para>A process instance + itself is also an <literal>Execution</literal>. Potentially, an execution can have + child executions to represent concurrent paths of execution. + </para> + <para>The <literal>execution</literal> can be seen as a state machine that operates as + described in the process definition. Starting a process + instance means that the initial node of the process definition is executed. + Since this is an automatic activity, the execution will proceed to the + <literal>evaluate</literal> node. The <literal>evaluate</literal> node is a wait state. + When the execution arrived at the evaluate node, the method <literal>startProcessInstance</literal> + will return and waits until an external signal is provided with the <literal>signal</literal> + method. So after the <literal>startProcessInstance</literal> we can verify if the + execution is positioned in the evaluate node. + </para> + <programlisting>assertEquals("evaluate", execution.getNodeName());</programlisting> + <para>To make the process execute further, we provide an external trigger with the + <literal>signal</literal> method. The result of the evaluation will be given as the + signalName parameter like this: + </para> + <programlisting>execution.signal("approve");</programlisting> + <para>The <literal>WaitState</literal> activity implementation will take the transition + that corresponds to the given signalName. So the execution will first execute + the automatic activity <literal>wire money</literal> and then return after entering + the next wait state <literal>archive</literal>. + </para> + <programlisting>assertEquals("archive", execution.getNodeName());</programlisting> + <para>When the execution is waiting in the archive node, the default signal will + make it take the first unnamed transition. + </para> + <programlisting>execution.signal(); +assertEquals("end", execution.getNodeName());</programlisting> + <para>The process has executed in the thread of the client. The + <literal>startProcessInstance</literal> method only returned when the <literal>evaluate</literal> + node was reached. In other words, the <literal>ClientProcessDefinition.startProcessInstance</literal> + and <literal>ClientExecution.signal</literal> methods are blocking until the next + wait state is reached. + </para> + </section> + + <section id="persistentexecutionmode"> + <title>Persistent execution mode</title> + <para>The Process Virtual Machine also contains the hibernate mappings to store the + process definitions and executions in any database. A special session facade called + <literal>ExecutionService</literal> is provided for working with process executions + in such a persistent environment. + </para> + <para>Two configuration files should be available on the classpath: an environment + configuration file and a <literal>hibernate.properties</literal> file. A basic + configuration for persistent execution mode in a standard Java environment looks + like this: + </para> + <literal><emphasis role="bold">environment.cfg.xml</emphasis>:</literal> + <programlisting>&lt;contexts xmlns=&quot;http://jbpm.org/pvm/1.0/wire&quot;&gt; + + &lt;environment-factory&gt; + + &lt;deployer-manager&gt; + &lt;language name=&quot;api&quot;&gt; + &lt;check-version /&gt; + &lt;create-id /&gt; + &lt;save-process /&gt; + &lt;/language&gt; + &lt;/deployer-manager&gt; + + &lt;process-service /&gt; + &lt;execution-service /&gt; + &lt;management-service /&gt; + + &lt;command-service&gt; + &lt;retry-interceptor /&gt; + &lt;environment-interceptor /&gt; + &lt;standard-transaction-interceptor /&gt; + &lt;/command-service&gt; + + &lt;hibernate-configuration&gt; + &lt;properties resource=&quot;hibernate.properties&quot; /&gt; + &lt;mappings resource=&quot;org/jbpm/pvm/pvm.hibernate.mappings.xml&quot; /&gt; + &lt;cache-configuration resource=&quot;org/jbpm/pvm/pvm.cache.xml&quot; + usage=&quot;nonstrict-read-write&quot; /&gt; + &lt;/hibernate-configuration&gt; + + &lt;hibernate-session-factory /&gt; + + &lt;id-generator /&gt; + &lt;variable-types resource=&quot;org/jbpm/pvm/pvm.types.xml&quot; /&gt; + &lt;job-executor auto-start=&quot;false&quot; /&gt; + + &lt;/environment-factory&gt; + + &lt;environment&gt; + &lt;hibernate-session /&gt; + &lt;transaction /&gt; + &lt;pvm-db-session /&gt; + &lt;job-db-session /&gt; + &lt;message-session /&gt; + &lt;/environment&gt; + +&lt;/contexts&gt;</programlisting> + <para>And next to it a hibernate.properties like this</para> + <literal>hibernate.properties:</literal> + <programlisting>hibernate.dialect org.hibernate.dialect.HSQLDialect +hibernate.connection.driver_class org.hsqldb.jdbcDriver +hibernate.connection.url jdbc:hsqldb:mem:. +hibernate.connection.username sa +hibernate.connection.password +hibernate.hbm2ddl.auto create-drop +hibernate.cache.use_second_level_cache true +hibernate.cache.provider_class org.hibernate.cache.HashtableCacheProvider +# hibernate.show_sql true +hibernate.format_sql true +hibernate.use_sql_comments true</programlisting> + <para>Then you can obtain the services from the environment factory like this: + </para> + <programlisting>EnvironmentFactory environmentFactory = new PvmEnvironmentFactory(&quot;environment.cfg.xml&quot;); + +ProcessService processService = environmentFactory.get(ProcessService.class); +ExecutionService executionService = environmentFactory.get(ExecutionService.class); +ManagementService managementService = environmentFactory.get(ManagementService.class);</programlisting> + <para>The responsibility of the <literal>ProcessService</literal> is to manage + the repository of process definitions. Before we can start a process execution, + the process definition needs to be deployed into the process repository. + Process definitions can be supplied in various formats and process definition + languages. A deployment collects process definition information from various + sources like a ZIP file, an XML file or a process definition object. + The method <literal>ProcessService.deploy</literal> will take a deployment + through all the deployers that are configured in the configuration file. + </para> + <para>In this example, we'll supply a process definition programmatically + for deployment.</para> + <programlisting>ClientProcessDefinition processDefinition = ProcessFactory.build("loan") + .node("submit loan request").initial().behaviour(AutomaticActivity.class) + .transition().to("evaluate") + .node("evaluate").behaviour(WaitState.class) + .transition("approve").to("wire money") + .transition("reject").to("end") + .node("wire money").behaviour(AutomaticActivity.class) + .transition().to("archive") + .node("archive").behaviour(WaitState.class) + .transition().to("end") + .node("end").behaviour(WaitState.class) +.done(); + +Deployment deployment = new Deployment(processDefinition); +processService.deploy(deployment);</programlisting> + <para>Now, a version of that process definition is stored in the database. + The <literal>check-version</literal> deployer will have assigned version 1 + to the stored process definition. The <literal>create-id</literal> deployer + will have distilled id <literal>loan:1</literal> from the process name and the + assigned version. + </para> + <para>Deploying that process again will lead to a new process definition + version being created in the database. But an incremented version number will + be assigned. For the purpose of versioning, process definitions are considered + equal if they have the same name.</para> + <para>It is recommended that a user provided key reference is supplied for + all process executions. Starting a new process execution goes like this: + </para> + <programlisting>Execution execution = executionService.startExecution("loan:1", "request7836");</programlisting> + <para>The return value is an execution interface, which prevents navigation of relations. + That is because outside of the service methods, the transaction and hibernate session + is not guaranteed to still be open. In fact, the default configuration as given + above will only keep the transaction and session open for the duration of the + service method. So navigating the relations outside of the service methods might result + into a hibernate <literal>LazyInitializationException</literal>. But the + current node name can still be verified: + </para> + <programlisting>assertEquals("evaluate", execution.getNodeName());</programlisting> + <para>Also very important is the generated id that can be obtained. The default + <literal>id-generator</literal> will use the process definition id and the + given key to make a unique id for the process execution like this:</para> + <programlisting>assertEquals("loan:1/request7836", execution.getId());</programlisting> + <para>That id must be when providing the subsequent external triggers to the + process execution like this: + </para> + <programlisting>executionService.signalExecution("loan:1/request7836", "approve");</programlisting> + <para>More information about service interfaces to run in persistent + mode can be found in package + <ulink url="../../api/org/jbpm/pvm/package-summary.html"><literal>org.jbpm.pvm</literal> of the + api docs</ulink>. + </para> + </section> + + <section id="embeddedexecutionmode"> + <title>Embedded execution mode</title> + <para>Embedded execution mode means that the state of a process is stored + as a string column inside a user domain object like e.g. a loan. + </para> + <programlisting>public class Loan { + + <emphasis role="bold">/** the loan process definition as a static resource */ + private static final ClientProcessDefinition processDefinition = createLoanProcess(); + + private static ClientProcessDefinition createLoanProcess() { + ClientProcessDefinition processDefinition = ProcessFactory.build(&quot;loan&quot;) + .node(&quot;submit loan request&quot;).initial().behaviour(AutomaticActivity.class) + .transition().to(&quot;evaluate&quot;) + .node(&quot;evaluate&quot;).behaviour(WaitState.class) + .transition(&quot;approve&quot;).to(&quot;wire money&quot;) + .transition(&quot;reject&quot;).to(&quot;end&quot;) + .node(&quot;wire money&quot;).behaviour(AutomaticActivity.class) + .transition().to(&quot;archive&quot;) + .node(&quot;archive&quot;).behaviour(WaitState.class) + .transition().to(&quot;end&quot;) + .node(&quot;end&quot;).behaviour(WaitState.class) + .done(); + + return processDefinition; + } + + /** exposes the process definition to the execution hibernate type */ + private static ClientProcessDefinition getProcessDefinition() { + return processDefinition; + } + </emphasis> + + long dbid; + String customer; + double amount; + <emphasis role="bold">ClientExecution execution;</emphasis> + + /** constructor for persistence */ + protected Loan() { + } + + public Loan(String customer, double amount) { + this.customer = customer; + this.amount = amount; + <emphasis role="bold">this.execution = processDefinition.startProcessInstance();</emphasis> + } + + public void approve() { + <emphasis role="bold">execution.signal(&quot;approve&quot;);</emphasis> + } + + public void reject() { + <emphasis role="bold">execution.signal(&quot;reject&quot;);</emphasis> + } + + public void archiveComplete() { + <emphasis role="bold">execution.signal();</emphasis> + } + + public String getState() { + return <emphasis role="bold">execution.getNodeName()</emphasis>; + } + + ...getters... +}</programlisting> + <para>If you ignore the bold parts for a second, you can see that this is a + POJO without anything fancy. It's just a bean that can be stored with hibernate. + The bold part indicate that implementation part of the class that is related + to process and execution. Not that nothing of the process definition or + execution is exposed to the user of the Loan class. + </para> + <para>Each <literal>Loan</literal> object corresponds to a <literal>loan</literal> + process instance. Some methods of the <literal>Loan</literal> class correspond + to the external triggers that need to be given during the lifecycle of a + <literal>Loan</literal> object. + </para> + <para>Next we'll show how to use this class. To get started we need a</para> + <emphasis role="bold"><literal>hibernate.cfg.xml:</literal></emphasis> + <programlisting>&lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot;?&gt; + +&lt;!DOCTYPE hibernate-configuration PUBLIC + &quot;-//Hibernate/Hibernate Configuration DTD 3.0//EN&quot; + &quot;http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd&quot;&gt; + +&lt;hibernate-configuration&gt; + &lt;session-factory&gt; + + &lt;property name=&quot;hibernate.dialect&quot;&gt;org.hibernate.dialect.HSQLDialect&lt;/property&gt; + &lt;property name=&quot;hibernate.connection.driver_class&quot;&gt;org.hsqldb.jdbcDriver&lt;/property&gt; + &lt;property name=&quot;hibernate.connection.url&quot;&gt;jdbc:hsqldb:mem:.&lt;/property&gt; + &lt;property name=&quot;hibernate.connection.username&quot;&gt;sa&lt;/property&gt; + &lt;property name=&quot;hibernate.connection.password&quot;&gt;&lt;/property&gt; + &lt;property name=&quot;hibernate.hbm2ddl.auto&quot;&gt;create&lt;/property&gt; + &lt;property name=&quot;hibernate.show_sql&quot;&gt;true&quot;&lt;/property&gt; + &lt;property name=&quot;hibernate.format_sql&quot;&gt;true&quot;&lt;/property&gt; + &lt;property name=&quot;hibernate.use_sql_comments&quot;&gt;true&quot;&lt;/property&gt; + + &lt;mapping resource=&quot;Loan.hbm.xml&quot;/&gt; + + &lt;/session-factory&gt; +&lt;/hibernate-configuration&gt;</programlisting> + <para>And a</para> + <emphasis role="bold"><literal>Loan.hbm.xml:</literal></emphasis> + <programlisting>&lt;?xml version=&quot;1.0&quot;?&lt; + +&lt;!DOCTYPE hibernate-mapping PUBLIC + &quot;-//Hibernate/Hibernate Mapping DTD 3.0//EN&quot; + &quot;http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd&quot;&lt; + +&lt;hibernate-mapping package=&quot;org.jbpm.pvm.api.db.embedded&quot; default-access=&quot;field&quot;&lt; + + &lt;typedef name=&quot;execution&quot; class=&quot;org.jbpm.pvm.internal.hibernate.ExecutionType&quot; /&lt; + + &lt;class name=&quot;Loan&quot; table=&quot;LOAN&quot;&lt; + + &lt;id name=&quot;dbid&quot;&lt; + &lt;generator class=&quot;sequence&quot;/&lt; + &lt;/id&lt; + + &lt;property name=&quot;execution&quot; type=&quot;execution&quot; /&lt; + &lt;property name=&quot;customer&quot; /&lt; + &lt;property name=&quot;amount&quot; /&lt; + + &lt;/class&lt; + +&lt;/hibernate-mapping&lt;</programlisting> + <para>Then you can use the Loan class like this in a test</para> + <programlisting>Configuration configuration = new Configuration(); +configuration.configure(); +SessionFactory sessionFactory = configuration.buildSessionFactory(); + +// start a session/transaction +Session session = sessionFactory.openSession(); +Transaction transaction = session.beginTransaction(); + +Loan loan = new Loan("john doe", 234.0); +session.save(loan); +assertEquals("evaluate", loan.getState()); + +// start a new session/transaction +transaction.commit(); +session.close(); +session = sessionFactory.openSession(); +transaction = session.beginTransaction(); + +loan = (Loan) session.get(Loan.class, loan.getDbid()); +assertEquals("evaluate", loan.getState()); +loan.approve(); +assertEquals("archive", loan.getState()); + +// start a new session/transaction +transaction.commit(); +session.close();</programlisting> + <para>After executing this code snippet, this is the loan record in the DB:</para> + <figure id="loan.db"> + <title>The loan record in the DB</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/loan.db.png"/></imageobject></mediaobject> + </figure> + </section> + +</chapter> \ No newline at end of file Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch02-ExecutionModes.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch03-Architecture.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch03-Architecture.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch03-Architecture.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,250 @@ +<chapter id="architecture"> + <title>Architecture</title> + + <section id="apis"> + <title>APIs</title> + <para>The Process Virtual Machine has 4 integrated API's that together + offer a complete coverage of working with processes in the different execution modes. + Each of the APIs has a specific purpose that fits within the following overall + architecture. + </para> + <figure id="apis"> + <title>The 4 API's of the Process Virtual Machine</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/apis.png"/></imageobject></mediaobject> + </figure> + <para>The services interfaces should be used from application code that wants to interact + with the Process Virtual Machine which runs in transactional persistent mode, backed by a + database. This is the most typical way how users interact with the PVM as a workflow engine. + </para> + <para>To execute processes without persistence, the client API can be used to work with process + and execution objects directly. The client API expose the methods of the core model objects. + </para> + <para>The activity API is used to implement the runtime behaviour of activities. So a activity + type is in fact a component with at the core an implementation of the <literal>Activity</literal> + interface. Activity implementations can control the flow of execution. + </para> + <para>The event listener API serves to write pieces of Java code that should be executed upon + process events. It's very similar to the activity API with that exception that event listeners + are not able to control the flow of execution. + </para> + </section> + + <section> + <title>Activity API</title> + <para>The activity API allows to implement the runtime activity behaviour in Java. + </para> + <programlisting>public interface Activity extends Serializable { + void execute(ActivityExecution execution) throws Exception; +}</programlisting> + <para>An activity is the behaviour of the node to which it is associated. + The provided execution is the execution that arrives in the node. + The interface <literal>ActivityExecution</literal> exposes special + methods to control the execution flow. + </para> + <programlisting>public interface ActivityExecution extends OpenExecution { + + void waitForSignal(); + void take(String transitionName); + void execute(String nodeName); + + ... + +}</programlisting> + </section> + + <section> + <title>Event listener API</title> + <para>The event listener API allows for listeners to be developed in Java code + and that are invoked on specific process events like entering a node or leaving + a node. It is very similar to the activity API, but the difference is + that the propagation of the execution flow cannot be controlled. E.g. when an execution + is taking a transition, a listener to that event can be notified, but since the + transition is already being taking, the execution flow cannot be changed + by the event listeners. + </para> + <programlisting>public interface EventListener extends Serializable { + + void notify(EventListenerExecution execution) throws Exception; + +}</programlisting> + </section> + + <section> + <title>Client API</title> + <para>The client API was already introduced above in the object execution mode + and embedded execution mode. It's an interface that exposes the methods for + managing executions on the plain process definition and execution objects directly. + </para> + <para>At a minimal, the client API and the activity API are needed to create + some a process definition with activities and execute it. + </para> + </section> + + <section> + <title>Environment</title> + <para>In the persistent execution mode, the first purpose of the environment is + to enable processes to be executed in different transactional environments like + standard Java, enterprise Java, SEAM and Spring. + </para> + <para>The PVM code itself will only use transactional resources through self-defined + interfaces. For example, the PVM itself has interfaces for some methods on the hibernate + session, a async messaging session and a timer session. + </para> + <para>The environment allows to configure the actual implementations, lazy + initialization of the services on a request-basis and caching the service + objects for the duration of the transaction. + </para> + <para>An environment factory is static and one environment factory can serve + all the threads in an application. + </para> + <programlisting>EnvironmentFactory environmentFactory = new PvmEnvironmentFactory("environment.cfg.xml");</programlisting> + <para>Environment blocks can surround persistent process operations + like this: + </para> + <programlisting>Environment environment = environmentFactory.openEnvironment(); +try { + + ... inside the environment block... + +} finally { + environment.close(); +}</programlisting> + <para>The PVM itself will fetch all it's transactional resources and configurations + from the environment. It's recommended that <literal>Activity</literal> implementations + do the same. + </para> + </section> + + <section> + <title>Commands</title> + <para>Commands encapsulate operations that are to be executed within an environment + block. The main purpose for commands is to capture the logic of + </para> + <programlisting>public interface Command&lt;T&gt; extends Serializable { + + T execute(Environment environment) throws Exception; + +}</programlisting> + <para></para> + </section> + + <section> + <title>Services</title> + <para>There are three services: <literal>ProcessService</literal>, + <literal>ExecutionService</literal> and <literal>ManagementService</literal>. + In general, services are session facades that expose methods for persistent + usage of the PVM. The next fragments show the essential methods as example + to illustrate those services. + </para> + <para>The <literal>ProcessService</literal> manages the repository of + process definitions. + </para> + <programlisting>public interface ProcessService { + + ProcessDefinition deploy(Deployment deployment); + + ProcessDefinition findLatestProcessDefinition(String processDefinitionName); + + ... + +}</programlisting> + <para>The <literal>ExecutionService</literal> manages the runtime + executions.</para> + <programlisting>public interface ExecutionService { + + Execution startExecution(String processDefinitionId, String executionKey); + + Execution signalExecution(String executionId, String signalName); + + ... + +}</programlisting> + <para>The <literal>ManagementService</literal> groups all management operations + that are needed to keep the system up and running. + </para> + <programlisting>public interface ManagementService { + + List&lt;Job&gt; getJobsWithException(int firstResult, int maxResults); + + void executeJob(String jobId); + + ... + +}</programlisting> + <para>The implementation of all these methods is encapsulated in + <literal>Command</literal>s. And the three services all delegate the + execution of the commands to a <literal>CommandService</literal>: + </para> + <programlisting>public interface CommandService { + + &lt;T&gt; T execute(Command&lt;T&gt; command); + +}</programlisting> + <para>The <literal>CommandService</literal> is configured in the + environment. A chain of CommandServices can act as interceptors + around a command. This is the core mechanism on how persistence and + transactional support can be offered in a variety of environments. + </para> + <para>From the default configuration which is included in full above, + here is the section that configures the services + </para> + <programlisting>&lt;contexts xmlns=&quot;http://jbpm.org/pvm/1.0/wire&quot;&gt; + + &lt;environment-factory&gt; + + &lt;process-service /&gt; + &lt;execution-service /&gt; + &lt;management-service /&gt; + + &lt;command-service&gt; + &lt;retry-interceptor /&gt; + &lt;environment-interceptor /&gt; + &lt;standard-transaction-interceptor /&gt; + &lt;/command-service&gt; + + ... + </programlisting> + <para>The three services <literal>process-service</literal>, <literal>execution-service</literal> + and <literal>management-service</literal> will look up the configured + <literal>command-service</literal> by type. The <literal>command-service</literal> + tag corresponds to the default command service that essentially does nothing else + then just execute the command providing it the current environment. + </para> + <para>The configured <literal>command-service</literal> results into the following + a chain of three interceptors followed by the default command executor. + </para> + <figure id="interceptors"> + <title>The CommandService interceptors</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/interceptors.png"/></imageobject></mediaobject> + </figure> + <para>The retry interceptor is the first in the chain and that one that will be exposed as the + <literal>CommandService.class</literal> from the environment. So the retry interceptor + will be given to the respective services <literal>process-service</literal>, <literal>execution-service</literal> + and <literal>management-service</literal>. + </para> + <para>The <literal>retry-interceptor</literal> will catch hibernate StaleObjectExceptions + (indicating optimistic locking failures) and retry to execute the command. + </para> + <para>The <literal>environment-interceptor</literal> will put an environment block + around the execution of the command. + </para> + <para>The <literal>standard-transaction-interceptor</literal> will initialize a + <literal>StandardTransaction</literal>. The hibernate session/transaction will be + enlisted as a resource with this standard transaction. + </para> + <para>Different configurations of this interceptor stack will also enable to + </para> + <itemizedlist> + <listitem>delegate execution to a local ejb command service so that an container + managed transaction is started. + </listitem> + <listitem>delegate to a remote ejb command service so that the command actually + gets executed on a different JVM. + </listitem> + <listitem>package the command as an asynchronous message so that the command gets + executed asynchronously in a different transaction. + </listitem> + </itemizedlist> + </section> + +</chapter> \ No newline at end of file Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch03-Architecture.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch04-ImplementingBasicActivities.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch04-ImplementingBasicActivities.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch04-ImplementingBasicActivities.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,536 @@ +<chapter id="implementingbasicactivities"> + <title>Implementing basic activities</title> + + <para>This chapter explains the basics of process definitions, the features offered by + the Process Virtual Machine and how activity implementations can be build. At the same + time the client API is shown to execute processes with those activity implementations. + </para> + + <!-- ### Activity ####################################################### --> + <section id="activity"> + <title>Activity</title> + <para>The PVM library doesn't have a fixed set of process constructs. + Instead, runtime behaviour of a node is delegated to an <literal>Activity</literal>. + In other words, <literal>Activity</literal> is an interface to implement the runtime + behaviour of process constructs in plain Java. + </para> + <programlisting>public <emphasis role="bold">interface Activity</emphasis> extends Serializable { + + void <emphasis role="bold">execute</emphasis>(ActivityExecution execution) throws Exception; + +}</programlisting> + <para>When an activity is used as the node behaviour, it is in full control of the further + propagation of the execution. In other words, a node behaviour can decide what the execution + should do next. For example, it can take a transition with + <literal>execution.take(Transition)</literal> or go into a wait state with + <literal>execution.waitForSignal()</literal>. In case the node behaviour does not invoke + any of the above execution propagation methods, the execution will + <link linkend="implicitproceedbehaviour">proceed in a default way</link>. + </para> + </section> + + <!-- ### Activity example ############################################### --> + <section id="activityexample"> + <title>Activity example</title> + <para>We'll start with a very original hello world example. A Display + activity will print a message to the console: + </para> + <programlisting>public <emphasis role="bold">class Display</emphasis> implements <emphasis role="bold">Activity</emphasis> { + + String message; + + public Display(String message) { + this.message = message; + } + + public void execute(ActivityExecution execution) { + <emphasis role="bold">System.out.println(message);</emphasis> + } +}</programlisting> + <para>Let' build our first process definition with this activity:</para> + <figure id="activity.example"> + <title>Display example process</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/process.ab.png"/></imageobject></mediaobject> + </figure> + <programlisting>ClientProcessDefinition processDefinition = ProcessFactory.build() + .<emphasis role="bold">node("a").initial()</emphasis>.behaviour(<emphasis role="bold">new Display("hello")</emphasis>) + .transition().to("b") + .<emphasis role="bold">node("b")</emphasis>.behaviour(<emphasis role="bold">new Display("world")</emphasis>) +.done();</programlisting> + <para>Now we can execute this process as follows:</para> + <programlisting>Execution execution = processDefinition.startExecution();</programlisting> + <para>The invocation of <literal>startExecution</literal> will print hello world to the console:</para> + <programlisting>hello +world</programlisting> + <para>One thing already worth noticing is that activities can be configured + with properties. In the Display example, you can see that the message property + is configured differently in the two usages. With configuration properties + it becomes possible to write reusable activities. They can then be configured + differently each time they are used in a process. That is an essential part of + how process languages can be build on top of the Process Virtual Machine. + </para> + <para>The other part that needs explanation is that this activity + implementation does not contain any instructions for the propagation of the + execution. When a new process instance is started, the execution is positioned + in the initial node and that activity is executed. The method + <literal>Display.execute</literal> makes use of what is called implicit propagation + of execution. Concretely this means that the activity itself does not + invoke any of the methods on the execution to propagate it. In that case + implicit propagation kicks in. Implicit propagation will take the first + transition if there is one. If not, it will end the execution. This explains + why both nodes <literal>a</literal> and <literal>b</literal> are executed and that + the execution stops after node <literal>b</literal> is executed. + </para> + <para>More details about the implicit proceed behaviour can be found + in <xref linkend="implicitproceedbehaviour" /></para> + </section> + + <!-- ### ExternalActivity ############################################### --> + <section id="externalactivity"> + <title>ExternalActivity</title> + <para>External activities are activities for which the responsibility for proceeding + the execution is transferred externally, meaning outside the process system. This + means that for the system that is executing the process, it's a wait state. The + execution will wait until an external trigger is given. + </para> + <para>For dealing with external triggers, <literal>ExternalActivity</literal> + adds two methods to the <literal>Activity</literal>:</para> + <programlisting>public <emphasis role="bold">interface ExternalActivity</emphasis> extends <emphasis role="bold">Activity</emphasis> { + + void <emphasis role="bold">signal</emphasis>(Execution execution, + String signal, + Map&lt;String, Object&gt; parameters) throws Exception; + +}</programlisting> + <para>Just like with plain activities, when an execution arrives in a node, the + <literal>execute</literal>-method of the node behaviour is invoked. + In external activities, the execute method typically does something to + transfer the responsibility to another system and then enters a wait + state by invoking <literal>execution.waitForSignal()</literal>. For + example in the execute method, responsibility could be transferred to a + person by creating a task entry in a task management system and then + wait until the person completes the task. + </para> + <para>In case a node behaves as a wait state, then the execution will + wait in that node until the execution's <literal>signal</literal> method + is invoked. The execution will delegate that signal to the behaviour Activity + of the current node. + </para> + <para>So the Activity's <literal>signal</literal>-method is invoked + when the execution receives an external trigger during the wait state. With the + signal method, responsibility is transferred back to the process execution. For + example, when a person completes a task, the task management system calls the + signal method on the execution. + </para> + <para>A signal can optionally have a signal name and a map of parameters. Most + common way on how node behaviours interprete the signal and parameters is that + the signal relates to the outgoing transition that needs to be taken and that the + parameters are set as variables on the execution. But those are just examples, it + is up to the activity to use the signal and the parameters as it pleases. + </para> + </section> + + <!-- ### ExternalActivity example ####################################### --> + <section id="externalactivityexample"> + <title>ExternalActivity example</title> + <para>Here's a first example of a simple wait state implementation: + </para> + <programlisting>public <emphasis role="bold">class WaitState</emphasis> implements <emphasis role="bold">ExternalActivity</emphasis> { + + public void execute(ActivityExecution execution) { + <emphasis role="bold">execution.waitForSignal();</emphasis> + } + + public void signal(ActivityExecution execution, + String signalName, + Map&lt;String, Object&gt; parameters) { + <emphasis role="bold">execution.take(signalName);</emphasis> + } +}</programlisting> + <para>The <literal>execute</literal>-method calls + <literal>execution.waitForSignal()</literal>. The invocation of + <literal>execution.waitForSignal()</literal> will bring the process execution + into a wait state until an external trigger is given. + </para> + <para><literal>signal</literal>-method takes the transition with + the signal parameter as the transition name. So when an execution receives an + external trigger, the signal name is interpreted as the name of an outgoing + transition and the execution will be propagated over that transition. + </para> + <para>Here's the same simple process that has a transition from a to b. This + time, the behaviour of the two nodes will be WaitState's. + </para> + <figure id="process.diagram"> + <title>The external activity example process</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/process.ab.png"/></imageobject></mediaobject> + </figure> + <programlisting>ClientProcessDefinition processDefinition = ProcessFactory.build() + <emphasis role="bold">.node("a").initial().behaviour(new WaitState())</emphasis> + .transition().to("b") + <emphasis role="bold">.node("b").behaviour(new WaitState())</emphasis> +.done();</programlisting> + <para>Let's start a new process instance for this process definition:</para> + <programlisting>ClientExecution execution = processDefinition.startProcessInstance();</programlisting> + <para>Starting this process will execute the <literal>WaitState</literal> activity + in node <literal>a</literal>. <literal>WaitState.execute</literal> will invoke + <literal>ActivityExecution.waitForSignal</literal>. So when the + <literal>processDefinition.startProcessInstance()</literal> returns, the execution + will still be positioned in node a. + </para> + <programlisting>assertEquals("a", execution.getNodeName());</programlisting> + <para>Then we provide the external trigger by calling the <literal>signal</literal> + method. + </para> + <programlisting>execution.signal();</programlisting> + <para>The <literal>execution.signal()</literal> will delegate to the activity + of the current node. So in this case that is the <literal>WaitState</literal> + activity in node <literal>a</literal>. The <literal>WaitState.signal</literal> + will invoke the <literal>ActivityExecution.take(String transitionName)</literal>. + Since we didn't supply a signalName, the first transition with name <literal>null</literal> + will be taken. The only transition we specified out of node <literal>a</literal> + didn't get a name so that one will be taken. And that transition points to node + <literal>b</literal>. When the execution arrives in node <literal>b</literal>, + the <literal>WaitState</literal> in node <literal>b</literal> is executed. + Similar as we saw above, the execution will wait in node <literal>b</literal> + and this time the <literal>signal</literal> method will return, leaving the + execution positioned in node <literal>b</literal>. + </para> + <programlisting>assertEquals("b", execution.getNodeName());</programlisting> + </section> + + <!-- ### BASIC PROCESS EXECUTION ######################################## --> + <section id="basicprocessexecution"> + <title>Basic process execution</title> + <para>In this next example, we'll combine automatic activities and wait states. + This example builds upon the loan approval process with the <literal>WaitState</literal> + and <literal>Display</literal> activities that we've just created. Graphically, + the loan process looks like this: + </para> + <figure id="basicprocessexecution.loan.process"> + <title>The loan process</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/process.loan.png"/></imageobject></mediaobject> + </figure> + <para>Building process graphs in Java code can be tedious because you have to keep track of all the + references in local variables. To resolve that, the Process Virtual Machine comes with a + ProcessFactory. The ProcessFactory is a kind of domain specific language (DSL) that is embedded + in Java and eases the construction of process graphs. This pattern is also known as + a <ulink url="http://martinfowler.com/bliki/FluentInterface.html">fluent + interface</ulink>. + </para> + <programlisting>ClientProcessDefinition processDefinition = ProcessFactory.build("loan") + .node(<emphasis role="bold">"submit loan request"</emphasis>).initial().behaviour(new Display("loan request submitted")) + .transition().to("evaluate") + <emphasis role="bold">.node("evaluate").behaviour(new WaitState())</emphasis> + .transition("approve").to("wire money") + .transition("reject").to("end") + <emphasis role="bold">.node("wire money").behaviour(new Display("wire the money"))</emphasis> + .transition().to("archive") + <emphasis role="bold">.node("archive").behaviour(new WaitState())</emphasis> + .transition().to("end") + <emphasis role="bold">.node("end").behaviour(new WaitState())</emphasis> +.done();</programlisting> + <para>For more details about the ProcessFactory, see <ulink url="../../api/org/jbpm/pvm/package-summary.html">the + api docs</ulink>. An alternative for + the ProcessFactory would be to create an XML language and an XML parser for expressing + processes. The XML parser can then instantiate the classes of package + <literal>org.jbpm.pvm.internal.model</literal> directly. That approach is typically taken by + process languages. + </para> + <para>The initial node <literal>submit loan request</literal> and the node + <literal>wire the money</literal> are automatic nodes. In this example, + the <literal>Display</literal> implementation of node + <literal>wire the money</literal> uses the Java API's to just print a + message to the console. But the witty reader can imagine an alternative + <literal>Activity</literal> implementation that uses the Java API of a payment + processing library to make a real automatic payment. + </para> + <para>A new execution for the process above can be started like this + </para> + <programlisting>ClientExecution execution = processDefinition.startProcessInstance();</programlisting> + <para>When the <literal>startExecution</literal>-method returns, the node + <literal>submit loan request</literal> will be executed and the execution will be + positioned in the node <literal>evaluate</literal>. + </para> + <figure id="execution.loan.evaluate"> + <title>Execution positioned in the 'evaluate' node</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/execution.loan.evaluate.png"/></imageobject></mediaobject> + </figure> + <para>Now, the execution is at an interesting point. There are two transitions out of + the state <literal>evaluate</literal>. One transition is called <literal>approve</literal> + and one transition is called <literal>reject</literal>. As we explained above, the WaitState + implementation will take the transition that corresponds to the signal that is given. + Let's feed in the 'approve' signal like this: + </para> + <programlisting>execution.signal("approve");</programlisting> + <para>The <literal>approve</literal> signal will cause the execution to take the <literal>approve</literal> + transition and it will arrive in the node <literal>wire money</literal>. + </para> + <para>In node <literal>wire money</literal>, the message will be printed to the console. + Since, the <literal>Display</literal> activity didn't invoke the + <literal>execution.waitForSignal()</literal>, nor any of the other execution propagation + methods, the implicit proceed behaviour will just make the execution continue + over the outgoing transition to node <literal>archive</literal>, which is again + a <literal>WaitState</literal>. + </para> + <figure id="execution.loan.archive"> + <title>Execution positioned in 'archive' node</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/execution.loan.archive.png"/></imageobject></mediaobject> + </figure> + <para>So only when the <literal>archive</literal> wait state is reached, + the <literal>signal("approve")</literal> returns. + </para> + <para>Another signal like this:</para> + <programlisting>execution.signal("approve");</programlisting> + <para>will bring the execution eventually in the end state.</para> + <figure id="execution.loan.end"> + <title>Execution positioned in the 'end' node</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/execution.loan.end.png"/></imageobject></mediaobject> + </figure> + </section> + + <!-- ### EVENTS ######################################################### --> + <section id="events"> + <title>Events</title> + <para>Events are points in the process definition to which a list of + <literal>EventListener</literal>s can be subscribed. + </para> + <programlisting>public interface EventListener extends Serializable { + + void notify(EventListenerExecution execution) throws Exception; + +}</programlisting> + <para>The motivation for events is to allow for + developers to add programming logic to a process without changing the process diagram. + This is a very valuable instrument in facilitating the collaboration between business analysts + and developers. Business analysts + are responsible for expressing the requirements. When they use a process graph to document + those requirements, developers can take this diagram and make it executable. Events can + be a very handy to insert technical details into a process (like e.g. some database insert) + in which the business analyst is not interested. + </para> + <para>Most common events are fired by the execution automatically: + </para> + <para><emphasis role="bold">WARNING: the following event names will be + subject to change in the next release: see + <ulink url="https://jira.jboss.org/jira/browse/JBPM-1753">JBPM-1753... + </para> + <itemizedlist> + <listitem><literal><emphasis role="bold">Event.TRANSITION_TAKE</emphasis> = "transition-take"</literal> : + fired on transitions when transitions are taken. + </listitem> + <listitem><literal><emphasis role="bold">Event.NODE_BEGIN</emphasis> = "node-begin"</literal> : fired on the node + when execution enters that node. This happens when execution takes a transition + to that node, when a child node is being executed with <literal>execution.execute(Node)</literal> + or when a transition is taken from a node outside that node to a contained node. + The latter refers to super states in state machines. + </listitem> + <listitem><literal><emphasis role="bold">Event.NODE_END</emphasis> = "node-end"</literal> : fired on the node + when a transition is taken out of that node or when a child node execution is + finished and the execution is propagated to the parent node. + </listitem> + <listitem><literal><emphasis role="bold">Event.PROCESS_BEGIN</emphasis> = "process-begin"</literal> : fired on a process + when a new process is started. + </listitem> + <listitem><literal><emphasis role="bold">Event.PROCESS_END</emphasis> = "process-end"</literal> : fired on a process + when a new process is ended. This might include a executions that are ended + with a cancelled or error state. + </listitem> + </itemizedlist> + <para>Events are identified by the combination of a process element + and an event name. Users and process languages can also fire events + programmatically with the fire method on the Execution: + </para> + <programlisting>public interface Execution extends Serializable { + ... + void fire(String eventName, ProcessElement eventSource); + ... +}</programlisting> + + <para>A list of <literal>EventListeners</literal> can be associated to an + event. But event listeners can not influence the control flow of the execution since + they are merely listeners to an execution which is already in progress. This is different from + activities that serve as the behaviour for nodes. Node behaviour activities are responsible + for propagating the execution. + </para> + <para>We'll create a <literal>PrintLn</literal> event listener which is + very similar to the <literal>Display</literal> activity from above. + </para> + <programlisting>public class PrintLn implements EventListener { + + String message; + + public PrintLn(String message) { + this.message = message; + } + + public void notify(EventListenerExecution execution) throws Exception { + System.out.println("message"); + } +}</programlisting> + <para>Several <literal>PrintLn</literal> listeners will be subscribed to events in + the process.</para> + <figure id="action.process"> + <title>The PrintLn listener process</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/process.ab.png"/></imageobject></mediaobject> + </figure> + <programlisting>ClientProcessDefinition processDefinition = ProcessFactory.build() + .node("a").initial().behaviour(new AutomaticActivity()) + <emphasis role="bold">.event("node-end") + .listener(new PrintLn("leaving a")) + .listener(new PrintLn("second message while leaving a"))</emphasis> + .transition().to("b") + <emphasis role="bold">.listener(new PrintLn("taking transition"))</emphasis> + .node("b").behaviour(new WaitState()) + .event("node-begin") + <emphasis role="bold">.listener(new PrintLn("entering b"))</emphasis> +.done();</programlisting> + <para>The first event shows how to register multiple listeners to the same + event. They will be notified in the order as they are specified. + </para> + <para>Then, on the transition, there is only one type of event. So in that case, + the event type must not be specified and the listeners can be added directly on + the transition. + </para> + <para>A listeners will be called each time an execution fires the event to + which the listener is subscribed. The execution will be provided in the activity + interface as a parameter and can be used by listeners except for the methods that + control the propagation of execution. + </para> + </section> + + <!-- ### EVENT PROPAGATION ############################################## --> + <section> + <title>Event propagation</title> + <para>Events are by default propagated to enclosing process elements. The motivation + is to allow for listeners on process definitions or composite nodes that get executed + for all events that occur within that process element. For example this feature + allows to register an event listener on a process definition or a composite node on + <literal>node-end</literal> events. Such action will be executed if that node is + left. And if that event listener is registered on a composite node, it will also be executed + for all nodes that are left within that composite node. + </para> + <para>To show this clearly, we'll create a <literal>DisplaySource</literal> event listener + that will print the message <literal>leaving</literal> and the source of the event + to the console. + </para> + <programlisting>public class <emphasis role="bold">DisplaySource</emphasis> implements EventListener { + + public void execute(EventListenerExecution execution) { + <emphasis role="bold">System.out.println("leaving "+execution.getEventSource());</emphasis> + } +}</programlisting> + <para>Note that the purpose of event listeners is not to be visible, that's why the event listener + itself should not be displayed in the diagram. A <literal>DisplaySource</literal> event listener + will be added as a listener to the event <literal>node-end</literal> on the composite node. + </para> + <para>The next process shows how the <literal>DisplaySource</literal> event listener is registered + as a listener to to the 'node-end' event on the <literal>composite</literal> node:</para> + <figure id="process.propagate"> + <title>A process with an invisible event listener on a node-end event on a composite node.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/process.propagate.png"/></imageobject></mediaobject> + </figure> + <programlisting>ClientProcessDefinition processDefinition = ProcessFactory.build("propagate") + <emphasis role="bold">.compositeNode("composite") + .event(Event.NODE_END) + .listener(new DisplaySource())</emphasis> + .node("a").initial().behaviour(new WaitState()) + .transition().to("b") + .node("b").behaviour(new WaitState()) + .transition().to("c") + .compositeEnd() + .node("c").behaviour(new WaitState()) +.done();</programlisting> + <para>Next we'll start an execution.</para> + <programlisting>ClientExecution execution = processDefinition.startProcessInstance();</programlisting> + <para>After starting a new execution, the execution will be in node <literal>a</literal> as + that is the initial node. No nodes have been left so no message is logged. Next a signal + will be given to the execution, causing it to take the transition from <literal>a</literal> + to <literal>b</literal>. + </para> + <programlisting>execution.signal();</programlisting> + <para>When the signal method returns, the execution will have taken the transition and + the <literal>node-end</literal> event will be fired on node <literal>a</literal>. That + event will be propagated to the + composite node and to the process definition. Since our <literal>DisplaySource</literal> + event listener is placed + on the <literal>composite</literal> node, it will receive the event and print the following + message on the console: + </para> + <programlisting>leaving node(a)</programlisting> + <para>Another</para> + <programlisting>execution.signal();</programlisting> + <para>will take the transition from b to c. That will fire two node-leave events. One on + node b and one on node composite. So the following lines will be appended to the console + output:</para> + <programlisting>leaving node(b) +leaving node(composite)</programlisting> + <para>Event propagation is build on the hierarchical composition structure of the process + definition. The top level element is always the process definition. The process + definition contains a list of nodes. Each node can be a leaf node or it can be a + composite node, which means that it contains a list of nested nodes. Nested nodes + can be used for e.g. super states or composite activities in nested process languages like BPEL. + </para> + <para>So the even model also works similarly for composite nodes as it did for the process + definition above. Suppose that 'Phase one' models + a super state as in state machines. Then event propagation allows to subscribe to all events + within that super state. The idea is that the hierarchical composition corresponds to + diagram representation. If an element 'e' is drawn inside another element 'p', then p + is the parent of e. A process definition has a set of top level nodes. Every node can have + a set of nested nodes. The parent of a transition is considered as the first common + parent for it's source and destination. + </para> + <para>If an event listener is not interested in propagated events, propagation can be disabled + with <literal>propagationDisabled()</literal> while building the process with the + <literal>ProcessFactory</literal>. The next process is the same process + as above except that propagated events will be disabled on the event listener. The graph diagram + remains the same. + </para> + <figure id="process.propagate.propagation.disabled"> + <title>A process with an event listener to 'node-end' events with propagation disabled.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/process.propagate.png"/></imageobject></mediaobject> + </figure> + <para>Building the process with the process factory: + </para> + <programlisting>ClientProcessDefinition processDefinition = ProcessFactory.build("propagate") + .compositeNode("composite") + .event(Event.NODE_END) + .listener(new DisplaySource()) + <emphasis role="bold">.propagationDisabled()</emphasis> + .node("a").initial().behaviour(new WaitState()) + .transition().to("b") + .node("b").behaviour(new WaitState()) + .transition().to("c") + .compositeEnd() + .node("c").behaviour(new WaitState()) +.done();</programlisting> + <para>So when the first signal is given for this process, again the <literal>node-end</literal> + event will be fired on node <literal>a</literal>, but now the event listener on the composite + node will not be executed cause + propagated events have been disabled. Disabling propagation is a property on the individual + event listener and doesn't influence the other listeners. The event will always be fired and + propagated over the whole parent hierarchy. + </para> + <programlisting>ClientExecution execution = processDefinition.startProcessInstance();</programlisting> + <para>The first signal will take the process from <literal>a</literal> to + <literal>b</literal>. No messages will be printed to the console. + </para> + <programlisting>execution.signal();</programlisting> + <para>Next, the second signal will take the transition from b to c. + </para> + <programlisting>execution.signal()</programlisting> + <para>Again two <literal>node-end</literal> + events are fired just like above on nodes <literal>b</literal> and <literal>composite</literal> + respectively. The first event + is the <literal>node-end</literal> event on node <literal>b</literal>. That will be propagated + to the <literal>composite</literal> node. So the event + listener will not be executed for this event cause it has propagation disabled. But the + event listener will be executed for the <literal>node-end</literal> event on the + <literal>composite</literal> node. That is not + propagated, but fired directly on the <literal>composite</literal> node. So the event + listener will now be executed + only once for the composite node as shown in the following console output: + </para> + <programlisting>leaving node(composite)</programlisting> + </section> + +</chapter> Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch04-ImplementingBasicActivities.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch05-ProcessAnatomy.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch05-ProcessAnatomy.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch05-ProcessAnatomy.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,62 @@ +<chapter id="processanatomy"> + <title>Process anatomy</title> + + <para>Above we already touched briefly on the two main process constructs: + Nodes, transitions and node composition. This chapter explores in full + all the possibilities of the process definition structures. + </para> + + <para>There are basically two forms of process languages: graph based and composite + process languages. First of all, the process supports both. Even graph based execution + and node composition can be used in combination to implement something like UML super states. + Furthermore, automatic functional activities can be implemented so that they can be + used with transitions as well as with node composition. + </para> + + <figure id="process.anatomy"> + <title>UML class diagram of the logical process structure</title> + <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 + with the PVM process model. + </para> + + <figure id="transition"> + <title>Any two nodes can be connected with a transition.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/transition.png"/></imageobject></mediaobject> + </figure> + + <figure id="self.transition"> + <title>A self transition.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/self.transition.png"/></imageobject></mediaobject> + </figure> + <figure id="composite.node"> + <title>Composite node is a list of nested nodes.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/composite.node.png"/></imageobject></mediaobject> + </figure> + <figure id="transition.into.composite"> + <title>Transition to a node inside a composite.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/transition.into.composite.png"/></imageobject></mediaobject> + </figure> + <figure id="transition.out.of.composite"> + <title>Transition from a node inside a composite to a node outside the composite.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/transition.out.of.composite.png"/></imageobject></mediaobject> + </figure> + <figure id="transition.inheritence"> + <title>Transition of composite nodes are inherited. The node inside can take the transition of the composite node.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/transition.inheritence.png"/></imageobject></mediaobject> + </figure> + <figure id="transition.to.outer"> + <title>Transition from a node to an outer composite.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/transition.to.outer.png"/></imageobject></mediaobject> + </figure> + <figure id="transition.to.inner"> + <title>Transition from a composite node to an inner composed node.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/transition.to.inner.png"/></imageobject></mediaobject> + </figure> + <figure id="initial.in.composite"> + <title>An initial node inside a composite node.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/initial.in.composite.png"/></imageobject></mediaobject> + </figure> +</chapter> \ No newline at end of file Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch05-ProcessAnatomy.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch06-ImplementingAdvancedActivities.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch06-ImplementingAdvancedActivities.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch06-ImplementingAdvancedActivities.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,393 @@ +<chapter id="advancedgraphexecution"> + <title>Advanced graph execution</title> + + <!-- ### LOOPS ########################################################## --> + <section> + <title>Loops</title> + <para>Activities can implement loops based on transitions or on node composition. + Loops can contain wait states. + </para> + <para>To support high numbers of automatic loop executions, the Process Virtual Machine + tranformed the propagation of execution from tail recursion to a while loop. + </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 node behaviour, it can + explicitely propagate the execution with following methods: + </para> + <itemizedlist> + <listitem><literal>waitForSignal()</literal></listitem> + <listitem><literal>take(Transition)</literal></listitem> + <listitem><literal>end(*)</literal></listitem> + <listitem><literal>execute(Node)</literal></listitem> + <listitem><literal>createExecution(*)</literal></listitem> + </itemizedlist> + <para>When <literal>Activity</literal> implementations used for node 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> + <para>The implicit proceed behaviour is defined as follows:</para> + <itemizedlist> + <listitem>If the current node has a default outgoing transition, take it.</listitem> + <listitem>If the current node has a parent node, move back to the parent node.</listitem> + <listitem>Otherwise, end this execution.</listitem> + </itemizedlist> + <para>Process languages can overwrite the implicit proceed behaviour + by overriding the <literal>proceed</literal> method in + <literal>ExecutionImpl</literal>. + </para> + </section> + + <!-- ### FUNCTIONAL ACTIVITIES ################################ --> + <section id="functionalactivities"> + <title>Functional activities</title> + <para>Activities 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 { + public void execute(ActivityExecution execution) { + perform(execution); + } + public void notify(EventListenerExecution execution) { + perform(execution); + } + void perform(OpenExecution execution) { + ...do functional work... + } + }</programlisting> + <para>The <literal>perform</literal> method takes an <literal>OpenExecution</literal>, + which is the supertype of both <literal>ActivityExecution</literal> and + <literal>EventListenerExecution</literal>. <literal>OpenExecution</literal> + does not allow any of the specific purpose methods, but still + the current state and the process definition can be inspected as well + as the variables, which contain the context information for the process + execution. + </para> + <para>None of these methods actually invoke execution propagation methods. + So after the perform method is completed, the execution will + <link linkend="implicitproceedbehaviour">proceed in the default way</link>. + </para> + </section> + + + <!-- ### EXECUTION AND THREADS ########################################## --> + <section id="executionandthreads"> + <title>Execution and threads</title> + <para>This section explains how the Process Virtual Machine boroughs the thread + from the client to bring an execution from one wait state to another. + </para> + <para>When a client invokes a method (like e.g. the signal method) on an execution, + by default, the Process Virtual Machine will use that thread to progress the execution + until it reached a wait state. Once the next wait state has been reached, the + method returns and the client gets the thread back. This is the default way + 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>. + </para> + <para>The next process will show the basics concretely. It has three wait states + and four automatic nodes. + </para> + <figure id="process.automatic"> + <title>Process with many sequential automatic activities.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/process.automatic.png"/></imageobject></mediaobject> + </figure> + <para>Here's how to build the process:</para> + <programlisting>ClientProcessDefinition processDefinition = ProcessFactory.build("automatic") + .<emphasis role="bold">node("wait 1").initial()</emphasis>.behaviour(new <emphasis role="bold">WaitState</emphasis>()) + .transition().to("automatic 1") + .<emphasis role="bold">node("automatic 1")</emphasis>.behaviour(new <emphasis role="bold">Display("one")</emphasis>) + .transition().to("wait 2") + .<emphasis role="bold">node("wait 2")</emphasis>.behaviour(new <emphasis role="bold">WaitState</emphasis>()) + .transition().to("automatic 2") + .<emphasis role="bold">node("automatic 2")</emphasis>.behaviour(new <emphasis role="bold">Display("two")</emphasis>) + .transition().to("automatic 3") + .<emphasis role="bold">node("automatic 3")</emphasis>.behaviour(new <emphasis role="bold">Display("three")</emphasis>) + .transition().to("automatic 4") + .<emphasis role="bold">node("automatic 4")</emphasis>.behaviour(new <emphasis role="bold">Display("four")</emphasis>) + .transition().to("wait 3") + .<emphasis role="bold">node("wait 3")</emphasis>.behaviour(new <emphasis role="bold">WaitState</emphasis>()) +.done();</programlisting> + <para>Let's walk you through one execution of this process. + </para> + <programlisting>ClientExecution execution = processDefinition.startProcessInstance();</programlisting> + <para>Starting a new execution means that the initial node is executed. So if an automatic + activity is the initial node, this means that immediately the first unnamed outgoing transition + is taken. This happens all inside of the invocation of <literal>startProcessInstance</literal>. + </para> + <para>In this case however, the initial node is a wait state. So + the method <literal>startProcessInstance</literal> returns immediately and the execution will be + positioned in the initial node 'wait 1'. + </para> + <figure id="execution.automatic.wait1"> + <title>A new execution will be positioned in 'wait 1'.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/execution.automatic.wait1.png"/></imageobject></mediaobject> + </figure> + <para>Then an external trigger is given with the signal method.</para> + <programlisting>execution.signal();</programlisting> + <para>As explained above when <link linkend="externalactivityexample">introducing the WaitState</link>, + that signal will cause the default transition to be taken. The + transition will move the execution to node <literal>automatic 1</literal> and execute it. + The execute method of the <literal>Display</literal> activity in <literal>automatic 1</literal> + print a line to the console and it will <emphasis role="bold">not</emphasis> call + <literal>execution.waitForSignal()</literal>. Therefore, the execution will proceed by + taking the default transition out of <literal>automatic 1</literal>. At this stage, the + signal method is still blocking. Another way to think about it is that the execution + methods like <literal>signal</literal> will use the thread of the client to interpret + the process definition until a wait state is reached. + </para> + <para>Then the execution arrives in <literal>wait 2</literal> and executes + the <literal>WaitState</literal> activity. That method will invoke + the <literal>execution.waitForSignal()</literal>, which will cause the signal method + to return. That is when the thread is given back to the client that invoked the + <literal>signal</literal> method. + </para> + <para>So when the signal method returns, the execution is positioned in <literal>wait 2</literal>.</para> + <figure id="execution.automatic.wait2"> + <title>One signal brought the execution from 'initial' to 'wait 2'.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/execution.automatic.wait2.png"/></imageobject></mediaobject> + </figure> + <para>Then the execution is now waiting for an external trigger just as an object + (more precisely an object graph) in memory until the next external trigger is given + with the signal method. + </para> + <programlisting>execution.signal();</programlisting> + <para>This second invocation of signal will take the execution similarly all the + way to <literal>wait 3</literal> before it returns. + </para> + <figure id="automatic.wait3"> + <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"> + persistent execution mode</link>, depending on the application and on the environment. + </para> + <para>When executing a process in persistent mode, this is how you typically want + to bind that process execution to transactions of the database: + </para> + <figure id="transactions.png"> + <title>Transactions over time in persistent execution mode.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/transactions.png"/></imageobject></mediaobject> + </figure> + <para>In most situations, the computational work that needs to be done as part of + the process after an external trigger (the red pieces) is pretty minimal. Typically + transactions combining the process execution and processing the request from the + UI takes typically less then a second. Whereas the wait state in business processes + typically can span for hours, days or even years. The clue is to clearly distinct + when a wait state starts so that only the computational work done before the start + of that wait state should be included in the transaction. + </para> + <para>Think of + it this way: &quot;When an approval arrives, what are all the automated processing that + needs to be done before the process system needs to wait for another external + trigger?&quot; Unless pdf's need to be generated or mass emails need to be send, + the amount of time that this takes is usually neglectable. That is why in the + default persistent execution mode, the process work is executed in the thread + of the client. + </para> + <para>This reasoning even holds in case of concurrent paths of execution. + When a single path of execution splits into concurrent paths of execution, + the process overhead of calculating that is neglectable. So that is why it + makes sense for a fork or split activity implementation that targets persistent + execution mode to spawn the concurrent paths sequentially in the same thread. + Basically it's all just computational work as part of the same transaction. + This can only be done because the fork/split knows that each concurrent path + of execution will return whenever a wait state is encountered. + </para> + <para>Since this is a difficult concept to grasp, I'll explain it again with other + words. Look at it from the overhead that is produced by the process execution + itself in persistent execution mode. If in a transaction, an execution is given + an external trigger and that causes the execution to split into multiple concurrent + paths of execution. Then the process overhead of calculating this is neglectable. + Also the overhead of the generated SQL is neglectable. And since all the work done + in the concurrent branches must be done inside that single transaction, there is + typically no point in having fork/split implementations spawn the concurrent + paths of execution in multiple threads. + </para> + <para>To make executable processes, developers need to know exactly what the automatic activities + are, what the wait states are and which threads will be allocated to the process execution. + For business analysts that draw the analysis process, things are a bit simpler. For the + activities they draw, they usually know whether it's a human or a system that is responsible. + But they typically don't not how this translates to threads and transactions. + </para> + <para>So for the developer, the first job is to analyse what needs to be executed + within the thread of control of the process and what is outside. Looking for the external + triggers can be a good start to find the wait states in a process, just like verbs and nouns + can be the rule of thumb in building UML class diagrams. + </para> + </section> + + <!-- ### PROCESS CONCURRENCY ############################################ --> + <section> + <title>Process concurrency</title> + <para>To model process concurrency, there is a parent-child tree structure on the + execution. The idea is that the main path of execution is the root of that tree. + The main path of execution is also called the process instance. It is the execution + that is created when starting or creating a new process instance for a given + process definition. + </para> + <para>Now, because the main path of execution is the same object as the + process instance, this keeps the usage simple in case of simple processes + without concurrency. + </para> + <figure id="execution.structure"> + <title>UML class diagram of the basic execution structure</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/class.diagram.process.execution.png"/></imageobject></mediaobject> + </figure> + <para>To establish multiple concurrent paths of execution, activity implementations + like a fork or split can create child executions with method + <literal>ActivityExecution.createExecution</literal>. Activity implementations + like join or merge can stop these concurrent paths of execution by calling + method <literal>stop</literal> on the concurrent execution. + </para> + <para>Only leaf executions can be active. Non-leave executions should be + inactive. This tree structure of executions doesn't enforce a particular type of + concurrency or join behaviour. It's up to the forks or and-splits and to the joins + or and-merges to use the execution tree structure in any way they want to define + the wanted concurrency behaviour. Here you see an example + of concurrent executions. + </para> + <figure id="concurrency"> + <title>Concurrent paths of execution</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/execution.concurrency.png"/></imageobject></mediaobject> + </figure> + <para>There is a billing and a shipping path of execution. In this case, the + flat bar nodes represent nodes that fork and join. The execution shows a three + executions. The main path of execution is inactive (represented as gray) and the + billing and shipping paths of execution are active and point to the node + <literal>bill</literal> and <literal>ship</literal> respectively. + </para> + <para>It's up to the node behaviour implementations how they want to use this + execution structure. Suppose that multiple tasks have to be completed before the + execution is to proceed. The node behaviour can spawn a series of child executions + for this. Or alternatively, the task component could support task groups that + are associated to one single execution. In that case, the task component becomes + responsible for synchronizing the tasks, thereby moving this responsibility + outside the scope of the execution tree structure. + </para> + </section> + + <!-- ### EXCEPTION HANDLERS ############################################# --> + <section> + <title>Exception handlers</title> + <para>In all the code that is associated to a process + like <literal>Activity</literal>s, <literal>EventListeners</literal> and + <literal>Condition</literal>s, it's possible to associate exception handlers. This + can be thought of as including try-catch blocks in + the method implementations of those implementations. But in order to build more reusable building + blocks for both the delegation classes and the exception handling logic, exception handlers are + added to the core process model. + </para> + <para>An exception handler can be associated to any process element. When an exception + occurs in a delegation class, a matching exception handler will be searched for. If + such an exception handler is found, it will get a chance to handle the exception. + </para> + <para>If an exception handler completes without problems, then the exception is considered + handled and the execution resumes right after the delegation code that was called. For example, + a transition has three actions and the second action throws an exception that is handled + by an exception handler, then + </para> + <para>Writing automatic activities that are exception handler aware is easy. The + default is to proceed anyway. No method needs to be called on the execution. So + if an automatic activity throws an exception that is handled by an exception handler, + the execution will just proceed after that activity. It becomes a big more difficult + for control flow activities. They might have to include try-finally blocks to + invoke the proper methods on the execution before an exception handler gets a + chance to handle the exception. For example, if an activity is a wait state and + an exception occurs, then there is a risk that the thread jumps over the + invocation of <literal>execution.waitForSignal()</literal>, causing the execution + to proceed after the activity. + </para> + <para>TODO: exceptionhandler.isRethrowMasked</para> + <para>TODO: transactional exception handlers</para> + <para>TODO: we never catch errors</para> + </section> + + <!-- ### PROCESS MODIFICATIONS ########################################## --> + <section> + <title>Process modifications</title> + <para>TODO: process modifications</para> + </section> + + <!-- ### LOCKING AND EXECUTION STATE #################################### --> + <section> + <title>Locking and execution state</title> + <para>The state of an execution is either active or locked. An active + execution is either executing or waiting for an external trigger. If an + execution is not in <literal>STATE_ACTIVE</literal>, then it is locked. + A locked execution is read only and cannot receive any external triggers. + </para> + <para>When a new execution is created, it is in STATE_ACTIVE. To change + the state to a locked state, use lock(String). Some STATE_* constants + are provided that represent the most commonly used locked states. But + the state '...' in the picture indicates that any string can be provided + as the state in the lock method. + </para> + <figure id="execution.states"> + <title>States of an execution</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/ch04.execution.states.png"/></imageobject></mediaobject> + </figure> + <para>If an execution is locked, methods that change the execution will + throw a PvmException and the message will reference the actual locking state. + Firing events, updating variables, updating priority and adding comments + are not considered to change an execution. Also creation and removal of child + executions are unchecked, which means that those methods can be invoked by + external API clients and node behaviour methods, even while the execution + is in a locked state. + </para> + <para>Make sure that comparisons between getState() and the STATE_* constants + are done with .equals and not with '==' because if executions are loaded + from persistent storage, a new string is created instead of the constants. + </para> + <para>An execution implementation will be locked: + </para> + <itemizedlist> + <listitem>When it is ended</listitem> + <listitem>When it is suspended</listitem> + <listitem>During asynchronous continuations</listitem> + </itemizedlist> + <para>Furthermore, locking can be used by Activity implementations to make + executions read only during wait states hen responsibility for the execution is + transferred to an external entity such as: + </para> + <itemizedlist> + <listitem>A human task</listitem> + <listitem>A service invocation</listitem> + <listitem>A wait state that ends when a scanner detects that a file appears</listitem> + </itemizedlist> + <para>In these situations the strategy is that the external entity should get + full control over the execution because it wants to control what is allowed + and what not. To get that control, they lock the execution so that all interactions + have to go through the external entity. + </para> + <para>One of the main reasons to create external entities is that they can live + on after the execution has already proceeded. For example, in case + of a service invocation, a timer could cause the execution to take the timeout transition. + When the response arrives after the timeout, the service invocation entity should + make sure it doesn't signal the execution. So the service invocation can be + seen as a node instance (aka activity instance) and is unique for every execution + of the node. + </para> + <para>External entities themselves are responsible for managing the execution + lock. If the timers and client applications are consequent in addressing the + external entities instead of the execution directly, then locking is in theory + unnecessary. It's up to the node behaviour implementations whether they want + to take the overhead of locking and unlocking. + </para> + </section> + +</chapter> Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch06-ImplementingAdvancedActivities.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch07-Variables.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch07-Variables.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch07-Variables.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,4 @@ +<chapter id="variables"> + <title>Variables</title> + <para>TODO</para> +</chapter> \ No newline at end of file Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch07-Variables.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch08-Timers.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch08-Timers.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch08-Timers.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,4 @@ +<chapter id="timers"> + <title>Timers</title> + <para>TODO</para> +</chapter> \ No newline at end of file Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch08-Timers.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch09-AsynchronousContinuations.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch09-AsynchronousContinuations.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch09-AsynchronousContinuations.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,4 @@ +<chapter id="asynchronouscontinuations"> + <title>Asynchronous continuations</title> + <para>TODO</para> +</chapter> Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch09-AsynchronousContinuations.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch10-SoftwareLogging.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch10-SoftwareLogging.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch10-SoftwareLogging.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,99 @@ +<chapter id="softwarelogging"> + <title>Software logging</title> + + <section> + <title>Configuration</title> + <para>PVM can use JDK logging (java.util.logging) or log4j. When the first message is + logged, PVM logging will make the selection with following procedure: + <orderedlist> + <listitem>If a <literal>logging.properties</literal> resource is found + on the classpath (using the context classloader), then JDK logging will + be used and that file will be used to initialize the JDK logging. + </listitem> + <listitem>If log4j is found on the classpath, then log4j will be used. + The check for log4j will be done by checking availability of class + <literal>org.apache.log4j.LogManager</literal> with the context classloader. + </listitem> + <listitem>If none of the above, JDK logging will be used.</listitem> + </orderedlist> + </para> + </section> + + <section> + <title>Categories</title> + <para>The PVM classes use their class name as the category for the logger. + </para> + <para>To have a basic understanding of what the PVM classes are doing, + turning on the <literal>debug</literal> level is great. Level + <literal>trace</literal> might be spitting out too much for that + purpose. + </para> + </section> + + <section> + <title>JDK logging</title> + <para>In JDK logging, <literal>debug</literal>maps to <literal>fine</literal> + and <literal>trace</literal> maps to <literal>finest</literal>. + Level <literal>finer</literal> is not used. + </para> + <para><literal>org.jbpm.pvm.internal.log.LogFormatter</literal> is part of + the pvm library and it can create a nice one-line output for log messages. + It also has a neat feature that creates a unique indentation per thread. + To configure it, this is a typical <literal>logging.properties</literal> + </para> + <programlisting>handlers = java.util.logging.ConsoleHandler +java.util.logging.ConsoleHandler.level = FINEST +java.util.logging.ConsoleHandler.formatter = org.jbpm.pvm.internal.log.LogFormatter + +# For example, set the com.xyz.foo logger to only log SEVERE messages: +# com.xyz.foo.level = SEVERE + +.level = SEVERE +org.jbpm.level=FINE +org.jbpm.tx.level=FINE +org.jbpm.pvm.internal.wire.level=FINE</programlisting> + +<!-- + <para>For production usage, jBPM also includes an error triggered log handler. This is + a log handler that will only keep the most recent log messages in + memory and these will only be flushed to a file in case an error occurs. + </para> + <para>to configure it, add <literal>org.jbpm.util.ErrorTriggeredFileHandler</literal> + to the handlers in the logging properties like this: + </para> + <programlisting>handlers = java.util.logging.ConsoleHandler org.jbpm.util.ErrorTriggeredFileHandler</programlisting> + <para>Next snippet shows how in the same logging.properties, the error + triggered file handler can be configured. The given values are the default + values. + </para> + <programlisting>org.jbpm.util.ErrorTriggeredFileHandler.size = 500 +org.jbpm.util.ErrorTriggeredFileHandler.push = SEVERE +org.jbpm.util.ErrorTriggeredFileHandler.pattern = %h/jbpm%u.log</programlisting> + <para>Alternatively to using the org.jbpm.util.ErrorTriggeredFileHandler, the + JDK handlers FileHandler and MemoryHandler can used in combination to get + similar results with a bit more configuration. + </para> + +--> + </section> + + <section> + <title>Debugging persistence</title> + <para>When testing the persistence, following logging configurations can be + valuable. Category <literal>org.hibernate.SQL</literal> shows the SQL statement that is executed + and category <literal>org.hibernate.type</literal> shows the values of the parameters that are + set in the queries. + </para> + <programlisting>org.hibernate.SQL.level=FINEST +org.hibernate.type.level=FINEST</programlisting> + <para>And in case you get a failed batch as a cause in a hibernate exception, + you might want to set the batch size to 0 like this in the hibernate properties: + </para> + <programlisting>hibernate.jdbc.batch_size = 0</programlisting> + <para>Also in the hibernate properties, the following properties allow for + detailed logs of the SQL that hibernate spits out:</para> + <programlisting>hibernate.show_sql = true +hibernate.format_sql = true +hibernate.use_sql_comments = true</programlisting> + </section> +</chapter> \ No newline at end of file Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/ch10-SoftwareLogging.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-DelegationClasses.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-DelegationClasses.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-DelegationClasses.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,53 @@ +<chapter id="delegationclasses"> + <title>Delegation classes</title> + + <section> + <title>What are delegation classes</title> + <para>Delegation classes are the classes that implement + <literal>Activity</literal> or <literal>Condition</literal>. From the Process + Virtual Machine's perspective, these are external classes that provide + programming logic that is inserted into the PVM's graph execution. + Delegation classes can be provided by the process languages as well + as by the end users. + </para> + </section> + + <section> + <title>Configuration of delegation classes</title> + <para>Delegation classes can be made configurable. Member fields can + contain configuration parameters so that a delegation class can be + configured differently each time it is used. For example, in the + <literal><link linkend="activity">Display</link></literal> activity, + the message that is to be printed to the console is a configuration + parameter. + </para> + <para>Delegation classes should be stateless. This means that executing the interface + methods should not change values of the member fields. Changing member field values + of delegation classes during execution methods is actually changing the process + while it's executing. That is not threadsafe and usually leads to unexpected + results. As an exception, getters and setters might be made available to inject + the configuration cause they are used before the delegation object is actually + used in the process execution. + </para> + </section> + + <section> + <title>Object references</title> + <para>TODO</para> + </section> + + <section> + <title>Design time versus runtime</title> + <para>TODO: the node behaviour allows for design time as well as runtime behaviour.</para> + </section> + + <section> + <title>UserCodeInterceptor</title> + <para>TODO: UserCodeInterceptor</para> + </section> + + <section> + <title>Member field configurations versus properties</title> + <para>TODO: document field configurations versus properties</para> + </section> +</chapter> \ No newline at end of file Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-DelegationClasses.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-Environment.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-Environment.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-Environment.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,139 @@ +<chapter id="environment"> + <title>Environment</title> + + <section> + <title>Introduction</title> + <para>The environment component together with the wire context is a kind of + Inversion of Control (IoC) container. It reads configuration information that + describes how objects should be instantiated, configured and wired together. + </para> + <para>The environment is used to retrieve resources and services needed by + <literal>Activity</literal> implementations and the Process Virtual Machine + itself. The main purpose is to make various aspects of the Process Virtual Machine + configurable so that the PVM and the languages that run on top can work + in a standard Java environment as well as an enterprise Java environment. + </para> + <para>The environment is partitioned into a set of contexts. Each context + can have its own lifecycle. For instance, the environment-factory context will + strech over the full lifetime of the application. The block context only + for the duration of a try-finally block. Typically a block context represents + a database transaction. Each context exposes a list of key-value + pairs. + </para> + </section> + + <section id="environmentfactory"> + <title>EnvironmentFactory</title> + <para>To start working with an environment, you need an EnvironmentFactory. + One single environment factory object can be used throughout the complete + lifetime of the application. So typically this is kept in a static + member field. The EnvironmentFactory itself is the environment-factory context. + </para> + <para>An <literal>EnvironmentFactory</literal> is typically obtained by + parsing a configuration file like this: + </para> + <programlisting>static EnvironmentFactory environmentFactory = + EnvironmentFactory.parse(new ResourceStreamSource("pvm.cfg.xml");</programlisting> + <para>See javadocs package org.jbpm.stream for more types of stream sources. + </para> + <para>There is a default parser in the environment factory that will + create <literal>DefaultEnvironmentFactory</literal>s. The idea is that we'll + also support spring as an IoC container. But that is still TODO. Feel free + to help us out :-). The parser can be configured with the static setter + method <literal>EnvironmentFactory.setParser(Parser)</literal> + </para> + </section> + + <section id="environmentblock"> + <title>Environment block</title> + <para>An environment exists for the duration of a try-finally block. This is how + an environment block looks like: + </para> + <programlisting><emphasis role="bold">Environment environment = environmentFactory.openEnvironment(); +try { + + ... + +} finally { + environment.close(); +}</emphasis></programlisting> + <para>The environment block defines another lifespan: the <literal>block</literal> context. + A transaction would be a typical example of an object that is defined in the block + context. + </para> + <para>Inside such a block, objects can be looked up from the environment by name + or by type. If objects can looked up from the environment with method + <literal>environment.get(String name)</literal> or + <literal>&lt;T&gt; T environment.get(Class&lt;T&gt;)</literal>. + </para> + <para>when an environment is created, it has a <literal>environment-factory</literal> context + and a <literal>block</literal> + context. + </para> + <para>In the default implementation, the <literal>environment-factory</literal> context and + the <literal>block</literal> context are <literal>WireContext</literal>s. A + <literal>WireContext</literal> contains a description of how its objects are + created and wired together to form object graphs. + </para> + </section> + + <section> + <title>Example</title> + <para>To start with a simple example, we'll need a <literal>Book</literal>:</para> + <programlisting>public class <emphasis role="bold">Book</emphasis> { + ... + public Book() {} + ... +}</programlisting> + <para>Then let's create an environment factory that knows how to create book</para> + <programlisting>static EnvironmentFactory environmentFactory = EnvironmentFactory.parseXmlString( + "&lt;contexts&gt;" + + " &lt;environment-factory&gt;" + + " &lt;object name='book' class='org.jbpm.examples.ch09.Book' /&gt;" + + " &lt;/environment-factory&gt;" + + "&lt;/contexts&gt;" +));</programlisting> + <para>Now we'll create an environment block with this environment factory and + we'll look up the book in the environment. First the lookup is done by + type and secondly by name. + </para> + <programlisting>Environment environment = environmentFactory.openEnvironment(); +try { + + Book book = <emphasis role="bold">environment.get(Book.class);</emphasis> + assertNotNull(book); + + assertSame(book, <emphasis role="bold">environment.get("book")</emphasis>); + +} finally { + environment.close(); +}</programlisting> + <para>To prevent that you have to pass the environment as a parameter in + all methods, the current environment is maintained in a threadlocal stack: + </para> + <programlisting>Environment environment = Environment.getCurrent();</programlisting> + </section> + + <section id="context"> + <title>Context</title> + <para>Contexts can be added and removed dynamically. Anything can be exposed + as a <literal>Context</literal>. + </para> + <programlisting>public interface <emphasis role="bold">Context</emphasis> { + + <emphasis role="bold">Object get(String key); + &lt;T&gt; T get(Class&lt;T&gt; type); + Set&lt;String&gt; keys();</emphasis> + + ... +}</programlisting> + <para>When doing a lookup on the environment, there is a default search order + in which the contexts will be scanned for the requested object. The default + order is the inverse of the sequence in which the contexts were added. E.g. + if an object is defined in both the environment-factory context and in the block context, + the block context is considered more applicable and that will be scanned first. + Alternatively, an explicit search order can be passed in with the + <literal>get</literal> lookups as an optional parameter. + </para> + </section> +</chapter> \ No newline at end of file Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-Environment.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-History.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-History.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-History.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,15 @@ +<chapter id="history"> + <title>History</title> + + <section id="processlogs"> + <title>Process logs</title> + </section> + + <section id="businessintelligence"> + <title>Business Intelligence (BI)</title> + </section> + + <section id="businessactivitymonitoring"> + <title>Business Activity Monitoring (BAM)</title> + </section> +</chapter> \ No newline at end of file Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-History.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-Persistence.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-Persistence.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-Persistence.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,266 @@ +<chapter id="persistence"> + <title>Persistence</title> + + <section> + <title>Standard environment configuration</title> + <para>This section describes how the environment can be configured to use + hibernate in a standard Java environment. + </para> + <programlisting>01 | &lt;contexts&gt; +02 | +03 | &lt;environment-factory&gt; +04 |<emphasis role="bold"> &lt;hibernate-session-factory /&gt;</emphasis> +05 |<emphasis role="bold"> &lt;hibernate-configuration&gt;</emphasis> +06 |<emphasis role="bold"> &lt;properties resource="hibernate.properties" /&gt;</emphasis> +07 |<emphasis role="bold"> &lt;mappings resource="org/jbpm/pvm/pvm.hibernate.mappings.xml" /&gt;</emphasis> +08 |<emphasis role="bold"> &lt;cache-configuration </emphasis> +09 |<emphasis role="bold"> resource="org/jbpm/pvm/pvm.cache.xml" </emphasis> +10 |<emphasis role="bold"> usage="nonstrict-read-write" /&gt;</emphasis> +11 |<emphasis role="bold"> &lt;/hibernate-configuration&gt;</emphasis> +12 | &lt;/environment-factory&gt; +13 | +14 | &lt;block&gt; +15 |<emphasis role="bold"> &lt;standard-transaction /&gt;</emphasis> +16 |<emphasis role="bold"> &lt;hibernate-session /&gt;</emphasis> +17 |<emphasis role="bold"> &lt;pvm-db-session /&gt;</emphasis> +18 | &lt;/block&gt; +19 | +20 | &lt;/contexts&gt;</programlisting> + <para><literal>line 04</literal> specifies a hibernate session factory in the + environment-factory context. This means that a hibernate session factory is lazy + created when it is first needed and cached in the + <literal>EnvironmentFactory</literal>. + </para> + <para>A hibernate session factory is build calling the + method <literal>buildSessionFactory()</literal> on a hibernate configuration. + By default, the hibernate configuration will be looked up by type. + </para> + <para><literal>line 05</literal> specifies a hibernate configuration. + </para> + <para><literal>line 06</literal> specifies the that the resource file + <literal>hibernate.properties</literal> should be loaded into the configuration. + </para> + <para><literal>line 07</literal> (note the plural form of mapping<emphasis role="bold">s</emphasis>) + specifies that resources <literal>org/jbpm/pvm/pvm.hibernate.mappings.xml</literal> contain references + to hibernate mapping files or resources that should be included into the + configuration. Also note the plural form of <literal>resources</literal>. + This means that not one, but all the resource files on the whole classpath will be found. + This way new library components containing a <literal>org/jbpm/pvm/pvm.hibernate.mappings.xml</literal> + resource can plug automatically into the same hibernate session by just being added to + the classpath. + </para> + <para>Alternatively, individual hibernate mapping files can be referenced with the + singular <literal>mapping</literal> element. + </para> + <para><literal>line 08 - 10</literal> provide a single place to specify the + hibernate caching strategy for all the PVM classes and collections. + </para> + <para><literal>line 15</literal> specifies a standard transaction. This is + a very simple global transaction strategy without recovery that can be used + in standard environments to get all-or-nothing semantics over multiple + transactional resources. + </para> + <para><literal>line 16</literal> specifies the hibernate session that will + automatically register itself with the standard transaction. + </para> + <para><literal>line 17</literal> specifies a <literal>PvmDbSession</literal>. + That is a class that adds methods that bind to specific queries to be executed + on the hibernate session. + </para> + </section> + + <section> + <title>Standard hibernate configuration</title> + <para>Here is a set of default properties to configure hibernate with + hsqldb in a standard Java environment. + </para> + <programlisting>hibernate.dialect org.hibernate.dialect.HSQLDialect +hibernate.connection.driver_class org.hsqldb.jdbcDriver +hibernate.connection.url jdbc:hsqldb:mem:. +hibernate.connection.username sa +hibernate.connection.password +hibernate.cache.use_second_level_cache true +hibernate.cache.provider_class org.hibernate.cache.HashtableCacheProvider</programlisting> + <para>Optionally in development the schema export can be used to + create the schema when the session factory is created and drop the + schema when the session factory is closed. + </para> + <programlisting>hibernate.hbm2ddl.auto create-drop</programlisting> + <para>For more information about hibernate configurations, see the hibernate + reference manual. + </para> + </section> + + <section> + <title>Standard transaction</title> + <para>By default, the <literal>&lt;hibernate-session /&gt;</literal> will + start a hibernate transaction with <literal>session.beginTransaction()</literal>. + Then the hibernate transaction is wrapped in a <literal>org.jbpm.pvm.internal.hibernate.HibernateTransactionResource</literal> + and that resource is enlisted with the <literal>&lt;standard-transaction /&gt;</literal> + (<literal>org.jbpm.tx.StandardTransaction</literal>) + </para> + <para>Inside of the environment block, the transaction is available + through <literal>environment.getTransaction()</literal>. So inside an + environment block, the transaction can be rolled back with + <literal>environment.getTransaction().setRollbackOnly()</literal> + </para> + <para>When created, the standard transaction will register itself to be notified on the + close of the environment. So in side the close, the standard transaction will + commit or rollback depending on whether <literal>setRollbackOnly()</literal> + was called. + </para> + <para>So in the configuration shown above, each environment block will be + a separate transaction. At least, if the hibernate session is used.</para> + </section> + + <section> + <title>Basics of process persistence</title> + <para>In the next example, we'll show how this hibernate persistence is + used with a concrete example. The 'persistent process' is a simple + three-step process: + </para> + <figure id="the.persistent.process"> + <title>The persistent process</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/ch09.persistent.process.png"/></imageobject></mediaobject> + </figure> + <para>The activities in the three nodes will be wait states just like + in <xref linkend="externalactivityexample" /> + </para> + <para>To make sure we can persist this class, we create the hibernate mapping for + it and add it to the configuration like this: + </para> + <programlisting>&lt;hibernate-configuration&gt; + &lt;properties resource="hibernate.properties" /&gt; + &lt;mappings resource="org/jbpm/pvm/pvm.hibernate.mappings.xml" /&gt; + <emphasis role="bold">&lt;mapping resource="org/jbpm/examples/ch09/state.hbm.xml" /&gt;</emphasis> + &lt;cache-configuration + resource="org/jbpm/pvm/pvm.cache.xml" + usage="nonstrict-read-write" /&gt;</programlisting> + <para>The next code pieces show the contents of one unit test method. The method + will first create the environment factory. Then, in a first transaction, a process + definition will be created and saved into the database. Then the next transaction will + create a new execution of that process. And the following two transactions will + provide external triggers to the execution. + </para> + <programlisting>EnvironmentFactory environmentFactory = EnvironmentFactory.parse(new ResourceStreamSource( + "org/jbpm/examples/ch09/environment.cfg.xml" +));</programlisting> + <para>Then in a first transaction, a process is created and saved in the database. + This is typically referred to as deploying a process and it only needs to be done + once. + </para> + <programlisting>Environment environment = environmentFactory.openEnvironment(); +try { + PvmDbSession pvmDbSession = environment.get(PvmDbSession.class); + + ProcessDefinition processDefinition = ProcessFactory.build("persisted process") + .node("one").initial().behaviour(new State()) + .transition().to("two") + .node("two").behaviour(new State()) + .transition().to("three") + .node("three").behaviour(new State()) + .done(); + + pvmDbSession.save(processDefinition); +} finally { + environment.close(); +}</programlisting> + <para>In the previous transaction, the process definition, the nodes and transitions + will be inserted into the database tables. + </para> + <para>Next we'll show how a new process execution can be started for this + process definition. Note that in this case, we provide <link linkend="businesskey">a + business key</link> called 'first'. This will make it easy for us to retrieve + the same execution from the database in subsequent transactions. After starting + the new process execution, it will wait in node 'one' cause the behaviour is a + wait state. + </para> + <programlisting>environment = environmentFactory.openEnvironment(); +try { + PvmDbSession pvmDbSession = environment.get(PvmDbSession.class); + + ProcessDefinition processDefinition = pvmDbSession.findProcessDefinition("persisted process"); + assertNotNull(processDefinition); + + Execution execution = processDefinition.startExecution("first"); + assertEquals("one", execution.getNode().getName()); + pvmDbSession.save(execution); + +} finally { + environment.close(); +}</programlisting> + <para>In the previous transaction, a new execution record will be inserted into + the database. + </para> + <para>Next we feed in an external trigger into this existing process execution. + We load the execution, provide a signal and just save it back into the database. + </para> + <programlisting>environment = environmentFactory.openEnvironment(); +try { + PvmDbSession pvmDbSession = environment.get(PvmDbSession.class); + + Execution execution = pvmDbSession.findExecution("persisted process", "first"); + assertNotNull(execution); + assertEquals("one", execution.getNode().getName()); + + // external trigger that will cause the execution to execute until + // it reaches the next wait state + execution.signal(); + + assertEquals("two", execution.getNode().getName()); + + pvmDbSession.save(execution); + +} finally { + environment.close(); +}</programlisting> + <para>The previous transaction will result in an update of the existing + execution, reassigning the foreign key to reference another record in + the node table. + </para> + <programlisting>UPDATE JBPM_EXECUTION +SET + NODE_=?, + DBVERSION_=?, + ... +WHERE DBID_=? + AND DBVERSION_=?</programlisting> + <para>The version in this SQL shows the automatic optimistic locking that + is baked into the PVM persistence so that process persistence can easily + scale to multiple JVM's or multiple machines. + </para> + <para>In the example code, there is one more transaction that is + completely similar to the previous which takes the execution from + node 'two' to node 'three'. + </para> + <para>All of this shows that the PVM can move from one wait state to + another wait state transactionally. Each transaction correcponds to + a state transition. + </para> + <para>Note that in case of automatic activities, multiple activities + will be executed before the execution reaches a wait state. Typically + that is desired behaviour. In case the automatic activities take too + long or you don't want to block the original transaction to wait for + the completion of those automatic activities, check out <xref linkend="asynchronouscontinuations"/> + to learn about how it's possible to demarcate transactions in the process + definition, which can also be seen as safe-points during process execution. + </para> + </section> + + <section id="businesskey"> + <title>Business key</title> + <para>TODO</para> + </section> + + + <para>TODO: General persistence architecture + </para> + <para>TODO: Object references + </para> + <para>TODO: Threads, concurrency with respect to forks and joins + </para> + <para>TODO: Caching + </para> + <para>TODO: Process instance migration + </para> +</chapter> \ No newline at end of file Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-Persistence.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-ProcessLanguages.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-ProcessLanguages.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-ProcessLanguages.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,19 @@ +<chapter id="processlanguages"> + <title>Process languages</title> + + <para>TODO: xml parser infrastructure + </para> + <para>TODO: inherit from ProcessDefinitionImpl, ExecutionImpl + </para> + <para>TODO: overriding the default proceed() + </para> + <para>TODO: node type implementations + </para> + <para>TODO: persistence + </para> + <para>TODO: compensation: languages like bpel and bpnm define that + as a normal contination that fits within the process + structures available in the pvm (taking a transition and + executing a nested node). + </para> +</chapter> \ No newline at end of file Property changes on: jbpm4/trunk/modules/manual/src/main/docbook/en/modules/chxx-ProcessLanguages.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/tutorial/docbook.properties =================================================================== --- jbpm4/trunk/modules/manual/src/main/tutorial/docbook.properties (rev 0) +++ jbpm4/trunk/modules/manual/src/main/tutorial/docbook.properties 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,3 @@ +lang = en +pdf.name = pvm-tutorial.pdf +build.dir = target/doc/tutorial Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/composite.decision.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/composite.decision.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.attach.src.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.attach.src.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.ex01.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.ex01.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.new.project.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.new.project.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.remove.src.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.remove.src.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.select.project.dir.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.select.project.dir.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.unzipped.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.unzipped.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.workspace.dir.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/eclipse.workspace.dir.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/ex01.basic.process.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/ex01.basic.process.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/pvm.unzipped.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/pvm.unzipped.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/sequence.2.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/sequence.2.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/sequence.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/sequence.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/tasks.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/tasks.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/transition.decision.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/images/transition.decision.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/master.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/tutorial/en/master.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/tutorial/en/master.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,27 @@ +<?xml version="1.0" encoding="UTF-8"?> + +<!DOCTYPE book [ + <!ENTITY ch01-GettingStarted SYSTEM "modules/ch01-GettingStarted.xml"> + <!ENTITY ch02-BasicProcessExecution SYSTEM "modules/ch02-BasicProcessExecution.xml"> + <!ENTITY ch03-BasicProcessPersistence SYSTEM "modules/ch03-BasicProcessPersistence.xml"> + + <!ENTITY ExamplesToIncorporate SYSTEM "modules/ExamplesToIncorporate.xml"> +]> + +<book lang="en"> + + <bookinfo> + <title>The Process Virtual Machine: Tutorial</title> + <subtitle>A library for building executable state machines. It can can + serve as the foundation for any form of BPM, workflow and orchestration. + </subtitle> + </bookinfo> + + <toc /> + + &ch01-GettingStarted; + &ch02-BasicProcessExecution; + &ch03-BasicProcessPersistence; + + &ExamplesToIncorporate; +</book> \ No newline at end of file Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/master.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ExamplesToIncorporate.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ExamplesToIncorporate.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ExamplesToIncorporate.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,470 @@ +<chapter> + <title>These examples need to be incorporated</title> + + <!-- ### GRAPH BASED CONTROL FLOW ACTIVITIES ############################ --> + <section id="graphbasedcontrolflowactivities"> + <title>Graph based control flow activities</title> + + <!-- ### AUTOMATIC DECISION ########################################### --> + <section id="automaticdecision"> + <title>Automatic decision</title> + <para>This example shows how to implement automatic conditional branching. This is mostly called + a decision or an or-split. It selects one path of execution from many alternatives. A decision node + should have multiple outgoing transitions. + </para> + <para>In a decision, information is collected from somewhere. Usually that is the process + variables. But it can also collect information from a database, a file, any other + form of input or a combination of these. In this example, a variable <literal>creditRate</literal> + is used. It contains an integer. The higher the integer, the better the credit rating. + Let's look at the example implementation: + </para> + <para>Then based on the obtained information, in our case that is the <literal>creditRate</literal>, + an outgoing transition has to be selected. + In the example, transition <literal>good</literal> will be selected when the creditRate is + above 5, transition <literal>bad</literal> will be selected when creditRate is below -5 + and otherwise transition <literal>average</literal> will be selected. + </para> + <para>Once the selection is done, the transition is taken with + <literal>execution.take(String)</literal> or + the <literal>execution.take(Transition)</literal> method. + </para> + <programlisting>public class AutomaticCreditRating implements Activity { + public void execute(Execution execution) { + <emphasis role="bold">int creditRate = (Integer) execution.getVariable("creditRate"); + + if (creditRate &gt; 5) { + execution.take("good"); + + } else if (creditRate &lt; -5) { + execution.take("bad"); + + } else { + execution.take("average"); + }</emphasis> + } + }</programlisting> + <para>We'll demonstrate the <literal>AutomaticCreditRating</literal> in the following + process:</para> + <figure id="example.process.automatic.credit.rating"> + <title>The decision process</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/transition.decision.png"/></imageobject></mediaobject> + </figure> + <programlisting>ProcessDefinition processDefinition = ProcessFactory.build() + .node("initial").initial().behaviour(new WaitState()) + .transition().to("creditRate?") + <emphasis role="bold">.node("creditRate?").behaviour(new AutomaticCreditRating()) + .transition("good").to("a") + .transition("average").to("b") + .transition("bad").to("c")</emphasis> + .node("a").behaviour(new WaitState()) + .node("b").behaviour(new WaitState()) + .node("c").behaviour(new WaitState()) +.done();</programlisting> + <para>Executing this process goes like this: + </para> + <programlisting>Execution execution = processDefinition.startExecution();</programlisting> + <para><literal>startExecution()</literal> will bring the execution into the <literal>initial</literal> + node. That's a wait state so the execution will point to that node when the + <literal>startExecution()</literal> returns. + </para> + <para>Then we have a chance to set the <literal>creditRate</literal> to a specific + value like e.g. 13.</para> + <programlisting>execution.setVariable("creditRate", 13);</programlisting> + <para>Next, we provide a signal so that the execution takes the default + transition to the <literal>creditRate?</literal> node. Since process variable + <literal>creditRate</literal> is set to 13, the <literal>AutomaticCreditRating</literal> + activity will take transition <literal>good</literal> to node <literal>a</literal>. + Node <literal>a</literal> is a wait state so them the invocation of <literal>signal</literal> + will return. + </para> + <para>Similarly, a decision can be implemented making use of the + transition's guard condition. For each outgoing transition, the guard condition + expression can be evaluated. The first transition for which its guard condition + evaluates to true is taken. + </para> + <para>This example showed automatic conditional branching. Meaning that all + information is available when the execution arrives in the decision node, even + if it may have to be collected from different sources. In the next example, + we show how a decision is implemented for which an external entity needs to + supply the information, which results into a wait state. + </para> + </section> + + <!-- ### EXTERNAL DECISION ############################################ --> + <section id="externaldecision"> + <title>External decision</title> + <para>This example shows an activity that again selects one path of execution + out of many alternatives. But this time, the information on which the decision + is based is not yet available when the execution arrives at the decision. + In other words, the execution will have to wait in the decision until the + information is provided from externally. + </para> + <programlisting>public class <emphasis role="bold">ExternalSelection</emphasis> implements ExternalActivity { + + public void execute(Execution execution) { + <emphasis role="bold">execution.waitForSignal();</emphasis> + } + + public void signal(Execution execution, String signalName, Map&lt;String, Object&gt; parameters) throws Exception { + <emphasis role="bold">execution.take(signalName);</emphasis> + } + + public Set&lt;SignalDefinition&gt; getSignals(Execution execution) throws Exception { + return null; + } +}</programlisting> + <para>The diagram for this external decision will be the same as for the + automatic decision: + </para> + <figure id="example.process.external.decision"> + <title>A decision</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/transition.decision.png"/></imageobject></mediaobject> + </figure> + <programlisting>ProcessDefinition processDefinition = ProcessFactory.build() + .node("initial").initial().behaviour(new WaitState()) + .transition().to("creditRate?") + <emphasis role="bold">.node("creditRate?").behaviour(new ExternalSelection()) + .transition("good").to("a") + .transition("average").to("b") + .transition("bad").to("c")</emphasis> + .node("a").behaviour(new WaitState()) + .node("b").behaviour(new WaitState()) + .node("c").behaviour(new WaitState()) +.done();</programlisting> + <para>The execution starts the same as in the automatic example. After starting + a new execution, it will be pointing to the initial wait state. + </para> + <programlisting>Execution execution = processDefinition.startExecution();</programlisting> + <para>But the next signal will cause the execution to take the default + transition out of the <literal>initial</literal> node and arrive in the + <literal>creditRate?</literal> node. Then the <literal>ExternalSelection</literal> + is executed, which will result into a wait state. So when the invocation + of <literal>signal()</literal> returns, the execution will be pointing to the + <literal>creditRate?</literal> node and it expects an external trigger. + </para> + <para>Next we'll give an external trigger with <literal>good</literal> as + the signalName. So supplying the external trigger is done together with + feeding the information needed by the decision. + </para> + <programlisting>execution.signal("good");</programlisting> + <para>That external trigger will be translated by the <literal>ExternalSelection</literal> + activity into taking the transition with name <literal>good</literal>. That way + the execution will have arrived in node <literal>a</literal> when + <literal>signal("good")</literal> returns. + </para> + <para>Note that both parameters <literal>signalName</literal> and <literal>parameters</literal> + can be used by external activities as they want. In the example here, we used the + signalName to specify the result. But another variation might expect an integer value + under the <literal>creditRate</literal> key of the parameters. + </para> + <para>But leveraging the execution API like that is not done very often in practice. + The reason is that for most external functions, typically activity instances are + created. Think about <literal>Task</literal> as an instance of a + <literal>TaskActivity</literal> (see later) or analogue, a <literal>ServiceInvocation</literal> + could be imagined as an instance of a <literal>ServiceInvocationActivity</literal>. + In those cases, those activity instances make the link between the external + activity and the execution. And these instances also can make sure that an + execution is not signalled inappropriately. Inappropriate signalling could happen + when for instance a service response message would arrive twice. If in such a + scenario, the message receiver would just signal the execution, it would not + notice that the second time, the execution is not positioned in the service invocation + node any more. + </para> + </section> + </section> + + <!-- ### COMPOSITE BASED CONTROL FLOW ACTIVITIES ######################## --> + <section id="compositebasedcontrolflowactivities"> + <title>Composite based control flow activities</title> + + <!-- ### COMPOSITE SEQUENCE ############################################# --> + <section> + <title>Composite sequence</title> + <para>Block structured languages like BPEL are completely based on composite nodes. Such + languages don't have transitions. The composite node structure of the Process Virtual Machine + allows to build a process with a structure that exactly matches the block structured + languages. There is no need for a conversion to a transition based model. We have + already discussed some examples of composite nodes. The following example + will show howw to implement a sequence, one of the most common composite + node types. + </para> + <para>A sequence has a list of nested activities that need to be executed + in sequence. + </para> + <para>This is how a sequence can be implemented: + </para> + <programlisting>public class Sequence implements ExternalActivity { + + public void <emphasis role="bold">execute</emphasis>(Execution execution) { + List&lt;Node&gt; nodes = execution.getNode().getNodes(); + execution.execute(nodes.get(0)); + } + + public void <emphasis role="bold">signal</emphasis>(Execution execution, String signal, Map&lt;String, Object&gt; parameters) { + Node previous = execution.getPreviousNode(); + List&lt;Node&gt; nodes = execution.getNode().getNodes(); + int previousIndex = nodes.indexOf(previous); + int nextIndex = previousIndex+1; + if (nextIndex &lt; nodes.size()) { + Node next = nodes.get(nextIndex); + execution.execute(next); + } else { + execution.proceed(); + } + } + + public Set&lt;SignalDefinition&gt; getSignals(Execution execution) { + return null; + } +}</programlisting> + <para>When an execution arrives in this sequence, the <emphasis role="bold">execute</emphasis> + method will execute the first node in the list of child nodes (aka composite nodes or + nested nodes). The sequence assumes that + the child node's behaviour doesn't have outgoing transitions and will end with + an <literal>execution.proceed()</literal>. That proceed will cause the execution + to be propagated back to the parent (the sequence) with a signal. + </para> + <para>The <emphasis role="bold">signal</emphasis> method will look up the previous + node from the execution, determine its index in the list of child nodes and increments + it. If there is a next node in the list it is executed. If the previous node was the + last one in the list, the proceed is called, which will propagate the execution to + the parent of the sequence in case there are no outgoing transitions. + </para> + <para>To optimize persistence of executions, the previous node of an execution is + normally not maintained and will be to null. If a node requires the previous + node or the previous transition like in this Sequence, the property + <literal>isPreviousNeeded</literal> must be set on the node. + </para> + <para>Let's look at how that translates to a process and an execution:</para> + <figure id="sequence"> + <title>A sequence.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/sequence.png"/></imageobject></mediaobject> + </figure> + <programlisting>ProcessDefinition processDefinition = ProcessFactory.build("sequence") + <emphasis role="bold">.compositeNode("sequence").initial().behaviour(new Sequence()) + .needsPrevious()</emphasis> + .node("one").behaviour(new Display("one")) + .node("wait").behaviour(new WaitState()) + .node("two").behaviour(new Display("two")) + .compositeEnd() +.done();</programlisting> + <para>The three numbered nodes will now be executed in sequence. Nodes <literal>1</literal> + and <literal>2</literal> are automatic <literal>Display</literal> activities, while + node <literal>wait</literal> is a wait state. + </para> + <programlisting>Execution execution = processDefinition.startExecution();</programlisting> + <para>The <literal>startExecution</literal> will execute the <literal>Sequence</literal> + activity. The <literal>execute</literal> method of the sequence will immediately execute + node 1, which will print message <literal>one</literal> on the console. Then the + execution is automatically proceeded back to the sequence. The sequence will have + access to the previous node. It will look up the index and execute the next. + That will bring the execution to node <literal>wait</literal>, which is a wait state. + At that point, the <literal>startExecution()</literal> will return. + A new external trigger is needed to complete the wait state. + </para> + <programlisting>execution.signal();</programlisting> + <para>That signal will delegate to the <literal>WaitState</literal>'s signal method. + That method is empty so the execution will <link linkend="defaultproceedbehaviour">proceed + in a default way</link>. Since there are no outgoing transitions, the execution will + be propagated back to the sequence node, which will be signalled. Then node + <literal>2</literal> is executed. When the execution comes back into the sequence + it will detect that the previously executed node was the last child node, + therefore, no propagation method will be invoked, causing the default proceed + to end the execution. The console will show: + </para> + <programlisting>one +two</programlisting> + </section> + + <!-- ### COMPOSITE DECISION ############################################# --> + <section id="compositedecision"> + <title>Composite decision</title> + <para>In a composite model, the node behaviour can use the + <literal>execution.execute(Node)</literal> method to execute one of the child nodes. + </para> + <figure id="composite.decision"> + <title>A decision based on node composition</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/composite.decision.png"/></imageobject></mediaobject> + </figure> + <programlisting>ProcessDefinition processDefinition = ProcessFactory.build() + <emphasis role="bold">.compositeNode("creditRate?").initial().behaviour(new CompositeCreditRating()) + .node("good").behaviour(new ExternalSelection()) + .node("average").behaviour(new ExternalSelection()) + .node("bad").behaviour(new ExternalSelection()) + .compositeEnd()</emphasis> +.done();</programlisting> + <para>The <literal>CompositeCreditRating</literal> is an automatic decision, implemented like this:</para> + <programlisting>public class <emphasis role="bold">CompositeCreditRating</emphasis> implements Activity { + + public void execute(Execution execution) { + int creditRate = (Integer) execution.getVariable("creditRate"); + + if (creditRate &gt; 5) { + execution.execute("good"); + + } else if (creditRate &lt; -5) { + execution.execute("bad"); + + } else { + execution.execute("average"); + } + } +}</programlisting> + <para>So when we start a new execution with</para> + <programlisting>Map&lt;String, Object&gt; variables = new HashMap&lt;String, Object&gt;(); +variables.put("creditRate", 13); +Execution execution = processDefinition.startExecution(variables); +</programlisting> + <para>The execution will execute the <literal>CompositeCreditRating</literal>. The + <literal>CompositeCreditRating</literal> will execute node <literal>good</literal> + cause the process variable <literal>creditRate</literal> is 13. When the + <literal>startExecution()</literal> returns, the execution will be positioned in + the good state. The other scenarios are very similar. + </para> + </section> + </section> + + <!-- ### HUMAN TASKS #################################################### --> + <section> + <title>Human tasks</title> + <para>This section will demonstrate how support for human tasks can be build on top + of the Process Virtual Machine. + </para> + <para>As we indicated in <xref linkend="executionandthreads" />, for each step in the process + the most important characteristic is whether responsibility for an activity lies within the + process system or outside. In case of a human task, it should be clear that the responsibility + is outside of the process system. This means that for the process, a human task is a wait state. + The execution will have to wait until the person provides the external trigger that the task + is completed or submitted. + </para> + <figure id="tasks"> + <title>Overview of the link between processes and tasks.</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/tasks.png"/></imageobject></mediaobject> + </figure> + <para>In the picture above, the typical link between process execution and tasks is + represented. When an execution arrives in a task node, a task is created in a task component. + Typically such a task will end up in a task table somewhere in the task component's + database. Then users can look at their task lists. A task list is then a filter on + the complete task list based on the task's assigned user column. When the user completes + the task, the execution is signalled and typically leaves the node in the process. + </para> + <para>A task management component keeps track of tasks for people. To integrate human tasks + into a process, we need an API to create new tasks and to get notifications of task + completions. The following example might have only a rudimentary integration between + between process execution and the task management component, but the goal is to show + the interactions as clearly as possible. Real process languages like jPDL have a + much better integration between process execution and tasks, resulting in more complexity. + </para> + <para>For this example we'll first define a simplest task component with classes + <literal>Task</literal> and <literal>TaskComponent</literal>: + </para> + <programlisting>public class <emphasis role="bold">Task</emphasis> { + public String userId; + public String taskName; + public Execution execution; + + public Task(String userId, String taskName, Execution execution) { + this.userId = userId; + this.taskName = taskName; + this.execution = execution; + } + + public void <emphasis role="bold">complete</emphasis>() { + execution.signal(); + } +}</programlisting> + <para>This task has public fields to avoid the getters and setters. The taskName property + is the short description of the task. The userId is a reference to the user that is + assigned to this task. And the execution is a reference to the execution to which this + task relates. When a task completes it signals the execution. + </para> + <para>The next task component manages a set of tasks. + </para> + <programlisting>public class TaskComponent { + + static List&lt;Task&gt; tasks = new ArrayList&lt;Task&gt;(); + + public static void createTask(String taskName, Execution execution) { + String userId = assign(taskName, execution); + tasks.add(new Task(userId, taskName, execution)); + } + + private static String assign(String taskName, Execution execution) { + return "johndoe"; + } + + public static List&lt;Task&gt; getTaskList(String userId) { + List&lt;Task&gt; taskList = new ArrayList&lt;Task&gt;(); + for (Task task : tasks) { + if (task.userId.equals(userId)) { + taskList.add(task); + } + } + return taskList; + } +}</programlisting> + <para>To keep this example short, this task component is to be accessed through + static methods. The assigning tasks is done hard coded to "johndoe". Tasks + can be created and tasklists can be extracted by userId. Next we can look at + the node behaviour implementation of a TaskActivity. + </para> + <programlisting>public class <emphasis role="bold">TaskActivity</emphasis> implements ExternalActivity { + + public void <emphasis role="bold">execute</emphasis>(Execution execution) { + // let's use the node name as the task id + String taskName = execution.getNode().getName(); + TaskComponent.createTask(taskName, execution); + } + + public void <emphasis role="bold">signal</emphasis>(Execution execution, String signal, Map&lt;String, Object&gt; parameters) { + execution.takeDefaultTransition(); + } + + public Set&lt;SignalDefinition&gt; getSignals(Execution execution) { + return null; + } +}</programlisting> + <para>The task node works as follows. When an execution arrives in a task node, + the execute method of the TaskActivity is invoked. The execute method will then + take the node name and use it as the task name. Alternatively, 'taskName' could + be a configuration property on the TaskActivity class. The task name is then used + to create a task in the task component. Once the task is created, the execution + is not propagated which means that the execution will wait in this node till + a signal comes in. + </para> + <para>When the task is completed with the Task.complete() method, it will + signal the execution. The TaskActivity's signal implementation will take + the default transition. + </para> + <para>This is how a process can be build with a task node: + </para> + <programlisting>ProcessDefinition processDefinition = ProcessFactory.build("task") + .node("initial").initial().behaviour(new AutomaticActivity()) + .transition().to("shred evidence") + .<emphasis role="bold">node("shred evidence").behaviour(new TaskActivity())</emphasis> + .transition().to("next") + .node("next").behaviour(new WaitState()) +.done();</programlisting> + <para>When a new execution is started, the initial node is an automatic activity. + So it will immediately propagate to the task node the task will be created and + the execution will stop in the 'shred evidence' node. + </para> + <programlisting>Execution execution = processDefinition.startExecution(); + +assertEquals("shred evidence", execution.getNode().getName()); + +Task task = TaskComponent.getTaskList("johndoe").get(0);</programlisting> + <para>Next, time can elapse until the human user is ready to complete the task. + In other words, the thread of control is now with 'johndoe'. When John + completes his task e.g. through a web UI, then this should result into an + invocation of the complete method on the task. + </para> + <programlisting>task.complete(); + +assertEquals("next", execution.getNode().getName());</programlisting> + <para>The invocation of the complete method cause the execution to take the + default transition to the 'next' node. + </para> + </section> + +</chapter> Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ExamplesToIncorporate.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ch01-GettingStarted.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ch01-GettingStarted.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ch01-GettingStarted.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,137 @@ +<chapter id="gettingstarted"> + <title>Getting started</title> + + <para>This tutorial is the best way to get started with the Process + Virtual Machine. It walks you through the examples that + come with the pvm download. In this section, we'll guide you through the + download and installation process. + </para> + + <section> + <title>Prerequisites</title> + <para><ulink url="http://java.sun.com/javase/downloads/index.jsp">JDK 5+</ulink> + </para> + </section> + + <section> + <title>Download PVM</title> + <para><ulink url="http://www.jboss.org/jbossjbpm/pvm_downloads/">Download the PVM</ulink> + </para> + </section> + + <section> + <title>Install PVM</title> + <para>The PVM comes as a zip file. Unzip it to a directory of your choice to + install it. Voila, you're all set. Following directories and files are + now on your system: + </para> + <figure id="pvm.unzipped"> + <title>Eclipse unzipped</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/pvm.unzipped.png"/></imageobject></mediaobject> + </figure> + <itemizedlist> + <listitem><literal><emphasis role="bold">jbpm-pvm-x.x/jbpm-pvm.jar</emphasis></literal>: the + jBPM PVM java archive library.</listitem> + <listitem><literal><emphasis role="bold">jbpm-pvm-x.x/release.notes.html</emphasis></literal>: the + release notes describing what changed relative to the previous release.</listitem> + <listitem><literal><emphasis role="bold">jbpm-pvm-x.x/doc/tutorial/index.html</emphasis></literal>: + this tutorial</listitem> + <listitem><literal><emphasis role="bold">jbpm-pvm-x.x/doc/reference/index.html</emphasis></literal>: + the reference manual</listitem> + <listitem><literal><emphasis role="bold">jbpm-pvm-x.x/doc/api/index.html</emphasis></literal>: + the javadocs of the PVM interface classes</listitem> + <listitem><literal><emphasis role="bold">jbpm-pvm-x.x/doc/wirexsd/index.html</emphasis></literal>: + the documentation of the wire XML schema used for configuring the PVM in + transactional and persistent environments</listitem> + <listitem><literal><emphasis role="bold">jbpm-pvm-x.x/doc/tutorial/index.html</emphasis></literal>: this</listitem> + <listitem><literal><emphasis role="bold">jbpm-pvm-x.x/lib</emphasis></literal>: contains all the + third party libraries on which the PVM might have a dependency. The idea is that + a library only needs to be on the classpath in case the related functionality + is actually used.</listitem> + </itemizedlist> + </section> + + <section> + <title>Library dependencies</title> + <para>For building and executing processes the jbpm-pvm.jar does not have any other + dependencies then on the JVM. If you're using DB persistence, then there is a dependency + on hibernate and it's dependencies. More information about the optional depedencies can + be found in <ulink url="../../../../lib/optional-dependencies.html">file optional.dependencies.html + in the lib directory</ulink>. + </para> + </section> + + <section> + <title>Set up eclipse</title> + <para>You can use and IDE, but we'll be giving the detailed setup for eclipse + here, version eclipse-java-europa-winter-win32.zip. + </para> + <para>Go to the <ulink url="http://www.eclipse.org/downloads/">downloads section at the + eclipse website.</ulink> Select "Eclipse IDE for Java Developers" for your platform. + Download and unzip to any directory on your file system. We'll be using + <literal>c:\eclipse</literal> + </para> + <figure id="eclipse.unzipped"> + <title>Eclipse unzipped</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/eclipse.unzipped.png"/></imageobject></mediaobject> + </figure> + <para>Start <literal>eclipse.exe</literal> in <literal>c:\eclipse</literal>. When + prompted for the workspace, select <literal>c:\workspace</literal> and tick the + checkbox so that you're not asked again.</para> + <figure id="eclipse.workspace.dir"> + <title>Eclipse workpace dir</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/eclipse.workspace.dir.png"/></imageobject></mediaobject> + </figure> + <para>Then eclipse opens and you can close the welcome screen. Now you're ready to start + creating the pvm project in your workspace. + </para> + </section> + + <section> + <title>Create the pvm eclipse project</title> + <para>In eclipse, select File --&gt; New --&gt; Java Project like this</para> + <figure id="eclipse.new.project"> + <title>Eclipse new Java Project</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/eclipse.new.project.png"/></imageobject></mediaobject> + </figure> + <para>In the New Java Project dialog, enter <literal>pvm</literal> as the project + name, select "Create new project from existing source" + </para> + <para>In the "Browse For Folder" dialog, select the <literal>c:\jbpm-pvm-1.x</literal> + directory and click OK. + </para> + <figure id="eclipse.select.project.dir"> + <title>Select project directory</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/eclipse.select.project.dir.png"/></imageobject></mediaobject> + </figure> + <para>Click <emphasis role="bold">"Next &gt;"</emphasis>.</para> + <para>In the Source tab, select the <literal>src</literal> directory in + pvm and click the button "Remove from Build Path", which is indicated with the + red circle in the following snapshot.</para> + <figure id="eclipse.remove.src"> + <title>Remove src from Build Path</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/eclipse.remove.src.png"/></imageobject></mediaobject> + </figure> + <para>Next, we'll attach the sources of the pvm to the pvm library. In the + 'Libraries' tab, open the jbpm-pvm.jar, select 'Source attachment' and + click Edit. In the dialog, select 'Workspace' and then select /pvm/src. + </para> + <figure id="eclipse.attach.src"> + <title>Attach pvm sources to library</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/eclipse.attach.src.png"/></imageobject></mediaobject> + </figure> + <para>Then click 'OK' in the two open dialogs and click 'Finish' in the + 'New Java Project' dialog and you have the pvm project in eclipse all set up. + </para> + <para>Next, you can open the examples like e.g. <literal>org.jbpm.pvm.ex01.BasicProcessExecutionTest</literal> + </para> + <figure id="eclipse.ex01"> + <title>Running the first example</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/eclipse.ex01.png"/></imageobject></mediaobject> + </figure> + <para>The example tests can be executed with 'Run --&gt; Run As --&gt; JUnit Test' or with + 'Run --&gt; Debug As --&gt; JUnit Test'. + </para> + </section> + +</chapter> Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ch01-GettingStarted.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ch02-BasicProcessExecution.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ch02-BasicProcessExecution.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ch02-BasicProcessExecution.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,115 @@ +<chapter id="basicprocessexecution"> + <title>Basic Process Execution</title> + + <para>In it's most basic usage, the Process Virtual Machine is a framework for + implementing state machines. It separates the structure of a process + from the runtime behaviour. The nodes, transitions and composite nodes + form the structure. Activities implement the runtime behaviour and are + associated to each of the nodes. + </para> + + <para>Let's look at the first example. A simple process with 5 consequetive + nodes. We'll use two node types. An automatic activity and a wait state. + The automatic activity is implemented like this: + </para> + + <programlisting>public class AutomaticActivity implements Activity { + + public void execute(Execution execution) { + } +}</programlisting> + + <para>This activity implements the behaviour of a node. The default behaviour is to + proceed over the default outgoing transition. So the empty <literal>execute</literal> + means that the default outgoing transition is taken immediately when an execution arrives + in this node. + </para> + + <para>Implementing a wait state involves an extra method. An invocation of + <literal>execution.waitForSignal()</literal> will cause the execution to stop + and wait in the node until an external trigger is provided into the execution. + So an extra <literal>signal</literal> method needs to be provided that implements + what needs to be done when the external trigger comes in. + </para> + + <programlisting>public class WaitState implements ExternalActivity { + + public void execute(Execution execution) { + execution.waitForSignal(); + } + + public void signal(Execution execution, + String signalName, + Map&lt;String, Object&gt; parameters) { + } +}</programlisting> + + <para>When an execution arrives in a wait state, the <literal>waitForSignal</literal> + invocation cause the execution to halt in that node. The signal method is called + after an external trigger is received. Again here, <literal>execution.take(String transitionName)</literal> + does not have to be called explicitely as the default outgoing transition is taken + in case no other execution propagation methods are invoked. + </para> + + <para>Note that ExternalActivity refers to the thread of control that goes external + to the process system. Each time when an external entity (e.g. think a + human task or a web service callback) is responsible for the continuation of the + process, the process node will behave as a wait state. + </para> + + <programlisting>38| ProcessDefinition processDefinition = ProcessFactory.build() +39| .<emphasis role="bold">node("a").initial()</emphasis>.behaviour(<emphasis role="bold">WaitState.class</emphasis>) +40| .transition().to("b") +41| .<emphasis role="bold">node("b")</emphasis>.behaviour(<emphasis role="bold">WaitState.class</emphasis>) +42| .transition().to("c") +43| .<emphasis role="bold">node("c")</emphasis>.behaviour(<emphasis role="bold">AutomaticActivity.class</emphasis>) +44| .transition().to("d") +45| .<emphasis role="bold">node("d")</emphasis>.behaviour(<emphasis role="bold">AutomaticActivity.class</emphasis>) +46| .transition().to("e") +47| .<emphasis role="bold">node("e")</emphasis>.behaviour(<emphasis role="bold">WaitState.class</emphasis>) +48| .done(); +49| +50| Execution execution = processDefinition.startExecution(); +51| +52| assertEquals("a", execution.getNode().getName()); +53| +54| execution.signal(); +55| +56| assertEquals("b", execution.getNode().getName()); +57| +58| execution.signal(); +59| +60| assertEquals("e", execution.getNode().getName());</programlisting> + + <para>In the first section (line 38-48), a <literal>processDefinition</literal> is created with the process + factory. The <literal>ProcessFactory</literal> is a fluent language to build a process definition. + All methods return the same process factory. So by concatenating method invocations a + full process definition object can be specified. The resulting process looks like this: + </para> + + <figure id="ex01.basic.process"> + <title>Basic process</title> + <mediaobject><imageobject><imagedata align="center" fileref="images/ex01.basic.process.png"/></imageobject></mediaobject> + </figure> + + <para>The second part shows how one execution is started and executed. After starting + a new execution (line 50), the initial node is executed. Since that is a wait state, the + newly created execution is positioned in node <literal>a</literal> (line 52) after the method + <literal>processDefinition.startExecution()</literal> returned. + </para> + + <para>A first external trigger (line 54) will take the process from node <literal>a</literal> + to node <literal>b</literal>. <literal>b</literal> is again a wait state. + </para> + + <para>The next two nodes <literal>c</literal> and <literal>d</literal> are automatic + activities. So during the <literal>signal</literal> method invocation in line 58 + the execution will move forward all the way to node <literal>e</literal> before it + returns.</para> + + <para>A first important consideration to make after this example is that process execution + is done in the thread of the client and this stops when the process execution reaches a + wait state. At that point, the PVM method invocation returns. + </para> + +</chapter> Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ch02-BasicProcessExecution.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ch03-BasicProcessPersistence.xml =================================================================== --- jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ch03-BasicProcessPersistence.xml (rev 0) +++ jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ch03-BasicProcessPersistence.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,11 @@ +<chapter id="basicprocesspersistence"> + <title>Basic Process Persistence</title> + + <para>In this section, the same simple process will be executed + in a persistent way. Therefor, the PvmService session facade interface + will be used instead of invoking methods on the objects directly. + </para> + <para>The PvmService can be obtained from an EnvironmentFactory. + </para> + +</chapter> Property changes on: jbpm4/trunk/modules/manual/src/main/tutorial/en/modules/ch03-BasicProcessPersistence.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/codehighlight.css =================================================================== --- jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/codehighlight.css (rev 0) +++ jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/codehighlight.css 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,242 @@ +span.property {color:#0066CC;} + +pre.JAVA {line-height:10px;} + +pre.XML {line-height:8px;} + +pre.JSP {line-height:8px;} + +pre.XHTML {line-height:8px;} + +.java_type {color:#000000;} + +.java_keyword { + font-weight:bold; + color:#7F1B55; +} + +.java_javadoc_comment { + color:#3F5FBF; + font-style:italic; + background-color:rgb(247,247,247); +} + +.java_comment { + color:#3F7F5F; + background-color:rgb(247,247,247); +} + +.java_operator {color:#000000;} + +.java_plain {color:rgb(0,0,0);} + +.java_literal {color:#2A00FF;} + +pre CODE { + font-size:12px; + color:rgb(0,0,0); + font-family:monospace; + white-space:nowrap; +} + +.java_javadoc_tag { + font-weight:bold; + color:#7F9FBF; + font-style:italic; + background-color:rgb(247,247,247); +} + +.java_separator {color:#000000;} + +.xml_plain {color:rgb(0,0,0);} + +.xml_tag_name {color:#3F7F7F;} + +.xml_comment { + color:#3F5FBF; + background-color:rgb(247,247,247); +} + +.xml_tag_symbols {color:#008080;} + +.xml_rife_tag { + color:rgb(0,0,0); + background-color:rgb(228,230,160); +} + +.xml_attribute_value {color:#2A00FF;} + +.xml_attribute_name { + font-weight:bold; + color:#7F007F; +} + +.xml_char_data {color:rgb(0,0,0);} + +.xml_rife_name { + color:#008cca; + background-color:rgb(228,230,160); +} + +.xml_processing_instruction { + font-weight:bold; + color:rgb(0,0,0); + font-style:italic; +} + +td.java { + vertical-align:top; + line-height:10px; +} + +td.java-ln { + vertical-align:top; + line-height:10px; +} + +tt.java { + margin-bottom:0em; + line-height:10px; + font-family:verdana,helvetica,sans-serif; +} + +tt.java-ln { + margin-bottom:0em; + line-height:10px; +} + +pre.java { + margin-bottom:0em; + line-height:10px; +} + +pre.java-ln { + margin-bottom:0em; + line-height:10px; +} + +td.java-ln { + line-height:10px; + text-align:right; +} + +tt.java-ln { + color:#888888; + line-height:10px; +} + +pre.java-ln { + color:#888888; + line-height:10px; +} + +span.java0 { + font-size:8pt; + color:#ffffff; + line-height:10px; +} + +span.java1 { + font-size:8pt; + color:#808080; +} + +span.java2 { + font-size:8pt; + color:#3f7f5f; + line-height:10px; +} + +/* Single-line comment */ + +span.java3 { + font-size:8pt; + color:#3f7f5f; + line-height:10px; +} + +/* Keywords excluding 'return' */ + +span.java4 { + font-weight:bold; + font-size:8pt; + color:#7F1B55; + line-height:10px; +} + +span.java5 { + font-size:8pt; + color:#2a00ff; + line-height:10px; +} + +span.java6 { + font-size:8pt; + color:#990000; + line-height:10px; +} + +span.java7 { + font-size:8pt; + color:#990000; + line-height:10px; +} + +span.java8 { + font-size:8pt; + color:#000000; + line-height:10px; +} + +/* Primitive types: long, int, void etc... */ + +span.java9 { + font-weight:bold; + font-size:8pt; + color:#7F0055; + line-height:10px; +} + +span.java10 { + font-size:8pt; + color:#000000; + line-height:10px; +} + +span.java11 { + font-size:8pt; + color:#7f9fbf; + line-height:10px; +} + +span.java12 { + font-size:8pt; + color:#7f7f9f; + line-height:10px; +} + +span.java13 { + font-size:8pt; + color:#3f3fbf; + line-height:10px; +} + +span.java14 { + font-size:8pt; + color:#3f5fbf; + line-height:10px; +} + +span.java15 { + font-size:8pt; + color:#7F0055; + line-height:10px; +} + +/* Annotations */ + +span.java16 { + font-size:8pt; + color:#646464; + line-height:10px; +} Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/docnav.css =================================================================== --- jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/docnav.css (rev 0) +++ jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/docnav.css 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,204 @@ +/* Document Navigation */ + +.docnav a, .docnav strong { + text-decoration:none; + font-weight:normal; +} + +.docnav { + list-style:none; + margin:0em; + padding:0em; + position:relative; + width:100%; + padding-bottom:2em; + padding-top:1em; + border-top:1px dotted #ccc; +} + +.docnav li { + list-style:none; + margin:0em; + padding:0em; + display:inline; + font-size:.8em; +} + +.docnav li:before {content:" ";} + +.docnav li.previous, .docnav li.next { + position:absolute; + top:1em; +} + +.docnav li.up, .docnav li.home {margin:0em 1.5em;} + +.docnav li.previous { + left:0px; + text-align:left; +} + +.docnav li.next { + right:0px; + text-align:right; +} + +.docnav li.previous strong, .docnav li.next strong { + display:block; + height:22px; +} + +.docnav { + margin:0 auto; + text-align:center; +} + +.docnav li.next a strong { + background:url(../images/community/docbook/next.png) top right no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-right:60px; + font-size:1.2em; +} + +.docnav li.previous a strong { + background:url(../images/community/docbook/prev.png) top left no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-left:60px; + font-size:1.2em; +} + +.docnav li.home a strong { + background:url(../images/community/docbook/home.png) top left no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-left:60px; + font-size:1.2em; +} + +.docnav li.up a strong { + background:url(../images/community/docbook/up.png) top left no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-left:60px; + font-size:1.2em; +} + +.docnav a:link, .docnav a:visited {color:#666 !important;} + +.docnav a:hover, .docnav a:focus, .docnav a:active {color:black !important;} + +.docnav a { + max-width:10em; + overflow:hidden; +} + +.docnav a:link strong {text-decoration:none;} + +.docnav { + margin:0 auto; + text-align:center; +} + +.docnav {margin-bottom:16px;} + +/* Eclipse Help Navigation */ + +.navheader {padding-top:35px} + +.navheader table {border-style:none} + +.navheader a { + text-decoration:none; + font-weight:normal; + font-size:.8em; +} + +.navheader td.next a { + background:url(../images/community/docbook/next.png) top right no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-right:60px; + font-size:0.9em; +} + +.navheader td.previous a { + background:url(../images/community/docbook/prev.png) top left no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-left:60px; + font-size:0.9em; +} + +.navheader a:link, .navheader a:visited {color:#666 !important;} + +.navheader a:hover, .navheader a:focus, .navheader a:active {color:black !important;} + +.navheader a { + max-width:10em; + overflow:hidden; +} + +.navheader a:link {text-decoration:none;} + +.navfooter table {border-style:none} + +.navfooter a { + text-decoration:none; + font-weight:normal; + font-size:.8em; +} + +.navfooter td.next a { + background:url(../images/community/docbook/next.png) top right no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-right:60px; + font-size:0.9em; +} + +.navfooter td.previous a { + background:url(../images/community/docbook/prev.png) top left no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-left:60px; + font-size:0.9em; +} + +.navfooter td.home a { + background:url(../images/community/docbook/home.png) top left no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-left:60px; + font-size:0.9em; +} + +.navfooter td.up a { + background:url(../images/community/docbook/up.png) top left no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-left:60px; + font-size:0.9em; +} + +.navfooter a:link, .navfooter a:visited {color:#666 !important;} + +.navfooter a:hover, .navfooter a:focus, .navfooter a:active {color:black !important;} + +.navfooter a { + max-width:10em; + overflow:hidden; +} + +.navfooter a:link {text-decoration:none;} Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/documentation.css =================================================================== --- jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/documentation.css (rev 0) +++ jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/documentation.css 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,551 @@ +/* Lists */ + +ol li, ul li { + padding-left:.2em; + padding-bottom:.5em; + margin:0em; +} + +ul { + padding-left:1.6em; + list-style-image:url(../images/community/dot.png); + list-style-type:circle; +} + +ul ul { + list-style-image:url(../images/community/dot2.png); + list-style-type:circle; +} + +dt { + font-weight:bold; + margin-bottom:0em; + padding-bottom:0em; +} + +dd { + margin:0em; + margin-left:2em; + padding-top:0em; +} + +li p:first-child, dd p:first-child { + padding:0em; + margin-top:.3em; +} + +.variablelist, .itemizedlist {margin-top:.6em;} + +ul li p:first-child {margin:0em;} + +/* Images */ + +img { + display:block; + margin:2em 0; +} + +.inlinemediaobject, .inlinemediaobject img { + display:inline !important; + margin:0em; +} + +.programlisting a img, pre a img, td a img, td img { + display:inline; + margin:0 0; +} + +/* Needed for Safari */ + +pre a span img, pre span img { + display:inline; + margin:0 0; +} + +span.co { + position:absolute; + left:900px +} + +/* Document modes */ + +.confidential { + background-color:#900; + color:white; + padding:.5em .5em; + font-family:serif; + text-transform:uppercase; + text-align:center +} + +dt a {font-weight:normal;} + +.longdesc-link {display:none;} + +.prompt { + background-color:#ede7c8; + padding:0em .3em; +} + +/* User interface styles */ + +.screen .replaceable {color:#444;} + +.screen { + background-color:#ede7c8; + color:#333; + padding:.5em 1em; + margin:0em; +} + +pre, code, .guibutton, .keycap, .guilabel { + font-size:0.9em; + font-family:verdana, helvetica, sans-serif; +} + +.guibutton, .keycap, .guilabel { + font-weight:bold; + white-space:nowrap; + color:#444; + font-family:'Lucida Grande', Geneva, Verdana, Arial, sans-serif; +} + +.guibutton, .guilabel {} + +.keycap {padding:.1em.4em;} + +.example { + background-color:#c8c5ac; + padding:5px; + margin-bottom:10px; +} + +/* Terminal/Console text */ + +.command, .computeroutput, .filename, .citetitle, .replaceable, .option {font-weight:bold;} + +.command .replaceable {color:#555;} + +pre { + display:block; + background-color:#f9f3b0; + color:#333; + overflow:auto; + padding:10px 10px; + line-height:1.2; +} + +code {white-space:nowrap;} + +/* Admonitions */ + +/* Set basic colors and spacing */ + +div.note { + background:#b5bcbd; + color:#4c5253; + border:1px solid #8a9195; + margin-bottom:1.5em; + background-repeat:no-repeat; + background-position:10px 10px; + padding:1em; + padding-bottom:20px; +} + +div.tip { + background:#7e917f; + color:white; + border:1px solid #8a9195; + margin-bottom:1.5em; + background-repeat:no-repeat; + background-position:10px 10px; + padding:1em; + padding-bottom:20px; +} + +div.important { + background:#4a5d75; + color:white; + border:1px solid #8a9195; + margin-bottom:1.5em; + background-repeat:no-repeat; + background-position:10px 10px; + padding:1em; + padding-bottom:20px; +} + +div.caution { + background:#e3a835; + color:#533500; + border:1px solid #ab710a; + margin-bottom:1.5em; + background-repeat:no-repeat; + background-position:10px 10px; + padding:1em; + padding-bottom:20px; +} + +div.warning { + background:#7b1e1e; + color:white; + border:1px solid #65504e; + margin-bottom:1.5em; + background-repeat:no-repeat; + background-position:10px 10px; + padding:1em; + padding-bottom:20px; +} + +/* Pre tag color settings */ + +div.note pre { + background-color:#d6dee0; + color:#334558; + border:1px solid #e1e9eb; +} + +div.tip pre { + background-color:#d5e1d5; + color:#334558; + border:1px solid #e1e9eb; +} + +div.important pre { + background-color:#e1eef4; + color:#334558; + border:1px solid #e1e9eb; +} + +div.caution pre { + background-color:#faf8ed; + color:#334558; + border:1px solid #e1e9eb; +} + +div.warning pre { + background-color:#faf8ed; + color:#334558; + border:1px solid #e1e9eb; +} + +/* Background images and margin */ + +div.note, div.tip, div.important, div.caution, div.warning {margin-top:.5em;} + +div.note {background-image:url(../images/community/docbook/note.png);} +div.tip {background-image:url(../images/community/docbook/tip.png);} +div.important {background-image:url(../images/community/docbook/important.png);} +div.caution {background-image:url(../images/community/docbook/caution.png);} +div.warning {background-image:url(../images/community/docbook/warning.png);} + +div.note .replaceable, div.tip .replaceable, div.important .replaceable, div.caution .replaceable, div.warning .replaceable {color:#e3dcc0;} + +pre .replaceable, tt .replaceable {color:#444 !important;} + +div.note h2, div.tip h2, div.important h2, div.caution h2, div.warning h2 { + height:32px; + font-size:1.3em; +} + +div.note h2 {color:#4c5253;} +div.tip h2 {color:white;} +div.important h2 {color:white;} +div.caution h2 {color:#533500;} +div.warning h2 {color:white;} + +div.note .guilabel, div.tip .guilabel, div.important .guilabel, div.caution .guilabel, div.warning .guilabel {color:white !important;} + +div.note li, div.tip li, div.caution li, div.warning li, div.important li { + padding-left:10px; + margin:0em; +} + +div.note ul, div.tip ul, div.caution ul, div.warning ul, div.important ul { + padding-left:40px; + margin:0em; +} + +div.note pre pre a:visited, div.tip pre pre a:visited, div.important pre pre a:visited, div.caution pre pre a:visited, div.warning pre pre a:visited, +div.note pre a:link, div.tip pre a:link, div.important pre a:link, div.caution pre a:link, div.warning pre a:link {color:#0066cc !important;} + +div.note a:visited, div.tip a:visited, div.important a:visited, div.warning a:visited, +div.note a:link, div.tip a:link, div.important a:link, div.warning a:link {color:#f7f2d0;} + +div.note a:visited, div.note a:link, div.caution a:link, div.caution a:visited {color:#0066cc;} + +/* Admonition icons spacing */ + +div.note h2, div.note p, div.tip h2, div.tip p, div.caution h2, div.caution p, div.warning h2, div.warning p, div.important h2, div.important p { + padding:0em; + margin:0em; + padding-left:56px; +} + +/* Page Title */ + +#title { + padding:0px; + margin:0px; +} + +#title strong {display:none;} + +#title a.site_href { + display:block; + height:89px; + width:310px; + float:left; +} + +#title a.doc_href { + display:block; + height:116px; + background:transparent url(../images/jbpm.png) top right no-repeat; +} + +/* Table */ + +table { + border:1px solid #aaa; + width:100%; + border-collapse:collapse; +} + +table th { + text-align:left; + background-color:#4A5D75; + padding:.3em .5em; + color:white; +} + +table td {padding:.15em .5em;} + +table tr.even td {background-color:#f5f5f5;} + +table th p:first-child, table td p:first-child, table li p:first-child { + margin-top:0em; + padding-top:0em; + display:inline; +} + +th, td {border-style:none;} + +table table td { + border-bottom:1px dotted #aaa !important; + background-color:white; + padding:.6em 0em; +} + +table table { + border:1px solid white !important; + font-size:.9em; +} + +td.remarkval { + font-size:.9em; + color:#444; +} + +.defaultval {font-size:.8em} + +td.typeval {font-size:.8em} + +td.fieldval { + font-weight:bold; + font-size:.9em; +} + +th.dbkey {font-size:.9em;} + +.lbname, .lbtype, .lbdescr, .lbdriver, .lbhost { + color:white; + font-weight:bold; + background-color:#999; + font-size:0.9em; + width:120px; +} + +td.remarkval {width:230px;} + +td.tname { + font-weight:bold; + font-size:1.1em; +} + +h5 {font-size:9pt;} +h6 {font-size:10pt;} + +th.dbfield {width:120px;} +th.dbtype {width:70px;} +th.dbdefault {width:70px;} +th.dbnul {width:70px;} +th.dbkey {width:70px;} + +span.book { + margin-top:4em; + display:block; +} + +span.chapter { + display:block; + margin-top:0.5em; +} + +/* Breadcrumbs */ + +#breadcrumbs ul li.first:before {content:" ";} + +#breadcrumbs { + color:#900; + padding:3px; + margin-bottom:25px; +} + +#breadcrumbs ul { + margin-left:0; + padding-left:0; + display:inline; + border:none; +} + +#breadcrumbs ul li { + margin-left:0; + padding-left:2px; + border:none; + list-style:none; + display:inline; +} + +#breadcrumbs ul li:before { + content:"\0020 \0020 \0020 \00BB \0020"; + color:#333; +} + +/* Status */ + +.alpha1 {background:white url(../images/community/watermark-alpha1.png) top left repeat;} +.alpha2 {background:white url(../images/community/watermark-alpha2.png) top left repeat;} +.beta1 {background:white url(../images/community/watermark-beta1.png) top left repeat;} +.beta2 {background:white url(../images/community/watermark-beta2.png) top left repeat;} +.pre-release-candidate {background:white url(../images/community/watermark-pre-release-candidate.png) top left repeat;} +.release-candidate {background:white url(../images/community/watermark-release-candidate.png) top left repeat;} + +/* Index */ + +.glossary h3, .index h3 { + font-size:2em; + color:#aaa; + margin:0em; +} + +.indexdiv {margin-bottom:1em;} + +.glossary dt, .index dt { + font-size:.9em; + color:#444; + padding-top:.5em; +} + +.glossary dl dl dt, .index dl dl dt { + font-size:.85em; + color:#777; + line-height:1.2em; + font-weight:normal; + padding-top:0em; +} + +.index dl dl dt:before { + content:"- "; + color:#ccc; +} + +/* Changes */ + +.footnotes {} + +.footnote { + padding:.2em 1em; + background-color:#c8c5ac; + font-size:.9em; + margin:0em; + margin-bottom:.5em; + color:#222; +} + +table .footnote {margin:1em .5em;} + +sup { + padding:0em .3em; + padding-left:0em; +} + +.footnote {position:relative;} + +.footnote sup { + color:#e3dcc0; + font-size:1.8em; + position:absolute; + left:.4em; +} + +.footnote sup a:link, .footnote sup a:visited { + color:#92917d; + text-decoration:none; +} + +.footnote:hover sup a { + color:#fff; + text-decoration:none; +} + +.footnote p {padding-left:5em;} + +.footnote a:link, .footnote a:visited {color:#00537c;} + +.footnote a:hover {color:white;} + +li p:first-child { + margin:0em !important; + padding:0em !important; +} + +div.chapter, div.section {padding-top:2em;} + +.revhistory {font-size:} + +pre .replaceable, pre .keycap {color:white;} + +pre { + font-family:courier new; + background-color:#F5F5F5; + border:1px solid #CCCCCC; + padding:5px 15px 5px 25px; +} + +div.note .replaceable, div.tip .replaceable, div.important .replaceable, div.caution .replaceable, div.warning .replaceable, +div.note .keycap, div.tip .keycap, div.important .keycap, div.caution .keycap, div.warning .keycap {color:white;} + +div.abstract {font-size:larger;} + +.authorgroup {} + +.authorgroup h4 { + padding:0em; + margin:0em; + margin-top:1em; +} + +.author, .editor, .translator, .othercredit {display:block;} + +/* Simpler author style on contents page */ + +.authorgroup div { + margin-left:10px; + margin-right:10px; + margin-bottom:15px; +} + +ul li p:last-child { + margin-bottom:0em; + padding-bottom:0em; +} Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/extensions.css =================================================================== --- jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/extensions.css (rev 0) +++ jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/extensions.css 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,7 @@ +/* Firefox */ + +pre {-moz-border-radius:11px;} + +.example {-moz-border-radius:15px;} + +div.note, div.tip, div.important, div.caution, div.warning {-moz-border-radius:11px;} Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/jbossorg.css =================================================================== --- jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/jbossorg.css (rev 0) +++ jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/jbossorg.css 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,80 @@ +@import url("documentation.css"); +@import url("docnav.css"); +@import url("reports.css"); +@import url("extensions.css"); +@import url("codehighlight.css"); + +body { + background-image:url(../images/bg.png); + background-repeat:repeat-x; + margin:0 auto; + font-family:'Lucida Grande', Geneva, Verdana, Arial, sans-serif; + font-size:12px; + max-width:55em; + padding:0em 2em; + color:#333; + line-height:150%; + text-align:justify; +} + +/* Links */ + +a:link {color:#0066cc;} + +a:visited {color:#6699cc;} + +div.longdesc-link { + float:right; + color:#999; +} + +/* Headings */ + +h1, h2, h3, h4, h5, h6 { + color:#4a5d75; + line-height:130%; + margin-top:0em; + font-family:'Lucida Grande', Geneva, Verdana, Arial, sans-serif; + background-color:transparent; +} + +h1 { + background-image:url(../images/community/title_hdr.png); + background-repeat:no-repeat; + border-top:1px dotted #CCCCCC; + line-height:1.2em; + color:#182737; + font-size:2em; + padding:1.5em; +} + +h2 {font-size:1.6em;} + +h3 { + font-size:1.3em; + padding-top:0em; + padding-bottom:0em; +} + +h4 { + font-size:1.1em; + padding-top:0em; + padding-bottom:0em; +} + +h5.formalpara { + font-size:1em; + margin-top:2em; + margin-bottom:.8em; +} + +/* Element rules */ + +hr { + border-collapse:collapse; + border-style:none; + border-top:1px dotted #ccc; + width:100% !important; +} + +sup {color:#999;} Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/reports.css =================================================================== --- jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/reports.css (rev 0) +++ jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/css/reports.css 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,231 @@ +/* Reports */ + +.reports ul.locale {list-style:none;} + +.reports ul { + padding:0em; + margin:0em; +} + +.reports ul.locale li { + font-size:small; + color:#000; + display:block; + border:1px solid #eee; + float:left; + padding-right:2em; + margin-right:1em; + margin-bottom:1em; +} + +.reports ul.locale li a { + font-size:1.2em; + display:block; + padding-top:.1em; + padding-bottom:.5em; +} + +.reports ul.locale strong { + display:block; + margin:0em; + padding:0em; + margin-bottom:-2.2em; +} + +.reports ul.locale span.value { + display:block; + position:relative; + text-align:right; + margin-right:-1.5em; + font-size:1.0em; + color:#444; +} + +.reports ul.locale li { + width:12em; + display:block; + float:left; + margin:0em; + clear:none; +} + +.reports ul.locale li div.progress { + font-size:1em; + width:13.2em; + position:relative; + left:0em; + top:0em; + margin-bottom:0em; +} + +.reports h2 { + font-size:1em; + margin:0em; +} + +.reports li {} + +.reports li:hover { + background-color:#666; + border-color:#444 !important; + color:white !important; +} + +.reports li:hover strong, .reports li:hover h2, .reports li:hover a, .reports li:hover span.value {color:white;} + +/* Uniform */ + +body.results, body.reports { + max-width:57em !important; + padding:0em !important; +} + +/* Progress Bar */ + +div.progress { + display:block; + float:left; + width:16em; + background:#c00 url(../images/community/shine.png) top left repeat-x; + height:1em; +} + +div.progress span { + height:1em; + float:left; +} + +div.progress span.translated {background:#6c3 url(../images/community/shine.png) top left repeat-x;} +div.progress span.fuzzy {background:#ff9f00 url(../images/community/shine.png) top left repeat-x;} + +/* Results */ + +.results ul.locale { + list-style:none; + padding:0em; + margin:0em; +} + +.results .pofile { + padding:0em !important; + margin:0em; +} + +.results ul.locale li { + border-top:1px solid #eee; + padding:0em; + margin:0em; + padding-left:32px; +} + +.results ul.locale .pofile { + font-size:1.2em; + display:block; + width:100%; + color:#444; + padding:0em; + margin:0em; +} + +.results span.value {color:#888;} + +.results strong {font-weight:normal;} + +.results .home a { + display:block; + margin:0 auto; + width:5em; + background:url(../images/community/docbook/home.png) top left no-repeat; + padding:5px; + padding-left:28px; + font-size:1.2em; +} + +.results ul.locale li:hover, .results ul.locale li:hover span.pofile, .results ul.locale li:hover strong, .results ul.locale li:hover span.value { + background-color:#666 !important; + color:white; +} + +ul.locale {list-style:none;} + +ul.locale li.total { + font-size:small; + color:#777; + width:31em; + display:block; + float:left; + margin-right:2em; + clear:none !important; +} + +ul.locale li { + clear:both; + font-size:small; + color:#777; + display:block; +} + +ul.locale strong, span.value { + font-weight:normal; + color:#888; + font-size:.7em; +} + +ul.locale li a { + font-size:1.2em; + display:block; + padding-top:.2em; +} + +ul.locale li.total div.progress { + position:relative; + left:0em; + top:0em; + margin-bottom:0em; +} + +ul.locale li {width:100%;} + +ul.locale li div.progress { + float:left; + position:relative; + left:30.5em; + top:-2em; + margin:0em; + margin-bottom:-3em; +} + +li.total {padding:0em !important;} + +li.total { + float:right; + max-width:16em; + padding:.5em; + margin:0 auto; + padding-top:.5em; + background-color:#f7f2d0; + font-size:1.3em !important; + color:#ccc !important; + margin-bottom:1em; + min-height:9.5em; +} + +li.total .value { + color:#444; + font-size:.8em; +} + +li.total strong { + display:block; + color:black; + font-weight:bold; +} + +li.total span.value { + position:relative; + display:block; + top:-1.25em; + text-align:right; +} + +.pofile {position:relative;} Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/apis.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/apis.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/bg.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/bg.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/ch04.execution.states.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/ch04.execution.states.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/ch09.persistent.process.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/ch09.persistent.process.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/class.diagram.process.definition.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/class.diagram.process.definition.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/class.diagram.process.execution.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/class.diagram.process.execution.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/community/title_hdr.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/community/title_hdr.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/composite.node.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/composite.node.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.automatic.wait1.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.automatic.wait1.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.automatic.wait2.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.automatic.wait2.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.automatic.wait3.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.automatic.wait3.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.concurrency.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.concurrency.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.loan.archive.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.loan.archive.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.loan.end.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.loan.end.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.loan.evaluate.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/execution.loan.evaluate.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/initial.in.composite.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/initial.in.composite.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/interceptors.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/interceptors.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/jbpm.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/jbpm.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/loan.db.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/loan.db.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/loan.execution.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/loan.execution.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.ab.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.ab.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.anatomy.classes.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.anatomy.classes.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.automatic.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.automatic.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.loan.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.loan.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.propagate.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.propagate.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.structure.classes.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/process.structure.classes.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/self.transition.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/self.transition.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transactions.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transactions.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.inheritence.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.inheritence.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.into.composite.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.into.composite.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.out.of.composite.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.out.of.composite.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.to.inner.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.to.inner.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.to.outer.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/images/transition.to.outer.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/index.html =================================================================== --- jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/index.html (rev 0) +++ jbpm4/trunk/modules/manual/target/docbook/publish/en/html_single/index.html 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,1170 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!DOCTYPE html + PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml"><head><title xmlns:rf="java:org.jboss.highlight.XhtmlRendererFactory">The Process Virtual Machine</title><link rel="stylesheet" href="css/jbossorg.css" type="text/css"/><meta xmlns:rf="java:org.jboss.highlight.XhtmlRendererFactory" name="generator" content="DocBook XSL Stylesheets V1.72.0"/></head><body><div class="book" lang="en"><div class="titlepage"><div><p id="title"><a href="http://www.jboss.org" class="site_href"><strong>JBoss.org</strong></a><a href="http://docs.jboss.org/" class="doc_href"><strong>Community Documentation</strong></a></p><div><h1 class="title"><a id="d0e1"/>The Process Virtual Machine</h1></div><div><h2 class="subtitle">A library for building executable state machines. It can + serve as the foundation for any form of BPM, workflow and orchestration. + </h2></div></div><hr/></div><div class="toc"><dl><dt><span class="chapter"><a href="#introduction">1. Introduction</a></span></dt><dd><dl><dt><span class="section"><a href="#d0e11">1.1. License and EULA</a></span></dt><dt><span class="section"><a href="#d0e22">1.2. Sources</a></span></dt><dt><span class="section"><a href="#d0e29">1.3. JVM version</a></span></dt><dt><span class="section"><a href="#d0e34">1.4. Library dependencies</a></span></dt><dt><span class="section"><a href="#d0e42">1.5. What is it</a></span></dt><dt><span class="section"><a href="#d0e82">1.6. Features</a></span></dt><dt><span class="section"><a href="#d0e105">1.7. Purpose</a></span></dt></dl></dd><dt><span class="chapter"><a href="#executionmodes">2. Execution modes</a></span></dt><dd><dl><dt><span class="section"><a href="#objectexecutionmode">2.1. Object execution mode</a></span></dt><dt><span class="section"><a href="#persistentexecutionmode">2.2. Persistent execution mode</a></span></dt><dt><spa! n class="section"><a href="#embeddedexecutionmode">2.3. Embedded execution mode</a></span></dt></dl></dd><dt><span class="chapter"><a href="#architecture">3. Architecture</a></span></dt><dd><dl><dt><span class="section"><a href="#apis">3.1. APIs</a></span></dt><dt><span class="section"><a href="#d0e419">3.2. Activity API</a></span></dt><dt><span class="section"><a href="#d0e433">3.3. Event listener API</a></span></dt><dt><span class="section"><a href="#d0e440">3.4. Client API</a></span></dt><dt><span class="section"><a href="#d0e447">3.5. Environment</a></span></dt><dt><span class="section"><a href="#d0e469">3.6. Commands</a></span></dt><dt><span class="section"><a href="#d0e477">3.7. Services</a></span></dt></dl></dd><dt><span class="chapter"><a href="#implementingbasicactivities">4. Implementing basic activities</a></span></dt><dd><dl><dt><span class="section"><a href="#activity">4.1. Activity</a></span></dt><dt><span class="section"><a href="#activityexample">4.2. Activi! ty example</a></span></dt><dt><span class="section"><a href="#external activity">4.3. ExternalActivity</a></span></dt><dt><span class="section"><a href="#externalactivityexample">4.4. ExternalActivity example</a></span></dt><dt><span class="section"><a href="#basicprocessexecution">4.5. Basic process execution</a></span></dt><dt><span class="section"><a href="#events">4.6. Events</a></span></dt><dt><span class="section"><a href="#d0e1133">4.7. Event propagation</a></span></dt></dl></dd><dt><span class="chapter"><a href="#processanatomy">5. Process anatomy</a></span></dt><dt><span class="chapter"><a href="#advancedgraphexecution">6. Advanced graph execution</a></span></dt><dd><dl><dt><span class="section"><a href="#d0e1378">6.1. Loops</a></span></dt><dt><span class="section"><a href="#d0e1386">6.2. Sub processes</a></span></dt><dt><span class="section"><a href="#implicitproceedbehaviour">6.3. Implicit proceed behaviour</a></span></dt><dt><span class="section"><a href="#functionalactivities">6.4. Functional activities</a></span></dt><dt><span cla! ss="section"><a href="#executionandthreads">6.5. Execution and threads</a></span></dt><dt><span class="section"><a href="#d0e1655">6.6. Process concurrency</a></span></dt><dt><span class="section"><a href="#d0e1695">6.7. Exception handlers</a></span></dt><dt><span class="section"><a href="#d0e1725">6.8. Process modifications</a></span></dt><dt><span class="section"><a href="#d0e1731">6.9. Locking and execution state</a></span></dt></dl></dd><dt><span class="chapter"><a href="#variables">7. Variables</a></span></dt><dt><span class="chapter"><a href="#timers">8. Timers</a></span></dt><dt><span class="chapter"><a href="#asynchronouscontinuations">9. Asynchronous continuations</a></span></dt><dt><span class="chapter"><a href="#softwarelogging">10. Software logging</a></span></dt><dd><dl><dt><span class="section"><a href="#d0e1793">10.1. Configuration</a></span></dt><dt><span class="section"><a href="#d0e1812">10.2. Categories</a></span></dt><dt><span class="section"><a href="#d! 0e1825">10.3. JDK logging</a></span></dt><dt><span class="section"><a href="#d0e1855">10.4. Debugging persistence</a></span></dt></dl></dd></dl></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="introduction"/>Chapter 1. Introduction</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#d0e11">1.1. License and EULA</a></span></dt><dt><span class="section"><a href="#d0e22">1.2. Sources</a></span></dt><dt><span class="section"><a href="#d0e29">1.3. JVM version</a></span></dt><dt><span class="section"><a href="#d0e34">1.4. Library dependencies</a></span></dt><dt><span class="section"><a href="#d0e42">1.5. What is it</a></span></dt><dt><span class="section"><a href="#d0e82">1.6. Features</a></span></dt><dt><span class="section"><a href="#d0e105">1.7. Purpose</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e11"/>1.1. License and EULA</h2></div></div></div><p>The Process Virtual Machine component is distributed! under the terms of the + GNU Lesser General Public License (LGPL) and the JBoss End User License Agreement (EULA). + See <a xmlns:xlink="http://www.w3.org/1999/xlink" href="../../../lgpl.html">the full LGPL license text</a> and <a xmlns:xlink="http://www.w3.org/1999/xlink" href="../../../JBossORG-EULA.txt">the + full End User License Agreement</a>. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e22"/>1.2. Sources</h2></div></div></div><p>The source code for this component can be found in the jBPM SVN repository: + </p><a xmlns:xlink="http://www.w3.org/1999/xlink" href="https://anonsvn.jboss.org/repos/jbpm/jbpm4/pvm/">https... class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e29"/>1.3. JVM version</h2></div></div></div><p>jbpm-pvm.jar requires a JVM version 5 or higher. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e34"/>1.4. Library dependencies</h2></div></div></div><p>For building and executing processes the jbpm-pvm.jar does not have any other + dependencies then on the JVM. If you're using DB persistence, then there is a dependency + on hibernate and it's dependencies. More information about the optional depedencies can + be found in the <a xmlns:xlink="http://www.w3.org/1999/xlink" href="../../lib/optional-dependencies.html">lib directory</a>. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e42"/>1.5. What is it</h2></div></div></div><p>In essence, the Process Virtual Machine is a framework specifying executable + graphs. A process definition represents an execution flow and has a structure that + be represented graphically as a diagram. + </p><div class="figure"><a id="example.process.graph"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/process.loan.png" align="middle" alt="Example process definition"/></div></div><p class="title"><b>Figure 1.1. Example process definition</b></p></div><br class="figure-break"/><p>Typically, process definitions are static. A process definition is composed of + nodes and transitions. The runtime behaviour of a node is encapsulated in a so called + Activity and it's decoupled from the process graph structure. + </p><div class="figure"><a id="class.diagram.process.definition"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/class.diagram.process.definition.png" align="middle" alt="Process structure class diagram"/></div></div><p class="title"><b>Figure 1.2. Process structure class diagram</b></p></div><br class="figure-break"/><p>The Process Virtual + Machine doesn't contain any such activity implementations. It only provides the + execution environment and an activity API to write <code class="literal">Activity</code> + implementations as Java components. Activities can also be wait states. This means + that the node control flow goes outside the process system. For example a human task + or invoking an service asynchronously. + </p><p>Many executions can be started for one process definition. An execution is a pointer + that keeps track of the current node. + </p><div class="figure"><a id="example.execution"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/loan.execution.png" align="middle" alt="Example execution"/></div></div><p class="title"><b>Figure 1.3. Example execution</b></p></div><br class="figure-break"/><p>To represent concurrent paths of execution, there is + a hierarchical parent-child relation between so that one process instance can cope with concurrent + paths of execution. + </p><div class="figure"><a id="class.diagram.process.execution"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/class.diagram.process.execution.png" align="middle" alt="Execution class diagram"/></div></div><p class="title"><b>Figure 1.4. Execution class diagram</b></p></div><br class="figure-break"/></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e82"/>1.6. Features</h2></div></div></div><p>The key features of this library are + </p><div class="itemizedlist"><ul><li>Create executable processes that are based on a diagram structure</li><li>Runtime behaviour of the nodes can be provided as Activity implementations</li><li>Activities can be wait states</li><li>There are no constraints on the process graph structure</li><li>Processes diagrams can be based on composition (aka block structured)</li><li>Processes diagrams can be a mix of graph based and composition</li><li>During wait states, the runtime state of a process execution can be persisted</li><li>Persistence is optional</li></ul></div><p> + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e105"/>1.7. Purpose</h2></div></div></div><p>The Process Virtual Machine is designed in such a way that it's easy to build + workflow, BPM, orchestration and other graph based execution langauges on top + of it. Examples of languages that have been built on top of this library: + </p><div class="itemizedlist"><ul><li>jPDL: Workflow language that combines powerful human task capabilities with easy binding to Java.</li><li>BPEL: Web-Service orchestration (to be exact for the purists: BPEL is a WSDL service orchestration language)</li><li>Pageflow: To describe navigation handling in a web application, pages can be seen as nodes and the nagivation between the pages as transitions.</li><li>XPDL: A graph based process language standardized by the Workflow Management Coalition (WfMC)</li></ul></div><p>Even while the nature of these languages is already very diverse, these are + all examples of general purpose workflow languages. The real power of the + Process Virtual Machine is that it's very easy to build Domain Specific Languages (DSL) + with it. For instance, it's very easy to build a very simple (and dedicated) workflow + language to specify approvals related to documents in a document management system. + </p><p>BPM as a discipline refers to the management level effort to optimise efficiency + of an organisation by analysing and optimising the procedures of how people and systems + work together. In designing the Process Virtual Machine and the jPDL language + in particular, we have spend great care on facilitating the link between BPM analysis + notations and executable process languages. Here are the most known modeling notations: + </p><div class="itemizedlist"><ul><li>BPMN: OMG latest notation for modeling business processes. + This is a modeling notation that is targetted explicitely to be bound + to executable processes. + </li><li>UML activity diagrams: OMG notation for modeling business + processes. Mostly used in business context.</li><li>UML state diagrams: OMG modeling notation for defining technical + state machines. More used in a technical context.</li><li>EPC: Event driven process chains. Rich notation for modeling + business processes driven by SAP and IDS Scheer.</li></ul></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="executionmodes"/>Chapter 2. Execution modes</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#objectexecutionmode">2.1. Object execution mode</a></span></dt><dt><span class="section"><a href="#persistentexecutionmode">2.2. Persistent execution mode</a></span></dt><dt><span class="section"><a href="#embeddedexecutionmode">2.3. Embedded execution mode</a></span></dt></dl></div><p>There are basically three process execution modes: object, persistent + and embedded. For the persistent and embedded execution modes, the process + execution has to participate in a transaction. In that case, the process + execution has to take place inside of an Environment. The environment will be + used to bind process execution updates to a transaction in the application + transaction. The environment can be used to bind to e.g. a JDBC connection, + JTA, BMT, Spring transactions and so on. + </p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="objectexecutionmode"/>2.1. Object execution mode</h2></div></div></div><p>Object execution mode is the simplest form of working with the Process + Virtual Machine. This means working with the process definition and execution + objects directly through the client API. Let's show this by an example. We + start by creating a <code class="literal">ClientProcessDefinition</code> that looks like this: + </p><p>Object execution mode is the simplest form of working with the Process + Virtual Machine. This means working with the process definition and execution + objects directly through the client API. Let's show this by an example. We + start by creating a <code class="literal">ClientProcessDefinition</code> that looks like this: + </p><div class="figure"><a id="loan.process"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/process.loan.png" align="middle" alt="The loan process"/></div></div><p class="title"><b>Figure 2.1. The loan process</b></p></div><br class="figure-break"/><pre class="programlisting">ClientProcessDefinition processDefinition = ProcessFactory.build("loan") + .node("submit loan request").initial().behaviour(AutomaticActivity.class) + .transition().to("evaluate") + .node("evaluate").behaviour(WaitState.class) + .transition("approve").to("wire money") + .transition("reject").to("end") + .node("wire money").behaviour(AutomaticActivity.class) + .transition().to("archive") + .node("archive").behaviour(WaitState.class) + .transition().to("end") + .node("end").behaviour(WaitState.class) +.done();</pre><p>The <code class="literal">ProcessFactory</code> is a helper class that provides convenience + for building an object graph that represents a process definition. + <code class="literal">AutomaticActivity</code> is a pass-through activity without anything + happening and <code class="literal">WaitState</code> will wait until an external signal is given. Both + activity implementations will be covered in more depth later. + </p><p>The <code class="literal">processDefinition</code> object serves as a factory for process + instance objects. A process instance represents one execution of the process definition. + More precise, the process instance is the main path of execution. + </p><pre class="programlisting">ClientExecution execution = processDefinition.startProcessInstance();</pre><p>A process instance + itself is also an <code class="literal">Execution</code>. Potentially, an execution can have + child executions to represent concurrent paths of execution. + </p><p>The <code class="literal">execution</code> can be seen as a state machine that operates as + described in the process definition. Starting a process + instance means that the initial node of the process definition is executed. + Since this is an automatic activity, the execution will proceed to the + <code class="literal">evaluate</code> node. The <code class="literal">evaluate</code> node is a wait state. + When the execution arrived at the evaluate node, the method <code class="literal">startProcessInstance</code> + will return and waits until an external signal is provided with the <code class="literal">signal</code> + method. So after the <code class="literal">startProcessInstance</code> we can verify if the + execution is positioned in the evaluate node. + </p><pre class="programlisting">assertEquals("evaluate", execution.getNodeName());</pre><p>To make the process execute further, we provide an external trigger with the + <code class="literal">signal</code> method. The result of the evaluation will be given as the + signalName parameter like this: + </p><pre class="programlisting">execution.signal("approve");</pre><p>The <code class="literal">WaitState</code> activity implementation will take the transition + that corresponds to the given signalName. So the execution will first execute + the automatic activity <code class="literal">wire money</code> and then return after entering + the next wait state <code class="literal">archive</code>. + </p><pre class="programlisting">assertEquals("archive", execution.getNodeName());</pre><p>When the execution is waiting in the archive node, the default signal will + make it take the first unnamed transition. + </p><pre class="programlisting">execution.signal(); +assertEquals("end", execution.getNodeName());</pre><p>The process has executed in the thread of the client. The + <code class="literal">startProcessInstance</code> method only returned when the <code class="literal">evaluate</code> + node was reached. In other words, the <code class="literal">ClientProcessDefinition.startProcessInstance</code> + and <code class="literal">ClientExecution.signal</code> methods are blocking until the next + wait state is reached. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="persistentexecutionmode"/>2.2. Persistent execution mode</h2></div></div></div><p>The Process Virtual Machine also contains the hibernate mappings to store the + process definitions and executions in any database. A special session facade called + <code class="literal">ExecutionService</code> is provided for working with process executions + in such a persistent environment. + </p><p>Two configuration files should be available on the classpath: an environment + configuration file and a <code class="literal">hibernate.properties</code> file. A basic + configuration for persistent execution mode in a standard Java environment looks + like this: + </p><code class="literal"><span class="bold"><strong>environment.cfg.xml</strong></span>:</code><pre class="programlisting">&lt;contexts xmlns="http://jbpm.org/pvm/1.0/wire"&gt; + + &lt;environment-factory&gt; + + &lt;deployer-manager&gt; + &lt;language name="api"&gt; + &lt;check-version /&gt; + &lt;create-id /&gt; + &lt;save-process /&gt; + &lt;/language&gt; + &lt;/deployer-manager&gt; + + &lt;process-service /&gt; + &lt;execution-service /&gt; + &lt;management-service /&gt; + + &lt;command-service&gt; + &lt;retry-interceptor /&gt; + &lt;environment-interceptor /&gt; + &lt;standard-transaction-interceptor /&gt; + &lt;/command-service&gt; + + &lt;hibernate-configuration&gt; + &lt;properties resource="hibernate.properties" /&gt; + &lt;mappings resource="org/jbpm/pvm/pvm.hibernate.mappings.xml" /&gt; + &lt;cache-configuration resource="org/jbpm/pvm/pvm.cache.xml" + usage="nonstrict-read-write" /&gt; + &lt;/hibernate-configuration&gt; + + &lt;hibernate-session-factory /&gt; + + &lt;id-generator /&gt; + &lt;variable-types resource="org/jbpm/pvm/pvm.types.xml" /&gt; + &lt;job-executor auto-start="false" /&gt; + + &lt;/environment-factory&gt; + + &lt;environment&gt; + &lt;hibernate-session /&gt; + &lt;transaction /&gt; + &lt;pvm-db-session /&gt; + &lt;job-db-session /&gt; + &lt;message-session /&gt; + &lt;/environment&gt; + +&lt;/contexts&gt;</pre><p>And next to it a hibernate.properties like this</p><code class="literal">hibernate.properties:</code><pre class="programlisting">hibernate.dialect org.hibernate.dialect.HSQLDialect +hibernate.connection.driver_class org.hsqldb.jdbcDriver +hibernate.connection.url jdbc:hsqldb:mem:. +hibernate.connection.username sa +hibernate.connection.password +hibernate.hbm2ddl.auto create-drop +hibernate.cache.use_second_level_cache true +hibernate.cache.provider_class org.hibernate.cache.HashtableCacheProvider +# hibernate.show_sql true +hibernate.format_sql true +hibernate.use_sql_comments true</pre><p>Then you can obtain the services from the environment factory like this: + </p><pre class="programlisting">EnvironmentFactory environmentFactory = new PvmEnvironmentFactory("environment.cfg.xml"); + +ProcessService processService = environmentFactory.get(ProcessService.class); +ExecutionService executionService = environmentFactory.get(ExecutionService.class); +ManagementService managementService = environmentFactory.get(ManagementService.class);</pre><p>The responsibility of the <code class="literal">ProcessService</code> is to manage + the repository of process definitions. Before we can start a process execution, + the process definition needs to be deployed into the process repository. + Process definitions can be supplied in various formats and process definition + languages. A deployment collects process definition information from various + sources like a ZIP file, an XML file or a process definition object. + The method <code class="literal">ProcessService.deploy</code> will take a deployment + through all the deployers that are configured in the configuration file. + </p><p>In this example, we'll supply a process definition programmatically + for deployment.</p><pre class="programlisting">ClientProcessDefinition processDefinition = ProcessFactory.build("loan") + .node("submit loan request").initial().behaviour(AutomaticActivity.class) + .transition().to("evaluate") + .node("evaluate").behaviour(WaitState.class) + .transition("approve").to("wire money") + .transition("reject").to("end") + .node("wire money").behaviour(AutomaticActivity.class) + .transition().to("archive") + .node("archive").behaviour(WaitState.class) + .transition().to("end") + .node("end").behaviour(WaitState.class) +.done(); + +Deployment deployment = new Deployment(processDefinition); +processService.deploy(deployment);</pre><p>Now, a version of that process definition is stored in the database. + The <code class="literal">check-version</code> deployer will have assigned version 1 + to the stored process definition. The <code class="literal">create-id</code> deployer + will have distilled id <code class="literal">loan:1</code> from the process name and the + assigned version. + </p><p>Deploying that process again will lead to a new process definition + version being created in the database. But an incremented version number will + be assigned. For the purpose of versioning, process definitions are considered + equal if they have the same name.</p><p>It is recommended that a user provided key reference is supplied for + all process executions. Starting a new process execution goes like this: + </p><pre class="programlisting">Execution execution = executionService.startExecution("loan:1", "request7836");</pre><p>The return value is an execution interface, which prevents navigation of relations. + That is because outside of the service methods, the transaction and hibernate session + is not guaranteed to still be open. In fact, the default configuration as given + above will only keep the transaction and session open for the duration of the + service method. So navigating the relations outside of the service methods might result + into a hibernate <code class="literal">LazyInitializationException</code>. But the + current node name can still be verified: + </p><pre class="programlisting">assertEquals("evaluate", execution.getNodeName());</pre><p>Also very important is the generated id that can be obtained. The default + <code class="literal">id-generator</code> will use the process definition id and the + given key to make a unique id for the process execution like this:</p><pre class="programlisting">assertEquals("loan:1/request7836", execution.getId());</pre><p>That id must be when providing the subsequent external triggers to the + process execution like this: + </p><pre class="programlisting">executionService.signalExecution("loan:1/request7836", "approve");</pre><p>More information about service interfaces to run in persistent + mode can be found in package + <a xmlns:xlink="http://www.w3.org/1999/xlink" href="../../api/org/jbpm/pvm/package-summary.html"><code class="literal">org.jbpm.pvm</code> of the + api docs</a>. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="embeddedexecutionmode"/>2.3. Embedded execution mode</h2></div></div></div><p>Embedded execution mode means that the state of a process is stored + as a string column inside a user domain object like e.g. a loan. + </p><pre class="programlisting">public class Loan { + + <span class="bold"><strong>/** the loan process definition as a static resource */ + private static final ClientProcessDefinition processDefinition = createLoanProcess(); + + private static ClientProcessDefinition createLoanProcess() { + ClientProcessDefinition processDefinition = ProcessFactory.build("loan") + .node("submit loan request").initial().behaviour(AutomaticActivity.class) + .transition().to("evaluate") + .node("evaluate").behaviour(WaitState.class) + .transition("approve").to("wire money") + .transition("reject").to("end") + .node("wire money").behaviour(AutomaticActivity.class) + .transition().to("archive") + .node("archive").behaviour(WaitState.class) + .transition().to("end") + .node("end").behaviour(WaitState.class) + .done(); + + return processDefinition; + } + + /** exposes the process definition to the execution hibernate type */ + private static ClientProcessDefinition getProcessDefinition() { + return processDefinition; + } + </strong></span> + + long dbid; + String customer; + double amount; + <span class="bold"><strong>ClientExecution execution;</strong></span> + + /** constructor for persistence */ + protected Loan() { + } + + public Loan(String customer, double amount) { + this.customer = customer; + this.amount = amount; + <span class="bold"><strong>this.execution = processDefinition.startProcessInstance();</strong></span> + } + + public void approve() { + <span class="bold"><strong>execution.signal("approve");</strong></span> + } + + public void reject() { + <span class="bold"><strong>execution.signal("reject");</strong></span> + } + + public void archiveComplete() { + <span class="bold"><strong>execution.signal();</strong></span> + } + + public String getState() { + return <span class="bold"><strong>execution.getNodeName()</strong></span>; + } + + ...getters... +}</pre><p>If you ignore the bold parts for a second, you can see that this is a + POJO without anything fancy. It's just a bean that can be stored with hibernate. + The bold part indicate that implementation part of the class that is related + to process and execution. Not that nothing of the process definition or + execution is exposed to the user of the Loan class. + </p><p>Each <code class="literal">Loan</code> object corresponds to a <code class="literal">loan</code> + process instance. Some methods of the <code class="literal">Loan</code> class correspond + to the external triggers that need to be given during the lifecycle of a + <code class="literal">Loan</code> object. + </p><p>Next we'll show how to use this class. To get started we need a</p><span class="bold"><strong><code class="literal">hibernate.cfg.xml:</code></strong></span><pre class="programlisting">&lt;?xml version="1.0" encoding="utf-8"?&gt; + +&lt;!DOCTYPE hibernate-configuration PUBLIC + "-//Hibernate/Hibernate Configuration DTD 3.0//EN" + "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd"&gt; + +&lt;hibernate-configuration&gt; + &lt;session-factory&gt; + + &lt;property name="hibernate.dialect"&gt;org.hibernate.dialect.HSQLDialect&lt;/property&gt; + &lt;property name="hibernate.connection.driver_class"&gt;org.hsqldb.jdbcDriver&lt;/property&gt; + &lt;property name="hibernate.connection.url"&gt;jdbc:hsqldb:mem:.&lt;/property&gt; + &lt;property name="hibernate.connection.username"&gt;sa&lt;/property&gt; + &lt;property name="hibernate.connection.password"&gt;&lt;/property&gt; + &lt;property name="hibernate.hbm2ddl.auto"&gt;create&lt;/property&gt; + &lt;property name="hibernate.show_sql"&gt;true"&lt;/property&gt; + &lt;property name="hibernate.format_sql"&gt;true"&lt;/property&gt; + &lt;property name="hibernate.use_sql_comments"&gt;true"&lt;/property&gt; + + &lt;mapping resource="Loan.hbm.xml"/&gt; + + &lt;/session-factory&gt; +&lt;/hibernate-configuration&gt;</pre><p>And a</p><span class="bold"><strong><code class="literal">Loan.hbm.xml:</code></strong></span><pre class="programlisting">&lt;?xml version="1.0"?&lt; + +&lt;!DOCTYPE hibernate-mapping PUBLIC + "-//Hibernate/Hibernate Mapping DTD 3.0//EN" + "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"&lt; + +&lt;hibernate-mapping package="org.jbpm.pvm.api.db.embedded" default-access="field"&lt; + + &lt;typedef name="execution" class="org.jbpm.pvm.internal.hibernate.ExecutionType" /&lt; + + &lt;class name="Loan" table="LOAN"&lt; + + &lt;id name="dbid"&lt; + &lt;generator class="sequence"/&lt; + &lt;/id&lt; + + &lt;property name="execution" type="execution" /&lt; + &lt;property name="customer" /&lt; + &lt;property name="amount" /&lt; + + &lt;/class&lt; + +&lt;/hibernate-mapping&lt;</pre><p>Then you can use the Loan class like this in a test</p><pre class="programlisting">Configuration configuration = new Configuration(); +configuration.configure(); +SessionFactory sessionFactory = configuration.buildSessionFactory(); + +// start a session/transaction +Session session = sessionFactory.openSession(); +Transaction transaction = session.beginTransaction(); + +Loan loan = new Loan("john doe", 234.0); +session.save(loan); +assertEquals("evaluate", loan.getState()); + +// start a new session/transaction +transaction.commit(); +session.close(); +session = sessionFactory.openSession(); +transaction = session.beginTransaction(); + +loan = (Loan) session.get(Loan.class, loan.getDbid()); +assertEquals("evaluate", loan.getState()); +loan.approve(); +assertEquals("archive", loan.getState()); + +// start a new session/transaction +transaction.commit(); +session.close();</pre><p>After executing this code snippet, this is the loan record in the DB:</p><div class="figure"><a id="loan.db"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/loan.db.png" align="middle" alt="The loan record in the DB"/></div></div><p class="title"><b>Figure 2.2. The loan record in the DB</b></p></div><br class="figure-break"/></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="architecture"/>Chapter 3. Architecture</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#apis">3.1. APIs</a></span></dt><dt><span class="section"><a href="#d0e419">3.2. Activity API</a></span></dt><dt><span class="section"><a href="#d0e433">3.3. Event listener API</a></span></dt><dt><span class="section"><a href="#d0e440">3.4. Client API</a></span></dt><dt><span class="section"><a href="#d0e447">3.5. Environment</a></span></dt><dt><span class="section"><a hre! f="#d0e469">3.6. Commands</a></span></dt><dt><span class="section"><a href="#d0e477">3.7. Services</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="apis"/>3.1. APIs</h2></div></div></div><p>The Process Virtual Machine has 4 integrated API's that together + offer a complete coverage of working with processes in the different execution modes. + Each of the APIs has a specific purpose that fits within the following overall + architecture. + </p><div class="figure"><a id="apis"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/apis.png" align="middle" alt="The 4 API's of the Process Virtual Machine"/></div></div><p class="title"><b>Figure 3.1. The 4 API's of the Process Virtual Machine</b></p></div><br class="figure-break"/><p>The services interfaces should be used from application code that wants to interact + with the Process Virtual Machine which runs in transactional persistent mode, backed by a + database. This is the most typical way how users interact with the PVM as a workflow engine. + </p><p>To execute processes without persistence, the client API can be used to work with process + and execution objects directly. The client API expose the methods of the core model objects. + </p><p>The activity API is used to implement the runtime behaviour of activities. So a activity + type is in fact a component with at the core an implementation of the <code class="literal">Activity</code> + interface. Activity implementations can control the flow of execution. + </p><p>The event listener API serves to write pieces of Java code that should be executed upon + process events. It's very similar to the activity API with that exception that event listeners + are not able to control the flow of execution. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e419"/>3.2. Activity API</h2></div></div></div><p>The activity API allows to implement the runtime activity behaviour in Java. + </p><pre class="programlisting">public interface Activity extends Serializable { + void execute(ActivityExecution execution) throws Exception; +}</pre><p>An activity is the behaviour of the node to which it is associated. + The provided execution is the execution that arrives in the node. + The interface <code class="literal">ActivityExecution</code> exposes special + methods to control the execution flow. + </p><pre class="programlisting">public interface ActivityExecution extends OpenExecution { + + void waitForSignal(); + void take(String transitionName); + void execute(String nodeName); + + ... + +}</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e433"/>3.3. Event listener API</h2></div></div></div><p>The event listener API allows for listeners to be developed in Java code + and that are invoked on specific process events like entering a node or leaving + a node. It is very similar to the activity API, but the difference is + that the propagation of the execution flow cannot be controlled. E.g. when an execution + is taking a transition, a listener to that event can be notified, but since the + transition is already being taking, the execution flow cannot be changed + by the event listeners. + </p><pre class="programlisting">public interface EventListener extends Serializable { + + void notify(EventListenerExecution execution) throws Exception; + +}</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e440"/>3.4. Client API</h2></div></div></div><p>The client API was already introduced above in the object execution mode + and embedded execution mode. It's an interface that exposes the methods for + managing executions on the plain process definition and execution objects directly. + </p><p>At a minimal, the client API and the activity API are needed to create + some a process definition with activities and execute it. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e447"/>3.5. Environment</h2></div></div></div><p>In the persistent execution mode, the first purpose of the environment is + to enable processes to be executed in different transactional environments like + standard Java, enterprise Java, SEAM and Spring. + </p><p>The PVM code itself will only use transactional resources through self-defined + interfaces. For example, the PVM itself has interfaces for some methods on the hibernate + session, a async messaging session and a timer session. + </p><p>The environment allows to configure the actual implementations, lazy + initialization of the services on a request-basis and caching the service + objects for the duration of the transaction. + </p><p>An environment factory is static and one environment factory can serve + all the threads in an application. + </p><pre class="programlisting">EnvironmentFactory environmentFactory = new PvmEnvironmentFactory("environment.cfg.xml");</pre><p>Environment blocks can surround persistent process operations + like this: + </p><pre class="programlisting">Environment environment = environmentFactory.openEnvironment(); +try { + + ... inside the environment block... + +} finally { + environment.close(); +}</pre><p>The PVM itself will fetch all it's transactional resources and configurations + from the environment. It's recommended that <code class="literal">Activity</code> implementations + do the same. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e469"/>3.6. Commands</h2></div></div></div><p>Commands encapsulate operations that are to be executed within an environment + block. The main purpose for commands is to capture the logic of + </p><pre class="programlisting">public interface Command&lt;T&gt; extends Serializable { + + T execute(Environment environment) throws Exception; + +}</pre><p/></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e477"/>3.7. Services</h2></div></div></div><p>There are three services: <code class="literal">ProcessService</code>, + <code class="literal">ExecutionService</code> and <code class="literal">ManagementService</code>. + In general, services are session facades that expose methods for persistent + usage of the PVM. The next fragments show the essential methods as example + to illustrate those services. + </p><p>The <code class="literal">ProcessService</code> manages the repository of + process definitions. + </p><pre class="programlisting">public interface ProcessService { + + ProcessDefinition deploy(Deployment deployment); + + ProcessDefinition findLatestProcessDefinition(String processDefinitionName); + + ... + +}</pre><p>The <code class="literal">ExecutionService</code> manages the runtime + executions.</p><pre class="programlisting">public interface ExecutionService { + + Execution startExecution(String processDefinitionId, String executionKey); + + Execution signalExecution(String executionId, String signalName); + + ... + +}</pre><p>The <code class="literal">ManagementService</code> groups all management operations + that are needed to keep the system up and running. + </p><pre class="programlisting">public interface ManagementService { + + List&lt;Job&gt; getJobsWithException(int firstResult, int maxResults); + + void executeJob(String jobId); + + ... + +}</pre><p>The implementation of all these methods is encapsulated in + <code class="literal">Command</code>s. And the three services all delegate the + execution of the commands to a <code class="literal">CommandService</code>: + </p><pre class="programlisting">public interface CommandService { + + &lt;T&gt; T execute(Command&lt;T&gt; command); + +}</pre><p>The <code class="literal">CommandService</code> is configured in the + environment. A chain of CommandServices can act as interceptors + around a command. This is the core mechanism on how persistence and + transactional support can be offered in a variety of environments. + </p><p>From the default configuration which is included in full above, + here is the section that configures the services + </p><pre class="programlisting">&lt;contexts xmlns="http://jbpm.org/pvm/1.0/wire"&gt; + + &lt;environment-factory&gt; + + &lt;process-service /&gt; + &lt;execution-service /&gt; + &lt;management-service /&gt; + + &lt;command-service&gt; + &lt;retry-interceptor /&gt; + &lt;environment-interceptor /&gt; + &lt;standard-transaction-interceptor /&gt; + &lt;/command-service&gt; + + ... + </pre><p>The three services <code class="literal">process-service</code>, <code class="literal">execution-service</code> + and <code class="literal">management-service</code> will look up the configured + <code class="literal">command-service</code> by type. The <code class="literal">command-service</code> + tag corresponds to the default command service that essentially does nothing else + then just execute the command providing it the current environment. + </p><p>The configured <code class="literal">command-service</code> results into the following + a chain of three interceptors followed by the default command executor. + </p><div class="figure"><a id="interceptors"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/interceptors.png" align="middle" alt="The CommandService interceptors"/></div></div><p class="title"><b>Figure 3.2. The CommandService interceptors</b></p></div><br class="figure-break"/><p>The retry interceptor is the first in the chain and that one that will be exposed as the + <code class="literal">CommandService.class</code> from the environment. So the retry interceptor + will be given to the respective services <code class="literal">process-service</code>, <code class="literal">execution-service</code> + and <code class="literal">management-service</code>. + </p><p>The <code class="literal">retry-interceptor</code> will catch hibernate StaleObjectExceptions + (indicating optimistic locking failures) and retry to execute the command. + </p><p>The <code class="literal">environment-interceptor</code> will put an environment block + around the execution of the command. + </p><p>The <code class="literal">standard-transaction-interceptor</code> will initialize a + <code class="literal">StandardTransaction</code>. The hibernate session/transaction will be + enlisted as a resource with this standard transaction. + </p><p>Different configurations of this interceptor stack will also enable to + </p><div class="itemizedlist"><ul><li>delegate execution to a local ejb command service so that an container + managed transaction is started. + </li><li>delegate to a remote ejb command service so that the command actually + gets executed on a different JVM. + </li><li>package the command as an asynchronous message so that the command gets + executed asynchronously in a different transaction. + </li></ul></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="implementingbasicactivities"/>Chapter 4. Implementing basic activities</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#activity">4.1. Activity</a></span></dt><dt><span class="section"><a href="#activityexample">4.2. Activity example</a></span></dt><dt><span class="section"><a href="#externalactivity">4.3. ExternalActivity</a></span></dt><dt><span class="section"><a href="#externalactivityexample">4.4. ExternalActivity example</a></span></dt><dt><span class="section"><a href="#basicprocessexecution">4.5. Basic process execution</a></span></dt><dt><span class="section"><a href="#events">4.6. Events</a></span></dt><dt><span class="section"><a href="#d0e1133">4.7. Event propagation</a></span></dt></dl></div><p>This chapter explains the basics of process definitions, the features offered by + the Process Virtual Machine and how activity implementations can be build. At the same + time the client API is shown to execute processes with those activity implementations. + </p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="activity"/>4.1. Activity</h2></div></div></div><p>The PVM library doesn't have a fixed set of process constructs. + Instead, runtime behaviour of a node is delegated to an <code class="literal">Activity</code>. + In other words, <code class="literal">Activity</code> is an interface to implement the runtime + behaviour of process constructs in plain Java. + </p><pre class="programlisting">public <span class="bold"><strong>interface Activity</strong></span> extends Serializable { + + void <span class="bold"><strong>execute</strong></span>(ActivityExecution execution) throws Exception; + +}</pre><p>When an activity is used as the node behaviour, it is in full control of the further + propagation of the execution. In other words, a node behaviour can decide what the execution + should do next. For example, it can take a transition with + <code class="literal">execution.take(Transition)</code> or go into a wait state with + <code class="literal">execution.waitForSignal()</code>. In case the node behaviour does not invoke + any of the above execution propagation methods, the execution will + <a href="#implicitproceedbehaviour" title="6.3. Implicit proceed behaviour">proceed in a default way</a>. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="activityexample"/>4.2. Activity example</h2></div></div></div><p>We'll start with a very original hello world example. A Display + activity will print a message to the console: + </p><pre class="programlisting">public <span class="bold"><strong>class Display</strong></span> implements <span class="bold"><strong>Activity</strong></span> { + + String message; + + public Display(String message) { + this.message = message; + } + + public void execute(ActivityExecution execution) { + <span class="bold"><strong>System.out.println(message);</strong></span> + } +}</pre><p>Let' build our first process definition with this activity:</p><div class="figure"><a id="activity.example"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/process.ab.png" align="middle" alt="Display example process"/></div></div><p class="title"><b>Figure 4.1. Display example process</b></p></div><br class="figure-break"/><pre class="programlisting">ClientProcessDefinition processDefinition = ProcessFactory.build() + .<span class="bold"><strong>node("a").initial()</strong></span>.behaviour(<span class="bold"><strong>new Display("hello")</strong></span>) + .transition().to("b") + .<span class="bold"><strong>node("b")</strong></span>.behaviour(<span class="bold"><strong>new Display("world")</strong></span>) +.done();</pre><p>Now we can execute this process as follows:</p><pre class="programlisting">Execution execution = processDefinition.startExecution();</pre><p>The invocation of <code class="literal">startExecution</code> will print hello world to the console:</p><pre class="programlisting">hello +world</pre><p>One thing already worth noticing is that activities can be configured + with properties. In the Display example, you can see that the message property + is configured differently in the two usages. With configuration properties + it becomes possible to write reusable activities. They can then be configured + differently each time they are used in a process. That is an essential part of + how process languages can be build on top of the Process Virtual Machine. + </p><p>The other part that needs explanation is that this activity + implementation does not contain any instructions for the propagation of the + execution. When a new process instance is started, the execution is positioned + in the initial node and that activity is executed. The method + <code class="literal">Display.execute</code> makes use of what is called implicit propagation + of execution. Concretely this means that the activity itself does not + invoke any of the methods on the execution to propagate it. In that case + implicit propagation kicks in. Implicit propagation will take the first + transition if there is one. If not, it will end the execution. This explains + why both nodes <code class="literal">a</code> and <code class="literal">b</code> are executed and that + the execution stops after node <code class="literal">b</code> is executed. + </p><p>More details about the implicit proceed behaviour can be found + in <a href="#implicitproceedbehaviour" title="6.3. Implicit proceed behaviour">Section 6.3, “Implicit proceed behaviour”</a></p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="externalactivity"/>4.3. ExternalActivity</h2></div></div></div><p>External activities are activities for which the responsibility for proceeding + the execution is transferred externally, meaning outside the process system. This + means that for the system that is executing the process, it's a wait state. The + execution will wait until an external trigger is given. + </p><p>For dealing with external triggers, <code class="literal">ExternalActivity</code> + adds two methods to the <code class="literal">Activity</code>:</p><pre class="programlisting">public <span class="bold"><strong>interface ExternalActivity</strong></span> extends <span class="bold"><strong>Activity</strong></span> { + + void <span class="bold"><strong>signal</strong></span>(Execution execution, + String signal, + Map&lt;String, Object&gt; parameters) throws Exception; + +}</pre><p>Just like with plain activities, when an execution arrives in a node, the + <code class="literal">execute</code>-method of the node behaviour is invoked. + In external activities, the execute method typically does something to + transfer the responsibility to another system and then enters a wait + state by invoking <code class="literal">execution.waitForSignal()</code>. For + example in the execute method, responsibility could be transferred to a + person by creating a task entry in a task management system and then + wait until the person completes the task. + </p><p>In case a node behaves as a wait state, then the execution will + wait in that node until the execution's <code class="literal">signal</code> method + is invoked. The execution will delegate that signal to the behaviour Activity + of the current node. + </p><p>So the Activity's <code class="literal">signal</code>-method is invoked + when the execution receives an external trigger during the wait state. With the + signal method, responsibility is transferred back to the process execution. For + example, when a person completes a task, the task management system calls the + signal method on the execution. + </p><p>A signal can optionally have a signal name and a map of parameters. Most + common way on how node behaviours interprete the signal and parameters is that + the signal relates to the outgoing transition that needs to be taken and that the + parameters are set as variables on the execution. But those are just examples, it + is up to the activity to use the signal and the parameters as it pleases. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="externalactivityexample"/>4.4. ExternalActivity example</h2></div></div></div><p>Here's a first example of a simple wait state implementation: + </p><pre class="programlisting">public <span class="bold"><strong>class WaitState</strong></span> implements <span class="bold"><strong>ExternalActivity</strong></span> { + + public void execute(ActivityExecution execution) { + <span class="bold"><strong>execution.waitForSignal();</strong></span> + } + + public void signal(ActivityExecution execution, + String signalName, + Map&lt;String, Object&gt; parameters) { + <span class="bold"><strong>execution.take(signalName);</strong></span> + } +}</pre><p>The <code class="literal">execute</code>-method calls + <code class="literal">execution.waitForSignal()</code>. The invocation of + <code class="literal">execution.waitForSignal()</code> will bring the process execution + into a wait state until an external trigger is given. + </p><p><code class="literal">signal</code>-method takes the transition with + the signal parameter as the transition name. So when an execution receives an + external trigger, the signal name is interpreted as the name of an outgoing + transition and the execution will be propagated over that transition. + </p><p>Here's the same simple process that has a transition from a to b. This + time, the behaviour of the two nodes will be WaitState's. + </p><div class="figure"><a id="process.diagram"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/process.ab.png" align="middle" alt="The external activity example process"/></div></div><p class="title"><b>Figure 4.2. The external activity example process</b></p></div><br class="figure-break"/><pre class="programlisting">ClientProcessDefinition processDefinition = ProcessFactory.build() + <span class="bold"><strong>.node("a").initial().behaviour(new WaitState())</strong></span> + .transition().to("b") + <span class="bold"><strong>.node("b").behaviour(new WaitState())</strong></span> +.done();</pre><p>Let's start a new process instance for this process definition:</p><pre class="programlisting">ClientExecution execution = processDefinition.startProcessInstance();</pre><p>Starting this process will execute the <code class="literal">WaitState</code> activity + in node <code class="literal">a</code>. <code class="literal">WaitState.execute</code> will invoke + <code class="literal">ActivityExecution.waitForSignal</code>. So when the + <code class="literal">processDefinition.startProcessInstance()</code> returns, the execution + will still be positioned in node a. + </p><pre class="programlisting">assertEquals("a", execution.getNodeName());</pre><p>Then we provide the external trigger by calling the <code class="literal">signal</code> + method. + </p><pre class="programlisting">execution.signal();</pre><p>The <code class="literal">execution.signal()</code> will delegate to the activity + of the current node. So in this case that is the <code class="literal">WaitState</code> + activity in node <code class="literal">a</code>. The <code class="literal">WaitState.signal</code> + will invoke the <code class="literal">ActivityExecution.take(String transitionName)</code>. + Since we didn't supply a signalName, the first transition with name <code class="literal">null</code> + will be taken. The only transition we specified out of node <code class="literal">a</code> + didn't get a name so that one will be taken. And that transition points to node + <code class="literal">b</code>. When the execution arrives in node <code class="literal">b</code>, + the <code class="literal">WaitState</code> in node <code class="literal">b</code> is executed. + Similar as we saw above, the execution will wait in node <code class="literal">b</code> + and this time the <code class="literal">signal</code> method will return, leaving the + execution positioned in node <code class="literal">b</code>. + </p><pre class="programlisting">assertEquals("b", execution.getNodeName());</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="basicprocessexecution"/>4.5. Basic process execution</h2></div></div></div><p>In this next example, we'll combine automatic activities and wait states. + This example builds upon the loan approval process with the <code class="literal">WaitState</code> + and <code class="literal">Display</code> activities that we've just created. Graphically, + the loan process looks like this: + </p><div class="figure"><a id="basicprocessexecution.loan.process"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/process.loan.png" align="middle" alt="The loan process"/></div></div><p class="title"><b>Figure 4.3. The loan process</b></p></div><br class="figure-break"/><p>Building process graphs in Java code can be tedious because you have to keep track of all the + references in local variables. To resolve that, the Process Virtual Machine comes with a + ProcessFactory. The ProcessFactory is a kind of domain specific language (DSL) that is embedded + in Java and eases the construction of process graphs. This pattern is also known as + a <a xmlns:xlink="http://www.w3.org/1999/xlink" href="http://martinfowler.com/bliki/FluentInterface.html">fl... + interface</a>. + </p><pre class="programlisting">ClientProcessDefinition processDefinition = ProcessFactory.build("loan") + .node(<span class="bold"><strong>"submit loan request"</strong></span>).initial().behaviour(new Display("loan request submitted")) + .transition().to("evaluate") + <span class="bold"><strong>.node("evaluate").behaviour(new WaitState())</strong></span> + .transition("approve").to("wire money") + .transition("reject").to("end") + <span class="bold"><strong>.node("wire money").behaviour(new Display("wire the money"))</strong></span> + .transition().to("archive") + <span class="bold"><strong>.node("archive").behaviour(new WaitState())</strong></span> + .transition().to("end") + <span class="bold"><strong>.node("end").behaviour(new WaitState())</strong></span> +.done();</pre><p>For more details about the ProcessFactory, see <a xmlns:xlink="http://www.w3.org/1999/xlink" href="../../api/org/jbpm/pvm/package-summary.html">the + api docs</a>. An alternative for + the ProcessFactory would be to create an XML language and an XML parser for expressing + processes. The XML parser can then instantiate the classes of package + <code class="literal">org.jbpm.pvm.internal.model</code> directly. That approach is typically taken by + process languages. + </p><p>The initial node <code class="literal">submit loan request</code> and the node + <code class="literal">wire the money</code> are automatic nodes. In this example, + the <code class="literal">Display</code> implementation of node + <code class="literal">wire the money</code> uses the Java API's to just print a + message to the console. But the witty reader can imagine an alternative + <code class="literal">Activity</code> implementation that uses the Java API of a payment + processing library to make a real automatic payment. + </p><p>A new execution for the process above can be started like this + </p><pre class="programlisting">ClientExecution execution = processDefinition.startProcessInstance();</pre><p>When the <code class="literal">startExecution</code>-method returns, the node + <code class="literal">submit loan request</code> will be executed and the execution will be + positioned in the node <code class="literal">evaluate</code>. + </p><div class="figure"><a id="execution.loan.evaluate"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/execution.loan.evaluate.png" align="middle" alt="Execution positioned in the 'evaluate' node"/></div></div><p class="title"><b>Figure 4.4. Execution positioned in the 'evaluate' node</b></p></div><br class="figure-break"/><p>Now, the execution is at an interesting point. There are two transitions out of + the state <code class="literal">evaluate</code>. One transition is called <code class="literal">approve</code> + and one transition is called <code class="literal">reject</code>. As we explained above, the WaitState + implementation will take the transition that corresponds to the signal that is given. + Let's feed in the 'approve' signal like this: + </p><pre class="programlisting">execution.signal("approve");</pre><p>The <code class="literal">approve</code> signal will cause the execution to take the <code class="literal">approve</code> + transition and it will arrive in the node <code class="literal">wire money</code>. + </p><p>In node <code class="literal">wire money</code>, the message will be printed to the console. + Since, the <code class="literal">Display</code> activity didn't invoke the + <code class="literal">execution.waitForSignal()</code>, nor any of the other execution propagation + methods, the implicit proceed behaviour will just make the execution continue + over the outgoing transition to node <code class="literal">archive</code>, which is again + a <code class="literal">WaitState</code>. + </p><div class="figure"><a id="execution.loan.archive"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/execution.loan.archive.png" align="middle" alt="Execution positioned in 'archive' node"/></div></div><p class="title"><b>Figure 4.5. Execution positioned in 'archive' node</b></p></div><br class="figure-break"/><p>So only when the <code class="literal">archive</code> wait state is reached, + the <code class="literal">signal("approve")</code> returns. + </p><p>Another signal like this:</p><pre class="programlisting">execution.signal("approve");</pre><p>will bring the execution eventually in the end state.</p><div class="figure"><a id="execution.loan.end"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/execution.loan.end.png" align="middle" alt="Execution positioned in the 'end' node"/></div></div><p class="title"><b>Figure 4.6. Execution positioned in the 'end' node</b></p></div><br class="figure-break"/></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="events"/>4.6. Events</h2></div></div></div><p>Events are points in the process definition to which a list of + <code class="literal">EventListener</code>s can be subscribed. + </p><pre class="programlisting">public interface EventListener extends Serializable { + + void notify(EventListenerExecution execution) throws Exception; + +}</pre><p>The motivation for events is to allow for + developers to add programming logic to a process without changing the process diagram. + This is a very valuable instrument in facilitating the collaboration between business analysts + and developers. Business analysts + are responsible for expressing the requirements. When they use a process graph to document + those requirements, developers can take this diagram and make it executable. Events can + be a very handy to insert technical details into a process (like e.g. some database insert) + in which the business analyst is not interested. + </p><p>Most common events are fired by the execution automatically: + </p><p><span class="bold"><strong>WARNING: the following event names will be + subject to change in the next release: see + <a xmlns:xlink="http://www.w3.org/1999/xlink" href="https://jira.jboss.org/jira/browse/JBPM-1753">JBPM-175... + </p><div class="itemizedlist"><ul><li><code class="literal"><span class="bold"><strong>Event.TRANSITION_TAKE</strong></span> = "transition-take"</code> : + fired on transitions when transitions are taken. + </li><li><code class="literal"><span class="bold"><strong>Event.NODE_BEGIN</strong></span> = "node-begin"</code> : fired on the node + when execution enters that node. This happens when execution takes a transition + to that node, when a child node is being executed with <code class="literal">execution.execute(Node)</code> + or when a transition is taken from a node outside that node to a contained node. + The latter refers to super states in state machines. + </li><li><code class="literal"><span class="bold"><strong>Event.NODE_END</strong></span> = "node-end"</code> : fired on the node + when a transition is taken out of that node or when a child node execution is + finished and the execution is propagated to the parent node. + </li><li><code class="literal"><span class="bold"><strong>Event.PROCESS_BEGIN</strong></span> = "process-begin"</code> : fired on a process + when a new process is started. + </li><li><code class="literal"><span class="bold"><strong>Event.PROCESS_END</strong></span> = "process-end"</code> : fired on a process + when a new process is ended. This might include a executions that are ended + with a cancelled or error state. + </li></ul></div><p>Events are identified by the combination of a process element + and an event name. Users and process languages can also fire events + programmatically with the fire method on the Execution: + </p><pre class="programlisting">public interface Execution extends Serializable { + ... + void fire(String eventName, ProcessElement eventSource); + ... +}</pre><p>A list of <code class="literal">EventListeners</code> can be associated to an + event. But event listeners can not influence the control flow of the execution since + they are merely listeners to an execution which is already in progress. This is different from + activities that serve as the behaviour for nodes. Node behaviour activities are responsible + for propagating the execution. + </p><p>We'll create a <code class="literal">PrintLn</code> event listener which is + very similar to the <code class="literal">Display</code> activity from above. + </p><pre class="programlisting">public class PrintLn implements EventListener { + + String message; + + public PrintLn(String message) { + this.message = message; + } + + public void notify(EventListenerExecution execution) throws Exception { + System.out.println("message"); + } +}</pre><p>Several <code class="literal">PrintLn</code> listeners will be subscribed to events in + the process.</p><div class="figure"><a id="action.process"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/process.ab.png" align="middle" alt="The PrintLn listener process"/></div></div><p class="title"><b>Figure 4.7. The PrintLn listener process</b></p></div><br class="figure-break"/><pre class="programlisting">ClientProcessDefinition processDefinition = ProcessFactory.build() + .node("a").initial().behaviour(new AutomaticActivity()) + <span class="bold"><strong>.event("node-end") + .listener(new PrintLn("leaving a")) + .listener(new PrintLn("second message while leaving a"))</strong></span> + .transition().to("b") + <span class="bold"><strong>.listener(new PrintLn("taking transition"))</strong></span> + .node("b").behaviour(new WaitState()) + .event("node-begin") + <span class="bold"><strong>.listener(new PrintLn("entering b"))</strong></span> +.done();</pre><p>The first event shows how to register multiple listeners to the same + event. They will be notified in the order as they are specified. + </p><p>Then, on the transition, there is only one type of event. So in that case, + the event type must not be specified and the listeners can be added directly on + the transition. + </p><p>A listeners will be called each time an execution fires the event to + which the listener is subscribed. The execution will be provided in the activity + interface as a parameter and can be used by listeners except for the methods that + control the propagation of execution. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e1133"/>4.7. Event propagation</h2></div></div></div><p>Events are by default propagated to enclosing process elements. The motivation + is to allow for listeners on process definitions or composite nodes that get executed + for all events that occur within that process element. For example this feature + allows to register an event listener on a process definition or a composite node on + <code class="literal">node-end</code> events. Such action will be executed if that node is + left. And if that event listener is registered on a composite node, it will also be executed + for all nodes that are left within that composite node. + </p><p>To show this clearly, we'll create a <code class="literal">DisplaySource</code> event listener + that will print the message <code class="literal">leaving</code> and the source of the event + to the console. + </p><pre class="programlisting">public class <span class="bold"><strong>DisplaySource</strong></span> implements EventListener { + + public void execute(EventListenerExecution execution) { + <span class="bold"><strong>System.out.println("leaving "+execution.getEventSource());</strong></span> + } +}</pre><p>Note that the purpose of event listeners is not to be visible, that's why the event listener + itself should not be displayed in the diagram. A <code class="literal">DisplaySource</code> event listener + will be added as a listener to the event <code class="literal">node-end</code> on the composite node. + </p><p>The next process shows how the <code class="literal">DisplaySource</code> event listener is registered + as a listener to to the 'node-end' event on the <code class="literal">composite</code> node:</p><div class="figure"><a id="process.propagate"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/process.propagate.png" align="middle" alt="A process with an invisible event listener on a node-end event on a composite node."/></div></div><p class="title"><b>Figure 4.8. A process with an invisible event listener on a node-end event on a composite node.</b></p></div><br class="figure-break"/><pre class="programlisting">ClientProcessDefinition processDefinition = ProcessFactory.build("propagate") + <span class="bold"><strong>.compositeNode("composite") + .event(Event.NODE_END) + .listener(new DisplaySource())</strong></span> + .node("a").initial().behaviour(new WaitState()) + .transition().to("b") + .node("b").behaviour(new WaitState()) + .transition().to("c") + .compositeEnd() + .node("c").behaviour(new WaitState()) +.done();</pre><p>Next we'll start an execution.</p><pre class="programlisting">ClientExecution execution = processDefinition.startProcessInstance();</pre><p>After starting a new execution, the execution will be in node <code class="literal">a</code> as + that is the initial node. No nodes have been left so no message is logged. Next a signal + will be given to the execution, causing it to take the transition from <code class="literal">a</code> + to <code class="literal">b</code>. + </p><pre class="programlisting">execution.signal();</pre><p>When the signal method returns, the execution will have taken the transition and + the <code class="literal">node-end</code> event will be fired on node <code class="literal">a</code>. That + event will be propagated to the + composite node and to the process definition. Since our <code class="literal">DisplaySource</code> + event listener is placed + on the <code class="literal">composite</code> node, it will receive the event and print the following + message on the console: + </p><pre class="programlisting">leaving node(a)</pre><p>Another</p><pre class="programlisting">execution.signal();</pre><p>will take the transition from b to c. That will fire two node-leave events. One on + node b and one on node composite. So the following lines will be appended to the console + output:</p><pre class="programlisting">leaving node(b) +leaving node(composite)</pre><p>Event propagation is build on the hierarchical composition structure of the process + definition. The top level element is always the process definition. The process + definition contains a list of nodes. Each node can be a leaf node or it can be a + composite node, which means that it contains a list of nested nodes. Nested nodes + can be used for e.g. super states or composite activities in nested process languages like BPEL. + </p><p>So the even model also works similarly for composite nodes as it did for the process + definition above. Suppose that 'Phase one' models + a super state as in state machines. Then event propagation allows to subscribe to all events + within that super state. The idea is that the hierarchical composition corresponds to + diagram representation. If an element 'e' is drawn inside another element 'p', then p + is the parent of e. A process definition has a set of top level nodes. Every node can have + a set of nested nodes. The parent of a transition is considered as the first common + parent for it's source and destination. + </p><p>If an event listener is not interested in propagated events, propagation can be disabled + with <code class="literal">propagationDisabled()</code> while building the process with the + <code class="literal">ProcessFactory</code>. The next process is the same process + as above except that propagated events will be disabled on the event listener. The graph diagram + remains the same. + </p><div class="figure"><a id="process.propagate.propagation.disabled"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/process.propagate.png" align="middle" alt="A process with an event listener to 'node-end' events with propagation disabled."/></div></div><p class="title"><b>Figure 4.9. A process with an event listener to 'node-end' events with propagation disabled.</b></p></div><br class="figure-break"/><p>Building the process with the process factory: + </p><pre class="programlisting">ClientProcessDefinition processDefinition = ProcessFactory.build("propagate") + .compositeNode("composite") + .event(Event.NODE_END) + .listener(new DisplaySource()) + <span class="bold"><strong>.propagationDisabled()</strong></span> + .node("a").initial().behaviour(new WaitState()) + .transition().to("b") + .node("b").behaviour(new WaitState()) + .transition().to("c") + .compositeEnd() + .node("c").behaviour(new WaitState()) +.done();</pre><p>So when the first signal is given for this process, again the <code class="literal">node-end</code> + event will be fired on node <code class="literal">a</code>, but now the event listener on the composite + node will not be executed cause + propagated events have been disabled. Disabling propagation is a property on the individual + event listener and doesn't influence the other listeners. The event will always be fired and + propagated over the whole parent hierarchy. + </p><pre class="programlisting">ClientExecution execution = processDefinition.startProcessInstance();</pre><p>The first signal will take the process from <code class="literal">a</code> to + <code class="literal">b</code>. No messages will be printed to the console. + </p><pre class="programlisting">execution.signal();</pre><p>Next, the second signal will take the transition from b to c. + </p><pre class="programlisting">execution.signal()</pre><p>Again two <code class="literal">node-end</code> + events are fired just like above on nodes <code class="literal">b</code> and <code class="literal">composite</code> + respectively. The first event + is the <code class="literal">node-end</code> event on node <code class="literal">b</code>. That will be propagated + to the <code class="literal">composite</code> node. So the event + listener will not be executed for this event cause it has propagation disabled. But the + event listener will be executed for the <code class="literal">node-end</code> event on the + <code class="literal">composite</code> node. That is not + propagated, but fired directly on the <code class="literal">composite</code> node. So the event + listener will now be executed + only once for the composite node as shown in the following console output: + </p><pre class="programlisting">leaving node(composite)</pre></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="processanatomy"/>Chapter 5. Process anatomy</h2></div></div></div><p>Above we already touched briefly on the two main process constructs: + Nodes, transitions and node composition. This chapter explores in full + all the possibilities of the process definition structures. + </p><p>There are basically two forms of process languages: graph based and composite + process languages. First of all, the process supports both. Even graph based execution + and node composition can be used in combination to implement something like UML super states. + Furthermore, automatic functional activities can be implemented so that they can be + used with transitions as well as with node composition. + </p><div class="figure"><a id="process.anatomy"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/process.anatomy.classes.png" align="middle" alt="UML class diagram of the logical process structure"/></div></div><p class="title"><b>Figure 5.1. UML class diagram of the logical process structure</b></p></div><br class="figure-break"/><p>Next we'll show a series of example diagram structures that can be formed + with the PVM process model. + </p><div class="figure"><a id="transition"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/transition.png" align="middle" alt="Any two nodes can be connected with a transition."/></div></div><p class="title"><b>Figure 5.2. Any two nodes can be connected with a transition.</b></p></div><br class="figure-break"/><div class="figure"><a id="self.transition"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/self.transition.png" align="middle" alt="A self transition."/></div></div><p class="title"><b>Figure 5.3. A self transition.</b></p></div><br class="figure-break"/><div class="figure"><a id="composite.node"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/composite.node.png" align="middle" alt="Composite node is a list of nested nodes."/></div></div><p class="title"><b>Figure 5.4. Composite node is a list of nested nodes.</b></p></div><br class="figure-bre! ak"/><div class="figure"><a id="transition.into.composite"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/transition.into.composite.png" align="middle" alt="Transition to a node inside a composite."/></div></div><p class="title"><b>Figure 5.5. Transition to a node inside a composite.</b></p></div><br class="figure-break"/><div class="figure"><a id="transition.out.of.composite"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/transition.out.of.composite.png" align="middle" alt="Transition from a node inside a composite to a node outside the composite."/></div></div><p class="title"><b>Figure 5.6. Transition from a node inside a composite to a node outside the composite.</b></p></div><br class="figure-break"/><div class="figure"><a id="transition.inheritence"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/transition.inheritence.png" align="middle" alt="Tra! nsition of composite nodes are inherited. The node inside can take the transition of the composite node."/></div></div><p class="title"><b>Figure 5.7. Transition of composite nodes are inherited. The node inside can take the transition of the composite node.</b></p></div><br class="figure-break"/><div class="figure"><a id="transition.to.outer"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/transition.to.outer.png" align="middle" alt="Transition from a node to an outer composite."/></div></div><p class="title"><b>Figure 5.8. Transition from a node to an outer composite.</b></p></div><br class="figure-break"/><div class="figure"><a id="transition.to.inner"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/transition.to.inner.png" align="middle" alt="Transition from a composite node to an inner composed node."/></div></div><p class="title"><b>Figure 5.9. Transition from a composite node to an inner composed node.</b></p></div><br class="figure-break"/><div class="! figure"><a id="initial.in.composite"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/initial.in.composite.png" align="middle" alt="An initial node inside a composite node."/></div></div><p class="title"><b>Figure 5.10. An initial node inside a composite node.</b></p></div><br class="figure-break"/></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="advancedgraphexecution"/>Chapter 6. Advanced graph execution</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#d0e1378">6.1. Loops</a></span></dt><dt><span class="section"><a href="#d0e1386">6.2. Sub processes</a></span></dt><dt><span class="section"><a href="#implicitproceedbehaviour">6.3. Implicit proceed behaviour</a></span></dt><dt><span class="section"><a href="#functionalactivities">6.4. Functional activities</a></span></dt><dt><span class="section"><a href="#executionandthreads">6.5. Execution and threads</a><! /span></dt><dt><span class="section"><a href="#d0e1655">6.6. Process c oncurrency</a></span></dt><dt><span class="section"><a href="#d0e1695">6.7. Exception handlers</a></span></dt><dt><span class="section"><a href="#d0e1725">6.8. Process modifications</a></span></dt><dt><span class="section"><a href="#d0e1731">6.9. Locking and execution state</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e1378"/>6.1. Loops</h2></div></div></div><p>Activities can implement loops based on transitions or on node composition. + Loops can contain wait states. + </p><p>To support high numbers of automatic loop executions, the Process Virtual Machine + tranformed the propagation of execution from tail recursion to a while loop. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e1386"/>6.2. Sub processes</h2></div></div></div><p>TODO: sub processes</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="implicitproceedbehaviour"/>6.3. Implicit proceed behaviour</h2></div></div></div><p>When an <code class="literal">Activity</code> is used as node behaviour, it can + explicitely propagate the execution with following methods: + </p><div class="itemizedlist"><ul><li><code class="literal">waitForSignal()</code></li><li><code class="literal">take(Transition)</code></li><li><code class="literal">end(*)</code></li><li><code class="literal">execute(Node)</code></li><li><code class="literal">createExecution(*)</code></li></ul></div><p>When <code class="literal">Activity</code> implementations used for node 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. + </p><p>The implicit proceed behaviour is defined as follows:</p><div class="itemizedlist"><ul><li>If the current node has a default outgoing transition, take it.</li><li>If the current node has a parent node, move back to the parent node.</li><li>Otherwise, end this execution.</li></ul></div><p>Process languages can overwrite the implicit proceed behaviour + by overriding the <code class="literal">proceed</code> method in + <code class="literal">ExecutionImpl</code>. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="functionalactivities"/>6.4. Functional activities</h2></div></div></div><p>Activities 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: + </p><pre class="programlisting">public class FunctionalActivity implements Activity, EventListener { + public void execute(ActivityExecution execution) { + perform(execution); + } + public void notify(EventListenerExecution execution) { + perform(execution); + } + void perform(OpenExecution execution) { + ...do functional work... + } + }</pre><p>The <code class="literal">perform</code> method takes an <code class="literal">OpenExecution</code>, + which is the supertype of both <code class="literal">ActivityExecution</code> and + <code class="literal">EventListenerExecution</code>. <code class="literal">OpenExecution</code> + does not allow any of the specific purpose methods, but still + the current state and the process definition can be inspected as well + as the variables, which contain the context information for the process + execution. + </p><p>None of these methods actually invoke execution propagation methods. + So after the perform method is completed, the execution will + <a href="#implicitproceedbehaviour" title="6.3. Implicit proceed behaviour">proceed in the default way</a>. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="executionandthreads"/>6.5. Execution and threads</h2></div></div></div><p>This section explains how the Process Virtual Machine boroughs the thread + from the client to bring an execution from one wait state to another. + </p><p>When a client invokes a method (like e.g. the signal method) on an execution, + by default, the Process Virtual Machine will use that thread to progress the execution + until it reached a wait state. Once the next wait state has been reached, the + method returns and the client gets the thread back. This is the default way + for the Process Virtual Machine to operate. Two more levels of asynchonous + execution complement this default behaviour: + <a href="#asynchronouscontinuations" title="Chapter 9. Asynchronous continuations">Asynchronous continuations</a> + and the <a href="#architecture" title="Chapter 3. Architecture">asynchronous command service</a>. + </p><p>The next process will show the basics concretely. It has three wait states + and four automatic nodes. + </p><div class="figure"><a id="process.automatic"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/process.automatic.png" align="middle" alt="Process with many sequential automatic activities."/></div></div><p class="title"><b>Figure 6.1. Process with many sequential automatic activities.</b></p></div><br class="figure-break"/><p>Here's how to build the process:</p><pre class="programlisting">ClientProcessDefinition processDefinition = ProcessFactory.build("automatic") + .<span class="bold"><strong>node("wait 1").initial()</strong></span>.behaviour(new <span class="bold"><strong>WaitState</strong></span>()) + .transition().to("automatic 1") + .<span class="bold"><strong>node("automatic 1")</strong></span>.behaviour(new <span class="bold"><strong>Display("one")</strong></span>) + .transition().to("wait 2") + .<span class="bold"><strong>node("wait 2")</strong></span>.behaviour(new <span class="bold"><strong>WaitState</strong></span>()) + .transition().to("automatic 2") + .<span class="bold"><strong>node("automatic 2")</strong></span>.behaviour(new <span class="bold"><strong>Display("two")</strong></span>) + .transition().to("automatic 3") + .<span class="bold"><strong>node("automatic 3")</strong></span>.behaviour(new <span class="bold"><strong>Display("three")</strong></span>) + .transition().to("automatic 4") + .<span class="bold"><strong>node("automatic 4")</strong></span>.behaviour(new <span class="bold"><strong>Display("four")</strong></span>) + .transition().to("wait 3") + .<span class="bold"><strong>node("wait 3")</strong></span>.behaviour(new <span class="bold"><strong>WaitState</strong></span>()) +.done();</pre><p>Let's walk you through one execution of this process. + </p><pre class="programlisting">ClientExecution execution = processDefinition.startProcessInstance();</pre><p>Starting a new execution means that the initial node is executed. So if an automatic + activity is the initial node, this means that immediately the first unnamed outgoing transition + is taken. This happens all inside of the invocation of <code class="literal">startProcessInstance</code>. + </p><p>In this case however, the initial node is a wait state. So + the method <code class="literal">startProcessInstance</code> returns immediately and the execution will be + positioned in the initial node 'wait 1'. + </p><div class="figure"><a id="execution.automatic.wait1"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/execution.automatic.wait1.png" align="middle" alt="A new execution will be positioned in 'wait 1'."/></div></div><p class="title"><b>Figure 6.2. A new execution will be positioned in 'wait 1'.</b></p></div><br class="figure-break"/><p>Then an external trigger is given with the signal method.</p><pre class="programlisting">execution.signal();</pre><p>As explained above when <a href="#externalactivityexample" title="4.4. ExternalActivity example">introducing the WaitState</a>, + that signal will cause the default transition to be taken. The + transition will move the execution to node <code class="literal">automatic 1</code> and execute it. + The execute method of the <code class="literal">Display</code> activity in <code class="literal">automatic 1</code> + print a line to the console and it will <span class="bold"><strong>not</strong></span> call + <code class="literal">execution.waitForSignal()</code>. Therefore, the execution will proceed by + taking the default transition out of <code class="literal">automatic 1</code>. At this stage, the + signal method is still blocking. Another way to think about it is that the execution + methods like <code class="literal">signal</code> will use the thread of the client to interpret + the process definition until a wait state is reached. + </p><p>Then the execution arrives in <code class="literal">wait 2</code> and executes + the <code class="literal">WaitState</code> activity. That method will invoke + the <code class="literal">execution.waitForSignal()</code>, which will cause the signal method + to return. That is when the thread is given back to the client that invoked the + <code class="literal">signal</code> method. + </p><p>So when the signal method returns, the execution is positioned in <code class="literal">wait 2</code>.</p><div class="figure"><a id="execution.automatic.wait2"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/execution.automatic.wait2.png" align="middle" alt="One signal brought the execution from 'initial' to 'wait 2'."/></div></div><p class="title"><b>Figure 6.3. One signal brought the execution from 'initial' to 'wait 2'.</b></p></div><br class="figure-break"/><p>Then the execution is now waiting for an external trigger just as an object + (more precisely an object graph) in memory until the next external trigger is given + with the signal method. + </p><pre class="programlisting">execution.signal();</pre><p>This second invocation of signal will take the execution similarly all the + way to <code class="literal">wait 3</code> before it returns. + </p><div class="figure"><a id="automatic.wait3"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/ch04.automatic.wait3.png" align="middle" alt="The second signal brought the execution all the way to 'wait 3'."/></div></div><p class="title"><b>Figure 6.4. The second signal brought the execution all the way to 'wait 3'.</b></p></div><br class="figure-break"/><p>The benefits of using this paradigm is that the same process definition + can be executed in <a href="#">client execution mode</a> + (in-memory without persistence) as well as in <a href="#persistentexecutionmode" title="2.2. Persistent execution mode"> + persistent execution mode</a>, depending on the application and on the environment. + </p><p>When executing a process in persistent mode, this is how you typically want + to bind that process execution to transactions of the database: + </p><div class="figure"><a id="transactions.png"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/transactions.png" align="middle" alt="Transactions over time in persistent execution mode."/></div></div><p class="title"><b>Figure 6.5. Transactions over time in persistent execution mode.</b></p></div><br class="figure-break"/><p>In most situations, the computational work that needs to be done as part of + the process after an external trigger (the red pieces) is pretty minimal. Typically + transactions combining the process execution and processing the request from the + UI takes typically less then a second. Whereas the wait state in business processes + typically can span for hours, days or even years. The clue is to clearly distinct + when a wait state starts so that only the computational work done before the start + of that wait state should be included in the transaction. + </p><p>Think of + it this way: "When an approval arrives, what are all the automated processing that + needs to be done before the process system needs to wait for another external + trigger?" Unless pdf's need to be generated or mass emails need to be send, + the amount of time that this takes is usually neglectable. That is why in the + default persistent execution mode, the process work is executed in the thread + of the client. + </p><p>This reasoning even holds in case of concurrent paths of execution. + When a single path of execution splits into concurrent paths of execution, + the process overhead of calculating that is neglectable. So that is why it + makes sense for a fork or split activity implementation that targets persistent + execution mode to spawn the concurrent paths sequentially in the same thread. + Basically it's all just computational work as part of the same transaction. + This can only be done because the fork/split knows that each concurrent path + of execution will return whenever a wait state is encountered. + </p><p>Since this is a difficult concept to grasp, I'll explain it again with other + words. Look at it from the overhead that is produced by the process execution + itself in persistent execution mode. If in a transaction, an execution is given + an external trigger and that causes the execution to split into multiple concurrent + paths of execution. Then the process overhead of calculating this is neglectable. + Also the overhead of the generated SQL is neglectable. And since all the work done + in the concurrent branches must be done inside that single transaction, there is + typically no point in having fork/split implementations spawn the concurrent + paths of execution in multiple threads. + </p><p>To make executable processes, developers need to know exactly what the automatic activities + are, what the wait states are and which threads will be allocated to the process execution. + For business analysts that draw the analysis process, things are a bit simpler. For the + activities they draw, they usually know whether it's a human or a system that is responsible. + But they typically don't not how this translates to threads and transactions. + </p><p>So for the developer, the first job is to analyse what needs to be executed + within the thread of control of the process and what is outside. Looking for the external + triggers can be a good start to find the wait states in a process, just like verbs and nouns + can be the rule of thumb in building UML class diagrams. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e1655"/>6.6. Process concurrency</h2></div></div></div><p>To model process concurrency, there is a parent-child tree structure on the + execution. The idea is that the main path of execution is the root of that tree. + The main path of execution is also called the process instance. It is the execution + that is created when starting or creating a new process instance for a given + process definition. + </p><p>Now, because the main path of execution is the same object as the + process instance, this keeps the usage simple in case of simple processes + without concurrency. + </p><div class="figure"><a id="execution.structure"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/class.diagram.process.execution.png" align="middle" alt="UML class diagram of the basic execution structure"/></div></div><p class="title"><b>Figure 6.6. UML class diagram of the basic execution structure</b></p></div><br class="figure-break"/><p>To establish multiple concurrent paths of execution, activity implementations + like a fork or split can create child executions with method + <code class="literal">ActivityExecution.createExecution</code>. Activity implementations + like join or merge can stop these concurrent paths of execution by calling + method <code class="literal">stop</code> on the concurrent execution. + </p><p>Only leaf executions can be active. Non-leave executions should be + inactive. This tree structure of executions doesn't enforce a particular type of + concurrency or join behaviour. It's up to the forks or and-splits and to the joins + or and-merges to use the execution tree structure in any way they want to define + the wanted concurrency behaviour. Here you see an example + of concurrent executions. + </p><div class="figure"><a id="concurrency"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/execution.concurrency.png" align="middle" alt="Concurrent paths of execution"/></div></div><p class="title"><b>Figure 6.7. Concurrent paths of execution</b></p></div><br class="figure-break"/><p>There is a billing and a shipping path of execution. In this case, the + flat bar nodes represent nodes that fork and join. The execution shows a three + executions. The main path of execution is inactive (represented as gray) and the + billing and shipping paths of execution are active and point to the node + <code class="literal">bill</code> and <code class="literal">ship</code> respectively. + </p><p>It's up to the node behaviour implementations how they want to use this + execution structure. Suppose that multiple tasks have to be completed before the + execution is to proceed. The node behaviour can spawn a series of child executions + for this. Or alternatively, the task component could support task groups that + are associated to one single execution. In that case, the task component becomes + responsible for synchronizing the tasks, thereby moving this responsibility + outside the scope of the execution tree structure. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e1695"/>6.7. Exception handlers</h2></div></div></div><p>In all the code that is associated to a process + like <code class="literal">Activity</code>s, <code class="literal">EventListeners</code> and + <code class="literal">Condition</code>s, it's possible to associate exception handlers. This + can be thought of as including try-catch blocks in + the method implementations of those implementations. But in order to build more reusable building + blocks for both the delegation classes and the exception handling logic, exception handlers are + added to the core process model. + </p><p>An exception handler can be associated to any process element. When an exception + occurs in a delegation class, a matching exception handler will be searched for. If + such an exception handler is found, it will get a chance to handle the exception. + </p><p>If an exception handler completes without problems, then the exception is considered + handled and the execution resumes right after the delegation code that was called. For example, + a transition has three actions and the second action throws an exception that is handled + by an exception handler, then + </p><p>Writing automatic activities that are exception handler aware is easy. The + default is to proceed anyway. No method needs to be called on the execution. So + if an automatic activity throws an exception that is handled by an exception handler, + the execution will just proceed after that activity. It becomes a big more difficult + for control flow activities. They might have to include try-finally blocks to + invoke the proper methods on the execution before an exception handler gets a + chance to handle the exception. For example, if an activity is a wait state and + an exception occurs, then there is a risk that the thread jumps over the + invocation of <code class="literal">execution.waitForSignal()</code>, causing the execution + to proceed after the activity. + </p><p>TODO: exceptionhandler.isRethrowMasked</p><p>TODO: transactional exception handlers</p><p>TODO: we never catch errors</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e1725"/>6.8. Process modifications</h2></div></div></div><p>TODO: process modifications</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e1731"/>6.9. Locking and execution state</h2></div></div></div><p>The state of an execution is either active or locked. An active + execution is either executing or waiting for an external trigger. If an + execution is not in <code class="literal">STATE_ACTIVE</code>, then it is locked. + A locked execution is read only and cannot receive any external triggers. + </p><p>When a new execution is created, it is in STATE_ACTIVE. To change + the state to a locked state, use lock(String). Some STATE_* constants + are provided that represent the most commonly used locked states. But + the state '...' in the picture indicates that any string can be provided + as the state in the lock method. + </p><div class="figure"><a id="execution.states"/><div class="figure-contents"><div class="mediaobject" align="center"><img src="images/ch04.execution.states.png" align="middle" alt="States of an execution"/></div></div><p class="title"><b>Figure 6.8. States of an execution</b></p></div><br class="figure-break"/><p>If an execution is locked, methods that change the execution will + throw a PvmException and the message will reference the actual locking state. + Firing events, updating variables, updating priority and adding comments + are not considered to change an execution. Also creation and removal of child + executions are unchecked, which means that those methods can be invoked by + external API clients and node behaviour methods, even while the execution + is in a locked state. + </p><p>Make sure that comparisons between getState() and the STATE_* constants + are done with .equals and not with '==' because if executions are loaded + from persistent storage, a new string is created instead of the constants. + </p><p>An execution implementation will be locked: + </p><div class="itemizedlist"><ul><li>When it is ended</li><li>When it is suspended</li><li>During asynchronous continuations</li></ul></div><p>Furthermore, locking can be used by Activity implementations to make + executions read only during wait states hen responsibility for the execution is + transferred to an external entity such as: + </p><div class="itemizedlist"><ul><li>A human task</li><li>A service invocation</li><li>A wait state that ends when a scanner detects that a file appears</li></ul></div><p>In these situations the strategy is that the external entity should get + full control over the execution because it wants to control what is allowed + and what not. To get that control, they lock the execution so that all interactions + have to go through the external entity. + </p><p>One of the main reasons to create external entities is that they can live + on after the execution has already proceeded. For example, in case + of a service invocation, a timer could cause the execution to take the timeout transition. + When the response arrives after the timeout, the service invocation entity should + make sure it doesn't signal the execution. So the service invocation can be + seen as a node instance (aka activity instance) and is unique for every execution + of the node. + </p><p>External entities themselves are responsible for managing the execution + lock. If the timers and client applications are consequent in addressing the + external entities instead of the execution directly, then locking is in theory + unnecessary. It's up to the node behaviour implementations whether they want + to take the overhead of locking and unlocking. + </p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="variables"/>Chapter 7. Variables</h2></div></div></div><p>TODO</p></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="timers"/>Chapter 8. Timers</h2></div></div></div><p>TODO</p></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="asynchronouscontinuations"/>Chapter 9. Asynchronous continuations</h2></div></div></div><p>TODO</p></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="softwarelogging"/>Chapter 10. Software logging</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="#d0e1793">10.1. Configuration</a></span></dt><dt><span class="section"><a href="#d0e1812">10.2. Categories</a></span></dt><dt><span class="section"><a href="#d0e1825">10.3. JDK logging</a></span></dt><dt><span class="section"><a href="#! d0e1855">10.4. Debugging persistence</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e1793"/>10.1. Configuration</h2></div></div></div><p>PVM can use JDK logging (java.util.logging) or log4j. When the first message is + logged, PVM logging will make the selection with following procedure: + </p><div xmlns:rf="java:org.jboss.highlight.XhtmlRendererFactory" class="orderedlist"><ol><li>If a <code class="literal">logging.properties</code> resource is found + on the classpath (using the context classloader), then JDK logging will + be used and that file will be used to initialize the JDK logging. + </li><li>If log4j is found on the classpath, then log4j will be used. + The check for log4j will be done by checking availability of class + <code class="literal">org.apache.log4j.LogManager</code> with the context classloader. + </li><li>If none of the above, JDK logging will be used.</li></ol></div><p> + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e1812"/>10.2. Categories</h2></div></div></div><p>The PVM classes use their class name as the category for the logger. + </p><p>To have a basic understanding of what the PVM classes are doing, + turning on the <code class="literal">debug</code> level is great. Level + <code class="literal">trace</code> might be spitting out too much for that + purpose. + </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e1825"/>10.3. JDK logging</h2></div></div></div><p>In JDK logging, <code class="literal">debug</code>maps to <code class="literal">fine</code> + and <code class="literal">trace</code> maps to <code class="literal">finest</code>. + Level <code class="literal">finer</code> is not used. + </p><p><code class="literal">org.jbpm.pvm.internal.log.LogFormatter</code> is part of + the pvm library and it can create a nice one-line output for log messages. + It also has a neat feature that creates a unique indentation per thread. + To configure it, this is a typical <code class="literal">logging.properties</code> + </p><pre class="programlisting">handlers = java.util.logging.ConsoleHandler +java.util.logging.ConsoleHandler.level = FINEST +java.util.logging.ConsoleHandler.formatter = org.jbpm.pvm.internal.log.LogFormatter + +# For example, set the com.xyz.foo logger to only log SEVERE messages: +# com.xyz.foo.level = SEVERE + +.level = SEVERE +org.jbpm.level=FINE +org.jbpm.tx.level=FINE +org.jbpm.pvm.internal.wire.level=FINE</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="d0e1855"/>10.4. Debugging persistence</h2></div></div></div><p>When testing the persistence, following logging configurations can be + valuable. Category <code class="literal">org.hibernate.SQL</code> shows the SQL statement that is executed + and category <code class="literal">org.hibernate.type</code> shows the values of the parameters that are + set in the queries. + </p><pre class="programlisting">org.hibernate.SQL.level=FINEST +org.hibernate.type.level=FINEST</pre><p>And in case you get a failed batch as a cause in a hibernate exception, + you might want to set the batch size to 0 like this in the hibernate properties: + </p><pre class="programlisting">hibernate.jdbc.batch_size = 0</pre><p>Also in the hibernate properties, the following properties allow for + detailed logs of the SQL that hibernate spits out:</p><pre class="programlisting">hibernate.show_sql = true +hibernate.format_sql = true +hibernate.use_sql_comments = true</pre></div></div></div></body></html> \ No newline at end of file Added: jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/MANIFEST.MF =================================================================== --- jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/MANIFEST.MF (rev 0) +++ jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/MANIFEST.MF 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,6 @@ +Manifest-Version: 1.0 +Archiver-Version: Plexus Archiver +Created-By: Apache Maven +Built-By: tom +Build-Jdk: 1.5.0_11 + Added: jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/maven/org.jbpm.jbpm4/docbook-style/pom.properties =================================================================== --- jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/maven/org.jbpm.jbpm4/docbook-style/pom.properties (rev 0) +++ jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/maven/org.jbpm.jbpm4/docbook-style/pom.properties 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,5 @@ +#Generated by Maven +#Fri Sep 19 15:07:00 CEST 2008 +version=1.0.0 +groupId=org.jbpm.jbpm4 +artifactId=docbook-style Added: jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/maven/org.jbpm.jbpm4/docbook-style/pom.xml =================================================================== --- jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/maven/org.jbpm.jbpm4/docbook-style/pom.xml (rev 0) +++ jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/maven/org.jbpm.jbpm4/docbook-style/pom.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,61 @@ +<project xmlns="http://maven.apache.org/POM/4.0.0" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> + + <modelVersion>4.0.0</modelVersion> + + <groupId>org.jbpm.jbpm4</groupId> + <artifactId>docbook-style</artifactId> + <packaging>jdocbook-style</packaging> + <version>1.0.0</version> + + <name>jBPM Documentation Style</name> + <description>The JDocBook styles for the jBPM Documentation.</description> + <url>http://jboss.org</url> + + <organization> + <name>JBoss.org</name> + <url>http://jboss.org</url> + </organization> + + <build> + <plugins> + <plugin> + <groupId>org.jboss.maven.plugins</groupId> + <artifactId>maven-jdocbook-style-plugin</artifactId> + <version>1.0.0</version> + <extensions>true</extensions> + </plugin> + </plugins> + </build> + + <!-- DistributionManagement --> + <distributionManagement> + <repository> + <id>repository.jboss.org</id> + <name>JBoss Maven Repository</name> + <url>file://${jboss.maven.repository}</url> + </repository> + <snapshotRepository> + <id>snapshots.jboss.org</id> + <name>JBoss Snapshot Repository</name> + <url>dav:https://snapshots.jboss.org/maven2</url> + </snapshotRepository> + </distributionManagement> + + <pluginRepositories> + <pluginRepository> + <id>maven2.java.net</id> + <name>Java.net Repository for Maven 2</name> + <url>http://download.java.net/maven/2/</url> + </pluginRepository> + <pluginRepository> + <id>repository.jboss.org</id> + <url>http://repository.jboss.org/maven2</url> + <snapshots> + <enabled>false</enabled> + </snapshots> + </pluginRepository> + </pluginRepositories> + +</project> Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/META-INF/maven/org.jbpm.jbpm4/docbook-style/pom.xml ___________________________________________________________________ Name: svn:keywords + Id Revision Name: svn:eol-style + LF Added: jbpm4/trunk/modules/manual/target/docbook/staging/css/css/codehighlight.css =================================================================== --- jbpm4/trunk/modules/manual/target/docbook/staging/css/css/codehighlight.css (rev 0) +++ jbpm4/trunk/modules/manual/target/docbook/staging/css/css/codehighlight.css 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,242 @@ +span.property {color:#0066CC;} + +pre.JAVA {line-height:10px;} + +pre.XML {line-height:8px;} + +pre.JSP {line-height:8px;} + +pre.XHTML {line-height:8px;} + +.java_type {color:#000000;} + +.java_keyword { + font-weight:bold; + color:#7F1B55; +} + +.java_javadoc_comment { + color:#3F5FBF; + font-style:italic; + background-color:rgb(247,247,247); +} + +.java_comment { + color:#3F7F5F; + background-color:rgb(247,247,247); +} + +.java_operator {color:#000000;} + +.java_plain {color:rgb(0,0,0);} + +.java_literal {color:#2A00FF;} + +pre CODE { + font-size:12px; + color:rgb(0,0,0); + font-family:monospace; + white-space:nowrap; +} + +.java_javadoc_tag { + font-weight:bold; + color:#7F9FBF; + font-style:italic; + background-color:rgb(247,247,247); +} + +.java_separator {color:#000000;} + +.xml_plain {color:rgb(0,0,0);} + +.xml_tag_name {color:#3F7F7F;} + +.xml_comment { + color:#3F5FBF; + background-color:rgb(247,247,247); +} + +.xml_tag_symbols {color:#008080;} + +.xml_rife_tag { + color:rgb(0,0,0); + background-color:rgb(228,230,160); +} + +.xml_attribute_value {color:#2A00FF;} + +.xml_attribute_name { + font-weight:bold; + color:#7F007F; +} + +.xml_char_data {color:rgb(0,0,0);} + +.xml_rife_name { + color:#008cca; + background-color:rgb(228,230,160); +} + +.xml_processing_instruction { + font-weight:bold; + color:rgb(0,0,0); + font-style:italic; +} + +td.java { + vertical-align:top; + line-height:10px; +} + +td.java-ln { + vertical-align:top; + line-height:10px; +} + +tt.java { + margin-bottom:0em; + line-height:10px; + font-family:verdana,helvetica,sans-serif; +} + +tt.java-ln { + margin-bottom:0em; + line-height:10px; +} + +pre.java { + margin-bottom:0em; + line-height:10px; +} + +pre.java-ln { + margin-bottom:0em; + line-height:10px; +} + +td.java-ln { + line-height:10px; + text-align:right; +} + +tt.java-ln { + color:#888888; + line-height:10px; +} + +pre.java-ln { + color:#888888; + line-height:10px; +} + +span.java0 { + font-size:8pt; + color:#ffffff; + line-height:10px; +} + +span.java1 { + font-size:8pt; + color:#808080; +} + +span.java2 { + font-size:8pt; + color:#3f7f5f; + line-height:10px; +} + +/* Single-line comment */ + +span.java3 { + font-size:8pt; + color:#3f7f5f; + line-height:10px; +} + +/* Keywords excluding 'return' */ + +span.java4 { + font-weight:bold; + font-size:8pt; + color:#7F1B55; + line-height:10px; +} + +span.java5 { + font-size:8pt; + color:#2a00ff; + line-height:10px; +} + +span.java6 { + font-size:8pt; + color:#990000; + line-height:10px; +} + +span.java7 { + font-size:8pt; + color:#990000; + line-height:10px; +} + +span.java8 { + font-size:8pt; + color:#000000; + line-height:10px; +} + +/* Primitive types: long, int, void etc... */ + +span.java9 { + font-weight:bold; + font-size:8pt; + color:#7F0055; + line-height:10px; +} + +span.java10 { + font-size:8pt; + color:#000000; + line-height:10px; +} + +span.java11 { + font-size:8pt; + color:#7f9fbf; + line-height:10px; +} + +span.java12 { + font-size:8pt; + color:#7f7f9f; + line-height:10px; +} + +span.java13 { + font-size:8pt; + color:#3f3fbf; + line-height:10px; +} + +span.java14 { + font-size:8pt; + color:#3f5fbf; + line-height:10px; +} + +span.java15 { + font-size:8pt; + color:#7F0055; + line-height:10px; +} + +/* Annotations */ + +span.java16 { + font-size:8pt; + color:#646464; + line-height:10px; +} Added: jbpm4/trunk/modules/manual/target/docbook/staging/css/css/docnav.css =================================================================== --- jbpm4/trunk/modules/manual/target/docbook/staging/css/css/docnav.css (rev 0) +++ jbpm4/trunk/modules/manual/target/docbook/staging/css/css/docnav.css 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,204 @@ +/* Document Navigation */ + +.docnav a, .docnav strong { + text-decoration:none; + font-weight:normal; +} + +.docnav { + list-style:none; + margin:0em; + padding:0em; + position:relative; + width:100%; + padding-bottom:2em; + padding-top:1em; + border-top:1px dotted #ccc; +} + +.docnav li { + list-style:none; + margin:0em; + padding:0em; + display:inline; + font-size:.8em; +} + +.docnav li:before {content:" ";} + +.docnav li.previous, .docnav li.next { + position:absolute; + top:1em; +} + +.docnav li.up, .docnav li.home {margin:0em 1.5em;} + +.docnav li.previous { + left:0px; + text-align:left; +} + +.docnav li.next { + right:0px; + text-align:right; +} + +.docnav li.previous strong, .docnav li.next strong { + display:block; + height:22px; +} + +.docnav { + margin:0 auto; + text-align:center; +} + +.docnav li.next a strong { + background:url(../images/community/docbook/next.png) top right no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-right:60px; + font-size:1.2em; +} + +.docnav li.previous a strong { + background:url(../images/community/docbook/prev.png) top left no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-left:60px; + font-size:1.2em; +} + +.docnav li.home a strong { + background:url(../images/community/docbook/home.png) top left no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-left:60px; + font-size:1.2em; +} + +.docnav li.up a strong { + background:url(../images/community/docbook/up.png) top left no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-left:60px; + font-size:1.2em; +} + +.docnav a:link, .docnav a:visited {color:#666 !important;} + +.docnav a:hover, .docnav a:focus, .docnav a:active {color:black !important;} + +.docnav a { + max-width:10em; + overflow:hidden; +} + +.docnav a:link strong {text-decoration:none;} + +.docnav { + margin:0 auto; + text-align:center; +} + +.docnav {margin-bottom:16px;} + +/* Eclipse Help Navigation */ + +.navheader {padding-top:35px} + +.navheader table {border-style:none} + +.navheader a { + text-decoration:none; + font-weight:normal; + font-size:.8em; +} + +.navheader td.next a { + background:url(../images/community/docbook/next.png) top right no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-right:60px; + font-size:0.9em; +} + +.navheader td.previous a { + background:url(../images/community/docbook/prev.png) top left no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-left:60px; + font-size:0.9em; +} + +.navheader a:link, .navheader a:visited {color:#666 !important;} + +.navheader a:hover, .navheader a:focus, .navheader a:active {color:black !important;} + +.navheader a { + max-width:10em; + overflow:hidden; +} + +.navheader a:link {text-decoration:none;} + +.navfooter table {border-style:none} + +.navfooter a { + text-decoration:none; + font-weight:normal; + font-size:.8em; +} + +.navfooter td.next a { + background:url(../images/community/docbook/next.png) top right no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-right:60px; + font-size:0.9em; +} + +.navfooter td.previous a { + background:url(../images/community/docbook/prev.png) top left no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-left:60px; + font-size:0.9em; +} + +.navfooter td.home a { + background:url(../images/community/docbook/home.png) top left no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-left:60px; + font-size:0.9em; +} + +.navfooter td.up a { + background:url(../images/community/docbook/up.png) top left no-repeat; + padding-top:10px; + padding-bottom:15px; + height:40px; + padding-left:60px; + font-size:0.9em; +} + +.navfooter a:link, .navfooter a:visited {color:#666 !important;} + +.navfooter a:hover, .navfooter a:focus, .navfooter a:active {color:black !important;} + +.navfooter a { + max-width:10em; + overflow:hidden; +} + +.navfooter a:link {text-decoration:none;} Added: jbpm4/trunk/modules/manual/target/docbook/staging/css/css/documentation.css =================================================================== --- jbpm4/trunk/modules/manual/target/docbook/staging/css/css/documentation.css (rev 0) +++ jbpm4/trunk/modules/manual/target/docbook/staging/css/css/documentation.css 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,551 @@ +/* Lists */ + +ol li, ul li { + padding-left:.2em; + padding-bottom:.5em; + margin:0em; +} + +ul { + padding-left:1.6em; + list-style-image:url(../images/community/dot.png); + list-style-type:circle; +} + +ul ul { + list-style-image:url(../images/community/dot2.png); + list-style-type:circle; +} + +dt { + font-weight:bold; + margin-bottom:0em; + padding-bottom:0em; +} + +dd { + margin:0em; + margin-left:2em; + padding-top:0em; +} + +li p:first-child, dd p:first-child { + padding:0em; + margin-top:.3em; +} + +.variablelist, .itemizedlist {margin-top:.6em;} + +ul li p:first-child {margin:0em;} + +/* Images */ + +img { + display:block; + margin:2em 0; +} + +.inlinemediaobject, .inlinemediaobject img { + display:inline !important; + margin:0em; +} + +.programlisting a img, pre a img, td a img, td img { + display:inline; + margin:0 0; +} + +/* Needed for Safari */ + +pre a span img, pre span img { + display:inline; + margin:0 0; +} + +span.co { + position:absolute; + left:900px +} + +/* Document modes */ + +.confidential { + background-color:#900; + color:white; + padding:.5em .5em; + font-family:serif; + text-transform:uppercase; + text-align:center +} + +dt a {font-weight:normal;} + +.longdesc-link {display:none;} + +.prompt { + background-color:#ede7c8; + padding:0em .3em; +} + +/* User interface styles */ + +.screen .replaceable {color:#444;} + +.screen { + background-color:#ede7c8; + color:#333; + padding:.5em 1em; + margin:0em; +} + +pre, code, .guibutton, .keycap, .guilabel { + font-size:0.9em; + font-family:verdana, helvetica, sans-serif; +} + +.guibutton, .keycap, .guilabel { + font-weight:bold; + white-space:nowrap; + color:#444; + font-family:'Lucida Grande', Geneva, Verdana, Arial, sans-serif; +} + +.guibutton, .guilabel {} + +.keycap {padding:.1em.4em;} + +.example { + background-color:#c8c5ac; + padding:5px; + margin-bottom:10px; +} + +/* Terminal/Console text */ + +.command, .computeroutput, .filename, .citetitle, .replaceable, .option {font-weight:bold;} + +.command .replaceable {color:#555;} + +pre { + display:block; + background-color:#f9f3b0; + color:#333; + overflow:auto; + padding:10px 10px; + line-height:1.2; +} + +code {white-space:nowrap;} + +/* Admonitions */ + +/* Set basic colors and spacing */ + +div.note { + background:#b5bcbd; + color:#4c5253; + border:1px solid #8a9195; + margin-bottom:1.5em; + background-repeat:no-repeat; + background-position:10px 10px; + padding:1em; + padding-bottom:20px; +} + +div.tip { + background:#7e917f; + color:white; + border:1px solid #8a9195; + margin-bottom:1.5em; + background-repeat:no-repeat; + background-position:10px 10px; + padding:1em; + padding-bottom:20px; +} + +div.important { + background:#4a5d75; + color:white; + border:1px solid #8a9195; + margin-bottom:1.5em; + background-repeat:no-repeat; + background-position:10px 10px; + padding:1em; + padding-bottom:20px; +} + +div.caution { + background:#e3a835; + color:#533500; + border:1px solid #ab710a; + margin-bottom:1.5em; + background-repeat:no-repeat; + background-position:10px 10px; + padding:1em; + padding-bottom:20px; +} + +div.warning { + background:#7b1e1e; + color:white; + border:1px solid #65504e; + margin-bottom:1.5em; + background-repeat:no-repeat; + background-position:10px 10px; + padding:1em; + padding-bottom:20px; +} + +/* Pre tag color settings */ + +div.note pre { + background-color:#d6dee0; + color:#334558; + border:1px solid #e1e9eb; +} + +div.tip pre { + background-color:#d5e1d5; + color:#334558; + border:1px solid #e1e9eb; +} + +div.important pre { + background-color:#e1eef4; + color:#334558; + border:1px solid #e1e9eb; +} + +div.caution pre { + background-color:#faf8ed; + color:#334558; + border:1px solid #e1e9eb; +} + +div.warning pre { + background-color:#faf8ed; + color:#334558; + border:1px solid #e1e9eb; +} + +/* Background images and margin */ + +div.note, div.tip, div.important, div.caution, div.warning {margin-top:.5em;} + +div.note {background-image:url(../images/community/docbook/note.png);} +div.tip {background-image:url(../images/community/docbook/tip.png);} +div.important {background-image:url(../images/community/docbook/important.png);} +div.caution {background-image:url(../images/community/docbook/caution.png);} +div.warning {background-image:url(../images/community/docbook/warning.png);} + +div.note .replaceable, div.tip .replaceable, div.important .replaceable, div.caution .replaceable, div.warning .replaceable {color:#e3dcc0;} + +pre .replaceable, tt .replaceable {color:#444 !important;} + +div.note h2, div.tip h2, div.important h2, div.caution h2, div.warning h2 { + height:32px; + font-size:1.3em; +} + +div.note h2 {color:#4c5253;} +div.tip h2 {color:white;} +div.important h2 {color:white;} +div.caution h2 {color:#533500;} +div.warning h2 {color:white;} + +div.note .guilabel, div.tip .guilabel, div.important .guilabel, div.caution .guilabel, div.warning .guilabel {color:white !important;} + +div.note li, div.tip li, div.caution li, div.warning li, div.important li { + padding-left:10px; + margin:0em; +} + +div.note ul, div.tip ul, div.caution ul, div.warning ul, div.important ul { + padding-left:40px; + margin:0em; +} + +div.note pre pre a:visited, div.tip pre pre a:visited, div.important pre pre a:visited, div.caution pre pre a:visited, div.warning pre pre a:visited, +div.note pre a:link, div.tip pre a:link, div.important pre a:link, div.caution pre a:link, div.warning pre a:link {color:#0066cc !important;} + +div.note a:visited, div.tip a:visited, div.important a:visited, div.warning a:visited, +div.note a:link, div.tip a:link, div.important a:link, div.warning a:link {color:#f7f2d0;} + +div.note a:visited, div.note a:link, div.caution a:link, div.caution a:visited {color:#0066cc;} + +/* Admonition icons spacing */ + +div.note h2, div.note p, div.tip h2, div.tip p, div.caution h2, div.caution p, div.warning h2, div.warning p, div.important h2, div.important p { + padding:0em; + margin:0em; + padding-left:56px; +} + +/* Page Title */ + +#title { + padding:0px; + margin:0px; +} + +#title strong {display:none;} + +#title a.site_href { + display:block; + height:89px; + width:310px; + float:left; +} + +#title a.doc_href { + display:block; + height:116px; + background:transparent url(../images/jbpm.png) top right no-repeat; +} + +/* Table */ + +table { + border:1px solid #aaa; + width:100%; + border-collapse:collapse; +} + +table th { + text-align:left; + background-color:#4A5D75; + padding:.3em .5em; + color:white; +} + +table td {padding:.15em .5em;} + +table tr.even td {background-color:#f5f5f5;} + +table th p:first-child, table td p:first-child, table li p:first-child { + margin-top:0em; + padding-top:0em; + display:inline; +} + +th, td {border-style:none;} + +table table td { + border-bottom:1px dotted #aaa !important; + background-color:white; + padding:.6em 0em; +} + +table table { + border:1px solid white !important; + font-size:.9em; +} + +td.remarkval { + font-size:.9em; + color:#444; +} + +.defaultval {font-size:.8em} + +td.typeval {font-size:.8em} + +td.fieldval { + font-weight:bold; + font-size:.9em; +} + +th.dbkey {font-size:.9em;} + +.lbname, .lbtype, .lbdescr, .lbdriver, .lbhost { + color:white; + font-weight:bold; + background-color:#999; + font-size:0.9em; + width:120px; +} + +td.remarkval {width:230px;} + +td.tname { + font-weight:bold; + font-size:1.1em; +} + +h5 {font-size:9pt;} +h6 {font-size:10pt;} + +th.dbfield {width:120px;} +th.dbtype {width:70px;} +th.dbdefault {width:70px;} +th.dbnul {width:70px;} +th.dbkey {width:70px;} + +span.book { + margin-top:4em; + display:block; +} + +span.chapter { + display:block; + margin-top:0.5em; +} + +/* Breadcrumbs */ + +#breadcrumbs ul li.first:before {content:" ";} + +#breadcrumbs { + color:#900; + padding:3px; + margin-bottom:25px; +} + +#breadcrumbs ul { + margin-left:0; + padding-left:0; + display:inline; + border:none; +} + +#breadcrumbs ul li { + margin-left:0; + padding-left:2px; + border:none; + list-style:none; + display:inline; +} + +#breadcrumbs ul li:before { + content:"\0020 \0020 \0020 \00BB \0020"; + color:#333; +} + +/* Status */ + +.alpha1 {background:white url(../images/community/watermark-alpha1.png) top left repeat;} +.alpha2 {background:white url(../images/community/watermark-alpha2.png) top left repeat;} +.beta1 {background:white url(../images/community/watermark-beta1.png) top left repeat;} +.beta2 {background:white url(../images/community/watermark-beta2.png) top left repeat;} +.pre-release-candidate {background:white url(../images/community/watermark-pre-release-candidate.png) top left repeat;} +.release-candidate {background:white url(../images/community/watermark-release-candidate.png) top left repeat;} + +/* Index */ + +.glossary h3, .index h3 { + font-size:2em; + color:#aaa; + margin:0em; +} + +.indexdiv {margin-bottom:1em;} + +.glossary dt, .index dt { + font-size:.9em; + color:#444; + padding-top:.5em; +} + +.glossary dl dl dt, .index dl dl dt { + font-size:.85em; + color:#777; + line-height:1.2em; + font-weight:normal; + padding-top:0em; +} + +.index dl dl dt:before { + content:"- "; + color:#ccc; +} + +/* Changes */ + +.footnotes {} + +.footnote { + padding:.2em 1em; + background-color:#c8c5ac; + font-size:.9em; + margin:0em; + margin-bottom:.5em; + color:#222; +} + +table .footnote {margin:1em .5em;} + +sup { + padding:0em .3em; + padding-left:0em; +} + +.footnote {position:relative;} + +.footnote sup { + color:#e3dcc0; + font-size:1.8em; + position:absolute; + left:.4em; +} + +.footnote sup a:link, .footnote sup a:visited { + color:#92917d; + text-decoration:none; +} + +.footnote:hover sup a { + color:#fff; + text-decoration:none; +} + +.footnote p {padding-left:5em;} + +.footnote a:link, .footnote a:visited {color:#00537c;} + +.footnote a:hover {color:white;} + +li p:first-child { + margin:0em !important; + padding:0em !important; +} + +div.chapter, div.section {padding-top:2em;} + +.revhistory {font-size:} + +pre .replaceable, pre .keycap {color:white;} + +pre { + font-family:courier new; + background-color:#F5F5F5; + border:1px solid #CCCCCC; + padding:5px 15px 5px 25px; +} + +div.note .replaceable, div.tip .replaceable, div.important .replaceable, div.caution .replaceable, div.warning .replaceable, +div.note .keycap, div.tip .keycap, div.important .keycap, div.caution .keycap, div.warning .keycap {color:white;} + +div.abstract {font-size:larger;} + +.authorgroup {} + +.authorgroup h4 { + padding:0em; + margin:0em; + margin-top:1em; +} + +.author, .editor, .translator, .othercredit {display:block;} + +/* Simpler author style on contents page */ + +.authorgroup div { + margin-left:10px; + margin-right:10px; + margin-bottom:15px; +} + +ul li p:last-child { + margin-bottom:0em; + padding-bottom:0em; +} Added: jbpm4/trunk/modules/manual/target/docbook/staging/css/css/extensions.css =================================================================== --- jbpm4/trunk/modules/manual/target/docbook/staging/css/css/extensions.css (rev 0) +++ jbpm4/trunk/modules/manual/target/docbook/staging/css/css/extensions.css 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,7 @@ +/* Firefox */ + +pre {-moz-border-radius:11px;} + +.example {-moz-border-radius:15px;} + +div.note, div.tip, div.important, div.caution, div.warning {-moz-border-radius:11px;} Added: jbpm4/trunk/modules/manual/target/docbook/staging/css/css/jbossorg.css =================================================================== --- jbpm4/trunk/modules/manual/target/docbook/staging/css/css/jbossorg.css (rev 0) +++ jbpm4/trunk/modules/manual/target/docbook/staging/css/css/jbossorg.css 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,80 @@ +@import url("documentation.css"); +@import url("docnav.css"); +@import url("reports.css"); +@import url("extensions.css"); +@import url("codehighlight.css"); + +body { + background-image:url(../images/bg.png); + background-repeat:repeat-x; + margin:0 auto; + font-family:'Lucida Grande', Geneva, Verdana, Arial, sans-serif; + font-size:12px; + max-width:55em; + padding:0em 2em; + color:#333; + line-height:150%; + text-align:justify; +} + +/* Links */ + +a:link {color:#0066cc;} + +a:visited {color:#6699cc;} + +div.longdesc-link { + float:right; + color:#999; +} + +/* Headings */ + +h1, h2, h3, h4, h5, h6 { + color:#4a5d75; + line-height:130%; + margin-top:0em; + font-family:'Lucida Grande', Geneva, Verdana, Arial, sans-serif; + background-color:transparent; +} + +h1 { + background-image:url(../images/community/title_hdr.png); + background-repeat:no-repeat; + border-top:1px dotted #CCCCCC; + line-height:1.2em; + color:#182737; + font-size:2em; + padding:1.5em; +} + +h2 {font-size:1.6em;} + +h3 { + font-size:1.3em; + padding-top:0em; + padding-bottom:0em; +} + +h4 { + font-size:1.1em; + padding-top:0em; + padding-bottom:0em; +} + +h5.formalpara { + font-size:1em; + margin-top:2em; + margin-bottom:.8em; +} + +/* Element rules */ + +hr { + border-collapse:collapse; + border-style:none; + border-top:1px dotted #ccc; + width:100% !important; +} + +sup {color:#999;} Added: jbpm4/trunk/modules/manual/target/docbook/staging/css/css/reports.css =================================================================== --- jbpm4/trunk/modules/manual/target/docbook/staging/css/css/reports.css (rev 0) +++ jbpm4/trunk/modules/manual/target/docbook/staging/css/css/reports.css 2008-10-29 16:08:20 UTC (rev 2662) @@ -0,0 +1,231 @@ +/* Reports */ + +.reports ul.locale {list-style:none;} + +.reports ul { + padding:0em; + margin:0em; +} + +.reports ul.locale li { + font-size:small; + color:#000; + display:block; + border:1px solid #eee; + float:left; + padding-right:2em; + margin-right:1em; + margin-bottom:1em; +} + +.reports ul.locale li a { + font-size:1.2em; + display:block; + padding-top:.1em; + padding-bottom:.5em; +} + +.reports ul.locale strong { + display:block; + margin:0em; + padding:0em; + margin-bottom:-2.2em; +} + +.reports ul.locale span.value { + display:block; + position:relative; + text-align:right; + margin-right:-1.5em; + font-size:1.0em; + color:#444; +} + +.reports ul.locale li { + width:12em; + display:block; + float:left; + margin:0em; + clear:none; +} + +.reports ul.locale li div.progress { + font-size:1em; + width:13.2em; + position:relative; + left:0em; + top:0em; + margin-bottom:0em; +} + +.reports h2 { + font-size:1em; + margin:0em; +} + +.reports li {} + +.reports li:hover { + background-color:#666; + border-color:#444 !important; + color:white !important; +} + +.reports li:hover strong, .reports li:hover h2, .reports li:hover a, .reports li:hover span.value {color:white;} + +/* Uniform */ + +body.results, body.reports { + max-width:57em !important; + padding:0em !important; +} + +/* Progress Bar */ + +div.progress { + display:block; + float:left; + width:16em; + background:#c00 url(../images/community/shine.png) top left repeat-x; + height:1em; +} + +div.progress span { + height:1em; + float:left; +} + +div.progress span.translated {background:#6c3 url(../images/community/shine.png) top left repeat-x;} +div.progress span.fuzzy {background:#ff9f00 url(../images/community/shine.png) top left repeat-x;} + +/* Results */ + +.results ul.locale { + list-style:none; + padding:0em; + margin:0em; +} + +.results .pofile { + padding:0em !important; + margin:0em; +} + +.results ul.locale li { + border-top:1px solid #eee; + padding:0em; + margin:0em; + padding-left:32px; +} + +.results ul.locale .pofile { + font-size:1.2em; + display:block; + width:100%; + color:#444; + padding:0em; + margin:0em; +} + +.results span.value {color:#888;} + +.results strong {font-weight:normal;} + +.results .home a { + display:block; + margin:0 auto; + width:5em; + background:url(../images/community/docbook/home.png) top left no-repeat; + padding:5px; + padding-left:28px; + font-size:1.2em; +} + +.results ul.locale li:hover, .results ul.locale li:hover span.pofile, .results ul.locale li:hover strong, .results ul.locale li:hover span.value { + background-color:#666 !important; + color:white; +} + +ul.locale {list-style:none;} + +ul.locale li.total { + font-size:small; + color:#777; + width:31em; + display:block; + float:left; + margin-right:2em; + clear:none !important; +} + +ul.locale li { + clear:both; + font-size:small; + color:#777; + display:block; +} + +ul.locale strong, span.value { + font-weight:normal; + color:#888; + font-size:.7em; +} + +ul.locale li a { + font-size:1.2em; + display:block; + padding-top:.2em; +} + +ul.locale li.total div.progress { + position:relative; + left:0em; + top:0em; + margin-bottom:0em; +} + +ul.locale li {width:100%;} + +ul.locale li div.progress { + float:left; + position:relative; + left:30.5em; + top:-2em; + margin:0em; + margin-bottom:-3em; +} + +li.total {padding:0em !important;} + +li.total { + float:right; + max-width:16em; + padding:.5em; + margin:0 auto; + padding-top:.5em; + background-color:#f7f2d0; + font-size:1.3em !important; + color:#ccc !important; + margin-bottom:1em; + min-height:9.5em; +} + +li.total .value { + color:#444; + font-size:.8em; +} + +li.total strong { + display:block; + color:black; + font-weight:bold; +} + +li.total span.value { + position:relative; + display:block; + top:-1.25em; + text-align:right; +} + +.pofile {position:relative;} Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/apis.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/apis.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/bg.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/bg.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/ch04.execution.states.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/ch04.execution.states.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/ch09.persistent.process.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/ch09.persistent.process.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/class.diagram.process.definition.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/class.diagram.process.definition.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/class.diagram.process.execution.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/class.diagram.process.execution.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/community/title_hdr.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/community/title_hdr.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/composite.node.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/composite.node.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.automatic.wait1.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.automatic.wait1.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.automatic.wait2.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.automatic.wait2.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.automatic.wait3.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.automatic.wait3.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.concurrency.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.concurrency.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.loan.archive.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.loan.archive.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.loan.end.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.loan.end.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.loan.evaluate.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/execution.loan.evaluate.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/initial.in.composite.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/initial.in.composite.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/interceptors.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/interceptors.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/jbpm.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/jbpm.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/loan.db.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/loan.db.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/loan.execution.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/loan.execution.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.ab.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.ab.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.anatomy.classes.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.anatomy.classes.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.automatic.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.automatic.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.loan.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.loan.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.propagate.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.propagate.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.structure.classes.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/process.structure.classes.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/self.transition.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/self.transition.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transactions.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transactions.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.inheritence.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.inheritence.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.into.composite.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.into.composite.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.out.of.composite.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.out.of.composite.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.to.inner.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.to.inner.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Added: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.to.outer.png =================================================================== (Binary files differ) Property changes on: jbpm4/trunk/modules/manual/target/docbook/staging/images/images/transition.to.outer.png ___________________________________________________________________ Name: svn:mime-type + application/octet-stream Modified: jbpm4/trunk/pom.xml =================================================================== --- jbpm4/trunk/pom.xml 2008-10-29 14:48:35 UTC (rev 2661) +++ jbpm4/trunk/pom.xml 2008-10-29 16:08:20 UTC (rev 2662) @@ -35,8 +35,9 @@ <modules> <module>modules/api</module> <module>modules/pvm</module> + <module>modules/cts</module> <module>modules/jpdl</module> - <module>modules/cts</module> + <module>modules/manual</module> </modules> <!-- Properties -->