学习6：网管和黑客都必须知道的命令

下面开始接触
JBPM

的
JPDL

部分：

在
jpdl

参考手册中主要介绍了
processdefinition.xml

文件的格式（
schema

）

一、
Process archive:



如前面所描述的，
process archive

是商务流程的规则描述。它被打成
jar

包，通常以扩展名
.par

结束，
jbpm

识别一个流程需要三种类型的文件数据：

1、

业务流程的正式声明：在
jpdl

中，是以
processdefinition.xml

文件来表达。这一章节我们就来解析这个文件的格式。

2、

设计逻辑：在流程上加上规划逻辑这些也是在
processdefinition.xml

中给予描述的，在
process archive

中可以嵌套
java-classes

。所有在
process archive

中的
classes

应该放在子目录
/classes

中。

3、

其他资源文件。作为工作流引擎的客户端，在运行时你可能想要在流程中包含一些资源文件的变量。例如。窗体（
form

）的描述与某人执行任务相关联。
Jbpm

不能在你想要包含在一个流程定义中的资源文件的类型上做任何手脚。

二、
version


机制（此处
versioning


可以大致理解为：一个
process archive


部署后转变成过程定义的过程。）（此部分需要参考原文理解。感觉不对劲）


作为最最基本的，
jbpm

的翻译机制遵从下面原理：

l

每次
process archive

部署的时候，一个新的流程定义就在
jbpm

数据库中被创建。

l

在部署的时候，
jbpm

安排一个
version

号码（数字）给过程定义。只有当过程名与被定义的号相同时候才会执行
Process archives

。为了实现安排
version

号码，如果它是第一个
version jbpm

采取
1+

(the highest version number of the current process definitions with the same name)
或者
1

。从
jbpm-api

中可以通过一个给定的
name

查找最近的过程定义。

l

在一个给定的定义执行某一个过程实例，过程实例将会（等到同个定义结束前）一直在这个定义中保持执行状态。

l

通过这种方式能通过最近定义启动过程并且在相同定义中的完整的生命周期中保持运行状态。

l

注意：
jbpm

可以把一个设计的程序逻辑与一个过程相关联起来。通过在
process archive

中包含类文件，
jbpm

将会对于每个过程定义把
classes

分离出来。

三、
Processdefinition.xml


格式


文档类型定义：



<!DOCTYPE process-definition PUBLIC

"-//jBpm/jBpm Mapping DTD 2.0 beta3//EN"

"http://jbpm.org/dtd/processdefinition-2.0-beta3.dtd">

the document type definition of processdefinition.xml

过程定义：



<!ELEMENT process-definition (
description?,

swimlane*,

type*,

start-state,

( state |

milestone |

process-state |

decision |

fork |

join

)*,

end-state,

action*
) >

<!ATTLIST process-definition name CDATA #REQUIRED >

dtd fragment for process-definition

状态：


<!ELEMENT state ( description?, assignment?, action*, transition+ ) >

<!ATTLIST state name
CDATA #REQUIRED >

dtd fragment for a state

在
JBPM
中，状态（
state
）这个术语与
FSM
（有限状态机）和
UML
状态图中有着同样的意思。

对商务流程进行建模的目的就是创建一个软件系统。我们考虑到过程定义是软件系统建立的一部分。所以
jbpm
中的状态术语是以一个软件系统的角度来解释的。

状态是
jbpm
的核心概念。在
jbpm
中当开始模仿一个流程，首要需要考虑的事情就是过程的状态。状态将成为你所设计的过程的基本框架。

以状态概念为核心的另外一个特殊原因是：状态在程序语言中没有容易重复混淆的概念。一个软件程序或者运行或者不运行。一个有代表性的商业过程都会与被分别执行的所设计的逻辑部分关联。
Jbpm
允许在相关联的程序逻辑中对状态建模。

Jpdl
也在状态之间定义了变迁，决定，分支，合并，
milestone
（
flow
）。需要注意的，控制流定义在状态与状态之间。无论什么情况下，一个正常的设计逻辑是更合适的，过程开发人员就能够在一个过程事件上指定一个
action
。
Jbpl
与其他过程定义语言如
bpel
等之间的区别之一是，
jpdl
具备以状态管理方式对
java
进行扩展和与程序语言最小交叠性的能力。

委派（

assignment

）：


<ELEMENT assignment EMPTY >

<!ATTLIST assignment swimlane CDATA #IMPLIED

assignment (optional
|required) #IMPLIED

authentication (optional
|required|verify) #IMPLIED >

dtd fragment for an assignment

当一个流程执行到某种状态时候，工作流引擎将会等到一个外部的trigger
（通过调用jbpm
的api
，ExecutionService.endOfState(…)
）。在这个方法里面，jbpm
将会算出流程实例的下一个状态。

所以一个状态能够依赖于一个外部参与者。外部参与者可以是一个人也可以是某个系统。有许多种方式来实现业务流程中的状态与任务相关联。这些任务基本上可以分为两组：

1、

基于客户端的委派

在这种策略中，jbpm
的用户管理他们自己用户的任务列表。在这种情况，jbpm
只是用一个执行引擎来控管有限状态机。Jbpm
的职责是计算并且追踪过程执行中的状态，然而客户端的职责就是确保每个人知道做了什么。然后客户端一般就是在一个给定的状态中找到过程实例（或者说tokens
）

2、

基于流程的委派

（在jbpm2.0 beta3
之前支持这种委派策略）

在这种委派策略中，jbpm
将会担负给参与者安排状态并且追踪任务列表的职责。在jbpm
中，流程在执行过程中是以一个token
来进行跟踪的。一个token
有一个指针来指向状态和一个参与者。在jbpm
中一个参与者总是引用java.lant.string
。为了详细说明jbpm
如何必须安排tokens
给参与者们，一些事件与此相关。接下来一个一个介绍：

只要一个客户端启动一个过程实例或者发出结束状态的信号，jbpm
都会计算过程实例的下一个状态。

首要的事情是关于这些api
方法中的第一个参数：参与者。这个参与用来识别谁来执行。

在启动一个新的过程实例的情况下，一个root-token
在开始状态中被创建好。在结束一个状态的情况下，一个tokenid
需要以一个某种状态中的参数形式指定。然后，jbpm
将会开始为token
计算下一个新状态。为了简单起见，我们忽略并发这种情况。Token
将会经历变迁和节点，然后抵达下一个状态节点。在那时，一个token
需要安排一个参与者。选择一个参与者之后，jbpm
将通过token
和调用的方法（开始过程实例或者结束状态）的返回值进行关联选择的参与者

所以当一个状态中的token
具备有一个参与者时，那就意味着过程实例的执行是在等待这个参与者提供一个外部trigger
给jbpm
引擎。在这种情形下，过程中的状态对应一个用户的任务，jbpm
通过检索所有已经安排给指定的参与者的tokens
计算任务列表。现在，参与者能够从列表中选择一个token
和发出结束状态信号量。

Assignmentn
（委派）有许多属性：assignment
和authentication
。Assingement
属性可以有两个值：optional
和required
。Required
意思指当执行到某一个状态时，jbpm
将会检测是否把一个token
安排了一个参与者。如果非法则会抛出AssignmentException
的异常。如果assingment
是optional
（=default
），当到达一个状态时jbpm
就允许离开一个未安排的token
。属性authentication
指定约束条件来限定哪个参与者可以发出结束状态的信号。参与者通过endOfState
方法中的参数actorid
来指定。如果optional=default
意思指对于指定谁来担当结束状态并不是必须的。Required
意味着一个参与者需要被指定。Vertify
意味着结束状态只可以安排给已经安排token
的参与者。

更多信息请查看群组委派。查看faqs
。

Swimlane



<!ELEMENT swimlane ( description?, delegation

? ) >

<!ATTLIST swimlane name CDATA
#REQUIRED >

dtd fragment for swimlane

非常典型的情况，一个人具备一个流程中多个状态的职责。在
jbpm
中通过创建一个
swimlane
并且通过
swimlane
安排状态给参与者（
actor
）。一个业务流程中的
swimlane
可以被看做为一个针对参与者的角色名字。
Jbpm
对
swimlane
的解释与
UML1.5
中的术语
swimlane
解释一致。首次执行到达一个状态，给定一个
swimlane
，就会算出参与者。

public interface AssignmentHandler {

String selectActor( AssignmentContext assignerContext );

}

the AssignmentHandler

interface

在
swimalne
中的
delegation
标签指向一个
AssignmentHandler
的具体实现。

然后那个参与者（
actor
）以
swimlane
中同名的方式被存储为过程变量。下次当一个
process archives
在一个状态，利用
swimlane
，
jbpm
引擎将会检测变量并且安排
token
给参与者（存储在变量中的）

计算的结果是存储一个
swimlane
同名的过程变量。所以当下一个状态到达相同的
swimlane
时，状态就会安排给相同的
actor
，而不再用
AssignmentHandler
。因为在
swimlane
和参与者之间的关联已经存储在变量中，而且可以通过更新变量来改变
swimlane
参与者（
actor
）之间的关联关系。

变量和类型：



<!ELEMENT type ( description?, (delegation

|transient), variable* ) >

<!ATTLIST type java-type CDATA #IMPLIED >

<!ELEMENT transient EMPTY >

<!ELEMENT variable EMPTY >

<!ATTLIST variable name CDATA #REQUIRED >

dtd fragment for type and variable

一个是变量是一种key-value
对。它与过程实例（一次过程执行）相关联。Key
是java.lang.string
，value
是任何java
类型的任何pojo
。所以任何是java
类型，即使不给jbpm
知道也能被应用到变量中。

变量存储过程实例的上下文信息（context
）。变量可以通过下面几种方式进行设置读取：

ExecutionService.startProcessInstance( String actorId, Long definitionId, Map variables
, String transitionName )

ExecutionService.endOfState( String actorId, Long tokenId, Map variables
, String transitionName )

ExecutionService.setVariables( String actorId, Long tokenId, Map variables
)

ExecutionContext.setVariable( String name, Object value )

ExecutionService.getVariables( String actorId, Long tokenId )

ExecutionContext.getVariable( String name )

当设计变量时候，jbpm
尽量模仿java.util.map
的语义。这一点可以通过jbpm-api
来了解。也就是说一个变量只能当它被插入时被赋值，任何java
类型都可以作为变量中的value
。

一个type
描述jbpm
如何存储变量的值到数据库中。Jbpm
有一个文本域用来存储值，中间以serializer
来实现文本和对象之间的转换。

public interface Serializer {

String serialize( Object object );

Object deserialize( String text );

}

the Serializer

interface

一个type
可以被看做一个serializer
的引用。Jbpm
包含了一些默认serializer
的实现，其中包括下面java
类型：

java.lang.String

java.lang.Long

java.lang.Double

by default supported java-types

变量类型匹配：

Java
类型声明的变量已经被默认支持，而不用在processdefinition.xml
声明。Jbpm
有个自动转换机制：当一个变量初始化后，jbpm
按照下面步骤，首先检测java
类型。如果它默认被java
支持，那么就可以正常使用，否则，jbpm
检查声明的类型是否与processdefinition.xml
中java-type
属性定义的变量是否一致。在匹配过程中jbpm
也考虑变量值的父类。如果没有找不到这种类型，jbpm
就把这样的变量作为transient
（瞬间）变量对待。为了避免jbpm
不得不执行匹配过程，你可以把变量指定到它各自类型中去。

Transient
（瞬间）变量：

一些变量并不需要做持久层处理存储在数据库中，jbpm
支持瞬时变量。这样的变量不存储到数据库中并且只可以在jbpm-api
的方法中使用。换句话说，瞬时变量的使用范围是：jbpm-api
的方法。