一 JPDL
流程定义
process-definition(流程定义)
流程定义的根节点，是所有节点的父节点
名称 类型 数量 描述
name 属性 可选的 流程的名称。
swimlane 元素 [0..*] 流程中使用的泳道。泳道表示流程角色，
它们被用于任务分配。
start-state 元素 [0..1] 流程起始状态。注意，没有起始状态的
流程是合法的，但是不能被执行。
end-state|state|node|task-node|
process-state|super-state|fork|j
oin|decision
元素 [0..*] 流程定义的节点。注意，没有节点的流
程是合法的，但是不能被执行。
event 元素 [0..*] 作为一个容器服务于动作的流程事件。
action|script|create-timer|canc
el-timer
元素 [0..*] 全局定义的的动作，可以在事件和转换
中引用。注意，为了被引用，这些动作
必须指定名称。
task 元素 [0..*] 全局定义的任务，可以在动作中使用。
exception-handler 元素 [0..*] 一个异常处理器列表，用于这个流程定
义中的委托类所抛出的所有异常。
node(自动节点)
这种节点和 State 相反，也称自动节点。当业务程序实例执行到这个节点，不会停止执
行。而是会继续往下执行。如果该节点存在多个离开转向。那么，就会执行其中的第一个离
开转向，在 Node 状态中，不需要外部参与者的参与，业务流程的这个部分是自动的、即时
完成的。
名称 类型 数量 描述
action|script|create-timer|cancel-timer 事件 1 用于表示这个节点行为的定制动
作。
普通节点元素 请参考普通节点元素。
start-state(开始状态)
start-state 是我们整个流程的开始节点，所有的流程实例从这里开始。
名称 类型 数量 描述
Name 属性 可选的 节点的名称。
Task 元素 [0..1] 起始一个流程实例的任务，或者用来捕获流程发起
者
Event 元素 [0..*] 支持的事件类型：｛node-leave｝。
transition 元素 [0..*] 离开转换，每个离开节点的转换必须有一个不同的
名称。
exception-handler 元素 [0..*] 一个异常处理器列表，用于这个流程节点中的委托
类所抛出的所有异常。
end-state(结束节点)
对于每一个流程定义都会有一个结束节点，与开始节点对应
名称 类型 数量 描述
Name 属性 必需的 结束状态的名称。
event 元素 [0..*] 支持的事件类型：｛node-enter｝。
exception-handler 元素 [0..*] 一个异常处理器列表，用于这个流程节点中的委托
类所抛出的所有异常。
state(状态)
State 节点也叫手工节点，进入到这种节点，整个流程的执行就会中断。直到系统外参
与者发起继续执行的命令，即调用 signal 或 end 方法，业务程序实例的执行才能够继续下去。
名称 类型 数量 描述
name 属性 必需的 节点的名称。
async 属性 {true|false}，
默认是 false
如果设置为 true，这个节点将会异步执行。请
参考”异步执行”章节。
transition 元素 [0..*] 离开转换。每个离开节点的转换必须有一个不
同的名称，最多只允许所有离开转换中的一个
没有名称。第一个转换被指定为默认转换，当
离开节点而没有指定转换时，默认转换发生。
event 元素 [0..*] 支持的事件类型：｛node-enter|node-leave｝。
exception-handler 元素 [0..*] 一个异常处理器列表，用于这个流程节点中的
委托类所抛出的所有异常。
timer 元素 [0..*] 指定一个定时器，用来监视节点中的一个执行
所持续的时间。
task-node (任务节点)
其性质和 node 节点一样，在没有 task 的时候，也都是自动执行，不等待。task-node 被
归类为一个等待节点，是指在 task-node 中的 task 列表中的 task 没有全部执行完之前，它会
一直等待。Task 可以在 task-node 节点下定义，也可以挂在 process-definition 节点下。最普
遍的方式是在 task-node 节点下定义一个或多个任务。默认情况下，流程在 task-node 节点会
处于等待状态，直到所有的任务被执行完毕。Task 的执行是按顺序执行的，任务都完成后，
token 仍然不会指向后面的节点；需要自己手动调用 ()才会驱动流程到
下面的节点。
名称 类型 数量 描述
signal 属性 可选的 {unsynchronized|never|first|first-wait|last|last-wait}，默
认是 last。signal 指定了任务的完成对流程执行继续
的影响。
create-tasks 属性 可选的 {yes|no|true|false}，默认是 true。当需要在运行时通
过计算来决定哪个任务将被创建时，可以设置为
false，如果这样的话，在 node-enter 事件上加一个动
作，在动作中创建任务，并且把 create-tasks 设置为
false。
end-tasks 属性 可选的 {yes|no|true|false}，默认是 false。如果设置 end-tasks
为 true，在离开节点时，所有打开的任务将被结束。
task 元素 [0..*] 当执行到达本节点时所应被创建的任务。
普通节点元素 请参考普通节点元素。
为了帮助读者理解 task-node 节点的 signal 属性，这里举例如下：
对于这样的流程定义：
<task-node name='a'>
<task name='laundry' />
<task name='dishes' />
<task name='change nappy' />
<transition to='b' />
</task-node>
a) 这里没有定义 signal 属性的值，这就表明当节点中的三个任务都完成后，流程才进入后
面的节点
b) 当<task-node name='a' signal='unsynchronized'>表明 token 不会在本节点停留，而是直接
到后面的节点
c) 当<task-node name='a' signal='never'>表明三个任务都完成后，token 仍然不会指向后面的
节点；需要自己手动调用 ()才会驱动流程到下面的节点
d) 当<task-node name='a' signal='first'>表明只要有一个任务完成后，token 就指向后面的节
点
e) 当<task-node name='a' signal='first-wait'>表明当第一个任务实例完成时继续执行；当在 a
节点入口处没有任务创建时，token 在 a 任务节点处等待，直到任务被创建或完成。
f) 当<task-node name='a' signal='last'>时，这是默认值，和不设置 signal 属性的情况相同。
g) 当<task-node name='a' signal='last-wait'>时，当最后一个任务实例完成时候继续执行下去。
当 a 这个任务节点没有任务被建立时,任务节点等待直到任务被建立。
fork(分支)
一个 fork 把一个执行路线分割成多个执行路线. 默认分支的行为是为每个离开分支转
换建立一个子令牌,在令牌要到达的分支之间建立一个父母-子女关系
名称 类型 数量 描述
name 属性 必需的 节点的名称。
async 属性 {true|false}，
默认是 false
如果设置为 true，这个节点将会异步执行。请参
考”异步执行”章节。
transition 元素 [0..*] 离开转换。每个离开节点的转换必须有一个不
同的名称，最多只允许所有离开转换中的一个
没有名称。第一个转换被指定为默认转换，当
离开节点而没有指定转换时，默认转换发生。
event 元素 [0..*] 支持的事件类型：｛node-enter|node-leave｝。
exception-hand
ler
元素 [0..*] 一个异常处理器列表，用于这个流程节点中的
委托类所抛出的所有异常。
timer 元素 [0..*] 指定一个定时器，用来监视节点中的一个执行
所持续的时间。
join(联合)
默认联合(join)假设所有来自同一个父母的子令牌联合，当在上使用 fork(分支)这个情形
就出现了并且所有令牌分支建立，并且到达同一个联合(join)。当全部令牌都进入联合的时
候联合就结束了， 然后联合将检查父母-子女， 当所有兄弟令牌到达联合(join)，父母令牌
将传播(唯一的)离开转换，当还有兄弟令牌活动时，联合的行为将作为等待状态。
名称 类型 数量 描述
name 属性 必需的 节点的名称。
async 属性 {true|false}，
默认是 false
如果设置为 true，这个节点将会异步执行。
transition 元素 [0..*] 离开转换。每个离开节点的转换必须有一
个不同的名称，最多只允许所有离开转换中的
一个没有名称。第一个转换被指定为默认转换，
当离开节点而没有指定转换时，默认转换发生。
event 元素 [0..*] 支持的事件类型：｛node-enter|node-leave｝。
exception-hand
ler
元素 [0..*] 一个异常处理器列表，用于这个流程节点
中的委托类所抛出的所有异常。
timer 元素 [0..*] 指定一个定时器，用来监视节点中的一个
执行所持续的时间。
对于 Join 节点，我们知道默认是要等到所有分支都到了流程才能往下继续走，要改变这一
情况，我们可以通过给该节点加 Action 的方法改变该 Join 节点的 Discriminator，就可以使
只要有一个分支到达流程就可以继续执行的效果了
decision(决策)
一个 decision 用以决定在多个执行路径中哪个才可以被执行。如果你是一个程序员，
把它可以理解成 switch case 结构即可，一个 decision 能够具有许多离开的 transition。
名称 类型 数量 描述
handler 元素 要么指定“handler”
元素，或者在转
换上指定条件。
一个 的实
现名称。
transition 元素 [0..*] 离开转换。决策的离开转换可以被扩展为拥有
一个条件，决策会查找条件计算为 true 的第
一个转换，没有条件的转换被认为计算为 true
（为了建模“otherwise”分支）。请参考 condition
元素。
普通节点元素 请参考普通节点元素。
et/fckeditor/editor/
ryEditor1_FCKEditor&Toolbar=Default#_%E6%99%AE%E9%80%9A%E8%8A%82%E7%82%B9%E5%85%83%E7%B4%A0
Handler 所指定的 DecisionHandler 的实现类里的 decide 方法返回一个字符串，表示要执行哪
个 transition
transition(转换)
转换用来指定节点之间的连接。transition 元素放在 node 里面，那么这个 transition 就
会从这个节点出离开。
名称 类型 数量 描述
name 属性 可选的 转换的名称。注意，每个节点的离开转换必须
有一个不同的名称。
to 属性 必需的 目标节点的分级名称，表示将要达到的那个节
点名称.
action|script
|create-timer
|cancel-timer
元素 [0..*] 发生转换时将要执行的动作。注意，转换的动
作无需放入事件（因为只有一个事件）。
exception-handler 元素 [0..*] 一个异常处理器列表，用于这个流程节点中的
委托类所抛出的所有异常。
event(事件)
JBPM 定义了一系列与工作流节点元素相关联的事件，例如，流程实例运行过程中，可
以触发节点进入（node-enter)、节点离开 （node-leave）、流程启动（process-start）、流程结
束（process-end）、任务创建（task-create）、 任务分派（task-assign）、任务启动（task-start）
等事件。
在流程定义时，JBPM 的事件均与 action 绑定。事件的触发将导致相应 actions 的执行。
名称 类型 数量 描述
type 属性 必需的 表示相对于事件要放置的元素事件类型。
action|script|create-timer|
cancel-timer
元素 [0..*] 在这个事件上将要执行的动作列表。
action(动作)
一个 action 是一段 java 代码。在流程执行期间在一些事件之上定义，这样会在相关事
件触发时自动在工作流引擎上执行。
名称 类
型
数量 描述
name 属
性
必需的 动作的名称。当动作被指定名称后，它们可以在
流程定义中被查出，这对于运行时动作以及仅一
次声明动作是有用的。
class 属
性
或者用
ref-name，或
者用
expression。
实现 接口的类
的全名。
ref-name 属
性
或者用 class。 所引用动作的名称。如果指定一个引用动作，则
本动作不需要再做处理。
expression 属
性
或者指定一
个 class，或者
ref-name。
一个解决一个方法的 jPDL 表达式。
accept-
propagated-events
属
性
可选的 {yes|no|true|false}，默认是 yes|true。如果设置为
false，则动作仅在本动作元素的触发事件上被执
行。更多信息，请参考“第 事件传播”。
config-type 属
性
可选的 {field|bean|constructor|configuration-property}。指
定动作对象将被怎样创建以及本元素的内容怎
样象配置信息那样被动作对象所使用。
async 属
性
{true|false} 默认 false，这意味着动作将在当前执行的线程中
被执行。如果设置为 true，一个消息将被发送到
命令执行器，并且执行器组件将在一个独立的事
务中同步执行动作。请参考”异步执行”章节。
ontentPlaceHolder1_EntryEditor1_FCKEditor&Toolbar=Default#_%E9%85%8D%E7%BD%AE%E7%B1%BB%E5%9E%8Bfield
?InstanceName=ctl00_ContentPlaceHolder1_EntryEditor1_FCKEditor&Toolbar=Default#_%E9%85%8D%E7%BD%AE%E7%B1%BB%E5%9E%8Bconfiguration-property
{
内
容}
可选的 action 的内容可以被作为你定制动作实现的配置
信息，这是考虑到可重用的委托类的创建。有关
委托配置的更多信息，请参考“第 节委托
配置”。
script(脚本)
Script 里是动作执行的 beanshell 脚本.
名称 类型 数量 描述
name 属性 可选的 脚本动作的名称。当动作被指定名称后，它们可以
在流程定义中被查出，这对于运行时动作以及仅一
次声明动作是有用的。
Accept
-propagated
-events
属性 可选的
[0..*]
{yes|no|true|false}，默认是 yes|true。如果设置为 false，
则动作仅在本动作元素的触发事件上被执行.
expression 元素 [0..1] beanshell 脚本。如果你没有指定 variable 元素，可
以写表达式作为脚本元素的内容（忽略 expression
元素标签）。
variable 元素 [0..*] 脚本所需变量。如果没有指定变量，则当前令牌的
所有变量将被装载到脚本，当你想要限制装载到脚
本中的变量数量时使用 variable。
expression（表达式）
Expression 里可书写 Beanshell 脚本
名称 类型 数量 描述
{内容} 一个 beanshell 脚本。
variable(变量)
一个是变量是一种 key-value 对。它与过程实例（一次过程执行）相关联。Key 是
，value 是任何 java 类型的任何 pojo。所以任何是 java 类型，即使不给 jbpm
知道也能被应用到变量中。JBPM 的流程变量在尽量模仿 的语义。这一点可以
通过 JBPM 的 API 来了解。也就是说一个变量只能当它被插入时被赋值，任何 java 类型都
可以作为变量中的 value。
名称 类型 数量 描述
name 属性 必需的 流程变量的名称。
access 属性 可选的 默认是 read,write，用逗号分割的一个访问列表。迄
今为止，使用的访问仅为 read，write 和 required。
mapped-name 属性 可选的 默认是变量的名称。用来指定变量名称被映射的名
称，mapped-name 的含义依赖于这个元素所被使用
的上下文。对于一个脚本，将是一个脚本变量名称；
对于一个任务控制器，将是任务表单参数的标签；
对于一个 process-state，将是在子流程中使用的变
量名称。
handler(句柄)
Handler 是在定义一个 decision 时需要为其定义一个 DecisionHandler 时采用。
名称 类
型
数量 描述
expression 属
性
或者用 class 一个 jPDL 表达式，返回结果被用 toString()方法转换为
字符串，结果字符串应该与某个离开转换匹配。
class 属
性
或者用
ref-name
实现了 接口的类
的全名。
Config
-type
属
性
可选的 {field|bean|constructor|configuration-property}。指定动
作对象将被怎样创建以及本元素的内容怎样象配置信
ault#_%E9%85%8D%E7%BD%AE%E7%B1%BB%E5%9E%8Bfield
r/
CKEditor&Toolbar=Default#_%E9%85%8D%E7%BD%AE%E7%B1%BB%E5%9E%8Bconfiguration-property
息那样被动作对象所使用。
{内
容}
可选的 Action 里的内容可以用来帮助结合我们的业务来处理
我们的流程,同时我们可以在 Action 里加上业务处理
逻辑,以更好的利用流程.
timer(定时器)
定时器 timer 可以被用于 decision fork join node process-state state super-state task-node，
可以设置开始时间 duedate 和频率 repeat，定时器动作可以是所支持的任何动作元素，如
action 或 script。
timer 还有一个很重要的属性 cancel-event，这个是 timer 和 task 结合时使用的，任务定
时器的 cancel-event 可以被定制。默认情况 下，当任务被结束时（=完成）任务上的定时器
将被取消，这是通过在定时器上使用 cancel-event 属性，流程开发者可以定制诸如 task- assign
或 task-start。cancel-event 支持多个事件，通过在属性中指定一个用逗号分割的列表，可以
组合 cancel-event 的类型。
名称 类型 数量 描述
name 属性 可选的 定时器的名称。如果没有指定名称，则采用外部的
节点名称。注意，每个定时器应该有一个唯一的名
称。
duedate 属性 必需的 所指定的定时器创建到定时器执行之间的期限（可
以用业务时间来表示）。
repeat 属性 可选的 {duration|yes|true}当一个定时器在预期时间执行后，
“repeat”可选项指定了在离开节点之前重复的执行
定时器之间的期限。如果指定为 true 或 false，则
与 duedate 相同的期限被使用。
transition 属性 可选的 当定时器执行、定时器事件触发后以及执行动作时
时所使用的转换名称。
cancel-event 属性 可选的 这个属性只用在任务的定时器中，它指定了定时器
将被取消的事件。默认是 task-end 事件，但是也可
以被设置为如 task-assign 或 task-start。cancel-event
的类型也可以通过指定一个用逗号分割的列表被
组合。
action|script|
create-timer|
cancel-timer
元素 [0..*] 当定时器被触发时所应被执行的动作。
create-timer(创建定时器)
Create-timer 是定时器的创建
名称 类型 数量 描述
name 属性 可选的 定时器的名称。这个名称可被用于用一个 cancel-timer
动作取消定时器。
duedate 属性 必需的 所指定的定时器创建到定时器执行之间的期限（可以用
业务时间来表示）。请参考“第 节期限”中的语法。
repeat 属性 可选的 {duration|’yes’|’true’}当一个定时器在预期时间执行后，
“repeat”可选项指定了在离开节点之前重复的执行定时
器之间的期限。如果指定为 true 或 yese，则与 duedate
相同的期限被使用。请参考“第 节期限”的语法。
transition 属性 可选的 当定时器执行、定时器事件触发后以及执行动作时时
（如果要）所获取的转换名称。
cancel-timer(取消定时器)
Cancel-timer 是定时器的取消
名称 类型 数量 描述
name 属性 可选的 要被取消的定时器的名称。
itor/editor/
task(任务)
Task 是是流程定义里的一部分，它决定了 task instance 的创建和分配
名称 类型 数量 描述
name 属性 可选的 任务的名称。命名的任可以被引用并且可以通过
TaskMgmtDefinition 被查出。
blocking 属性 可选的 {yes|no|true|false} 如果 blocking 设置为 true，当任务没有
结束时节点不能被离开（必须要通过 ()方
法离开节点）；如果设置为 false（默认），允许用户通过
signal 继续执行和离开节点。默认设置为 false，因为通常
是由用户接口来强制阻塞。
signalling 属性 可选的 {yes|no|true|false}，默认是 true。如果设置 signalling 为 false，
则任务没有触发令牌继续的能力。
duedate 属性 可选的 延迟时间（任务执行的的延迟时间）。请见业务日历中的
解释。
swimlane 属性 可选的 引用一个 swimlane，如果在任务上指定了一个 swimlane，
则 assignment 将被忽略。
priority 属性 可选的 {highest,high,normal,low,lowest}之一。作为选择，可以为
priority 指定任何整数，供参考：(highest=1,lowest=5)。
assignment 元素 可选的 描写一个委托，该委托将在任务被创建时把任务分配给一
个参与者。
event 元素 [0..*] 支持的事件类型：
｛task-create|task-start|task-assign|task-end｝。为了任务分配，
我们特别的为 TaskInstance 添加了一个非持久化的属性
previousActorId。
exception
-handler
元素 [0..*] 一个异常处理器列表，用于这个流程节点中的委托类所抛
出的所有异常。
timer 元素 [0..*] 指定一个监视本任务执行期限的一个定时器。对于任务定
时器特殊的是可以指定 cancel-event，cancel-event 默认是
task-end，但是它可以被自定义如 task-assign 或 task-start。
controller 元素 [0..1] 指定流程变量怎样被转换为任务表单参数。任务表单参数
有用户界面使用，用力向用户表现一个任务表单。
swimlane(泳道)
实际应用中，一个人是一个流程中多个 Task 的参与者(actor)的情况是很常见的。在 jbpm 中
通过创建一个 swimlane 并且把 swimlane 赋给一个 task 的方式来设置当前 task 的参与者
（actor）。一个业务流程中的 swimlane 可以被看做为一个参与者的参与者对象的名称，当然
它不一定是固定的某个人，它可以是一个用户组，一个特定用户的角色等。首次执行到达一
个 Task，赋给该 Task 的一个 swimlane 就会算出参与者(actor)。
名称 类型 数量 描述
name 属性 必需的 泳道的名称。泳道可以被引用并且可以通过
TaskMgmtDefinition 被查出。
assignment 元素 [1..1] 指定泳道的分配。这个分配在本泳道中的第一个任务
实例被创建时完成。
assignment(委派)
当流程执行到某个 Task 的时候，引时流程引挚要调用相应的 swimlane 或 assignment 将当前
的 task 分配（委派）给某个参与者，外部参与者可以是一个人也可以是某个系统等。
名称 类型 数量 描述
expression 属性 可选
的
由于历史原因，这个属性的表达式不是 jPDL 表达式，而是
对 jBPM 身份组件的一个分配表达式。
actor-id 属性 可选
的
一个 actorId，可以与 pooled-actors 协同使用。actor-id 被作
为一个表达式，因此你可以引用一个固定的 actorId，如
actor-id=”bobthebuiler”；或者你可以引用一个可以返回一个
字符串的属性或方法，如 actor-id=””，这将调
用任务实例变量“myVar”上的 getActorId 方法。
Pooled 属性 可选 一个逗号分割的 actorId 列表，可以与 actor-id 协同使用。一
-actors 的 个固定的参与者池可以指定如下：
pooled-actors=”chicagobulls,pointersisters”。 pooled-actors 被
作为一个表达式，因此你可以引用一个返回 String[]、
Collection、或一个逗号分割的池中的参与者列表的属性或
方法。
class 属性 可选
的
一个实现 接口的
类的全名称。
config-type 属性 可选
的
{field|bean|constructor|configuration-property}。指定分配处理
器对象（assignment-handler-object）对象将被怎样创建以及
本元素的内容怎样象配置信息那样被分配处理器对象所使
用。
{内
容}
可选
的
assignment 元素的内容可以被作为分配处理器
（AssignmentHandler）实现的配置信息，这是考虑到可重用
的委托类的创建。
controller(控制器)
在任务执行时，可能需要读、写流程变量；在任务完成并提交时，可能需要写流程变量。
为此，jBPM 提供了"任务变量"的概念。在某些情况下，任务变量和流 程变量并非简单的一
一对应关系，例如，三个流程变量代表三个月的销售额，任务变量只需要它们的平均值。为
实现任务与流程实例之间的信息交流，jBPM 设置 了任务控制器机制。该机制也采用递进
模式：首先，jBPM 提供基本（默认）的任务控制器；如果不敷使用，二次开发人员可以使
用自定义的任务控制器。 jBPM 的任务控制器机制在流程变量和任务变量之间架起了一座
桥梁。
名称 类型 数量 描述
class 属性 可选的 一个实现 接口
的类的全名称。
Config 属性 可选的 {field|bean|constructor|configuration-property}。指定分配处理
or/
ame=ctl00_ContentPlaceHolder1_EntryEditor1_FCKEditor&Toolbar=Default#_%E9%85%8D%E7%BD%AE%E7%B1%BB%E5%9E%8Bbean
ContentPlaceHolder1_EntryEditor1_FCKEditor&Toolbar=Default#_%E9%85%8D%E7%BD%AE%E7%B1%BB%E5%9E%8Bbean
-type 器对象（assignment-handler-object）对象将被怎样创建以及本
元素的内容怎样象配置信息那样被分配处理器对象所使用。
{内
容}
controller 元素的内容要么是指定的任务控制处理器的配置信
息（如果指定了 class 属性），要么必须是一个 variable 元素列
表（如果没有指定任务控制器）。
variable 元素 [0..*] 如果没有通过 class 属性指定任务控制处理器，则 controller 元
素的内容必须是变量列表。
process-state 子流程
process-state 是 JBPM 提供的用来处理子流程的节点，一个 process-state 只能对应一个子流
程，究竟指到哪个子流程可以在 process-state 的 action 里指定，当 token 执行到指定的子流
程时，子流程就已经启动，不用像启动主流程一样手工启动子流程。其它部分的处理就和普
通的流程没有区别了。
名称 类型 数量 描述
name 属性 必需的 名称。
Sub-process 元素 只能定
义一个
子流程
variable 变量 [0…*] Variable 是用来指定如何把数据从父流程 copy 到
子流程
sub-process 子流程
名称 类型 数量 描述
name 属性 必需的 子流程的名称
version 属性 可选 子流程的版本。如果没有指定该属性，默认将会采且
该子流程的最后一个版本
condition 条件
名称 类型 数量 描述
{内容}或属性
表达式
必需的 condition 元素的内容是一个计算结果为布尔值的
jPDL 表达式。决策采用第一个表达式处理结果为 true
的转换（按在 中的顺序），如果
没有条件处理结果为 true，则采用默认离开转换（也
就是第一个）。
exception-handler 异常处理
Jbpm 的异常处理机制仅仅集中于 java 异常，流程定义本身的执行不会导致什么异常，
只有在执行委托类时才会导致异常。
在流程定义（process-definitions）添加的 exception-handler 对整个流程起作用、节点
（nodes）上添加异常只对当前的节点起作用（同时如果在 process-definitions 里也设置了
exception-handler 那么将不会再执行 process-definitions 里的 exception-handler），和转换
（transitions）添加 exception-handler 只对当前的 transitions 起作用（同时如果在
process-definitions 里也设置了 exception-handler 那么将不会再执行 process-definitions 里的
exception-handler），可以指定一个异常处理（exception-handlers）清单，每个异常处理
（exception-handler）有一个动作列表，当在委托类中发生异常时，会在流程元素的父层次
搜索一个适当的异常处理（exception-handler），当它被搜索到，则异常处理
（exception-handler）的动作将被执行。
注意，Jbpm 的异常处理机制与 java 异常处理不完全相似。在 java 中，一个捕获的异常
可以影响控制流，而在 Jbpm 中，流程不会被 Jbpm 异常处理机制所改变。异常要么被捕获，
要么不捕获，没有被捕获的异常被抛向客户端（例如客户端调用 ()），而被捕获
的异常则是通过 Jbpm 的 exception-handler，对于被捕获的异常，图执行仍会继续，就像没
有异常发生一样。
在处理异常的动作中，可以使用 (Node node)把令牌放入图中的任何节点。
二 XPDL 之流程定义元模型
XPDL 元模型定义了流程定义里所包含的实体、它们的关系以及属性，其中
属性不仅仅为了执行需要，很多属性是为了统计与监控的需要。
包（Package）
流程模型包含许多作用域大于流程定义的实体，例如参与者声明、应用程序
声明和相关数据元素，它们可能被多个流程定义所引用。为了避免每个流程定义
都重复定义这些实体，XPDL 引入包的概念，包作为流程定义的容器，对流程定
义按照关联性进行分组。在包上定义的实体被其包含的流程定义继承，同时，包
能够为所属流程定义声明一系列的通用属性，例如作者、版本号、状态等。
XPDL 里的包等价于 BPMN 里的业务流程图（Business Process Diagram）。
泳道（Swimlanes）
泳道被用来对流程定义和活动进行布局。我们使用泳道在流程级别上定义参
与者信息（部门、公司），在活动级别上定义执行者信息（角色、人员）。我们
使用一系列非重叠的长方形来描述泳道，这些长方形称为池（Pool），同时，池
又被细分为一系列的子泳道（Lane）。如下图 2-6 所示：
名称 类型 数量 描述
exception-class 属性 可选的 指定与本异常处理器所匹配的 java throwable 类，
如果这个没有指定这个属性，则它匹配所有异常
（）。
action 元素 [1..*] 当异常被异常处理器捕获时将要执行的动作列表。
图 2-6 泳道
同样的在下图中描述了一个包含贷款应用流程的池。池中没有道。流程可以是可
重用的子流程或内嵌的子流程。
要注意迁移（顺序流）可以穿越同一个池中的道。迁移可能不会穿越池。
流程定义(Process Definition)
流程定义是对流程的建模和描述，为流程中的其他实体提供上下文信息。其
属性包括创建时间、作者、初始化参数、执行优先级、时间约束、仿真信息等。
文档包含对流程集（包）的流程定义。Xml 文档不仅被模型工具、
模拟工具和执行工具使用，它同样为 bam 报表工具提供了基本信息，特别是为
OLAP 立体报表技术提供了维度和变量信息。
在这里我们描述了使用管理工具发送 xpdl 流程定义到分析工具并传达能捕
捉执行的详细情况的日志事件流的企业流程管理系统。分析工具根据流程定义、
参与者和队列信息来构造数据库和 OLAP 立方。分析工具处理事件来更新数据
库中实际和维度上的表，并且利用 excel 和（或）其他拥有的流程以及企业智能
工具立体处理事件来完成对切片和切块查看数据的交互的准备。
一个可供选择的数据展示的方法显示了流程定义的视觉环境中选择的数据。
这个可以由历史展示或动画执行系统或模拟运行来实现。
活动（Activity）
活动是流程中的一个步骤，一个基本活动具有属性。这些属性提供了在这一
步骤中谁可以执行这个活动、什么应用或 Web 服务会被调用、正在工作的对象
的哪些内容被使用了以及（或）被改变了等信息。参与者（资源）和应用可能会
定义在一个流程中，或者被定义在企业流程模型的整个流程集中。工作对象的内
容同样可以定义在一个流程中或整个模型中。活动有一些其他属性更进一步定义
了它们的特殊角色或它们是如何实现的一个流程包含一个或多个活动，活动对应
着流程里的一个工作单元。一个典型的活动能被人力资源或计算机所执行。
XPDL 的活动粒度比较粗，分为四类，分别对应 BPMN 里的任务、子流
程、网关和事件。如下图 2-7 所示：
图 2-7XPDL 活动与 BPMN 的映射
转移线(Transition)
活动之间通过转移线连接。转移线包括 3 个属性：源活动、目标活动和条
件。转移线可以是有条件的（设置表达式），也可以是无条件的。
XPDL 的转移线对应于 BPMN 里的顺序流，如下图 2-8 所示：
图 2-8XPDL 转移线对应 BPMN 里的顺序流
参与者声明（Participant Declaration）
描述执行流程和活动的资源。资源可以是单个人、也可以是角色、部门、还
可以是自动执行的机器资源（例如打印机）。
应用程序声明（Application Declaration）
活动可以调用的 IT 系统、接口、Web 服务。BPMN 使用内置的服务任务
（Service Task）直接代表对应用程序的调用。
人工产出物(Artifact)
为流程附加额外的建模信息，这些信息不属于基本的流程实体（活动、转
移线、消息流），它们通过关联与流程实体联系在一起。在 BPMN 里，人工交
付物包括 3 种类型，如下图 2-9 所示：
图 2-9 人工产出物
消息流（Message Flow）
消息流用来展示两个参与者/流程之间的消息流向。在 BPMN 中，用泳道
中的池代表两个参与者/流程。消息流不能连接同一个池中的活动。
图 2-10 消息流
消息流一般由 Web 服务或消息队列实现。在例子中我们阐述了不同池中的
活动之间的消息流是怎样流动的。这使得我们可以图形化的展示流程之间各方面
的安排。应该注意的是消息流不会出现在同一个池中的活动之间。换句话说，顺
序流用来连接同一个池中的活动，而消息流用来展示不同池中的活动之间的通信。
这个例子中的池被画成水平方向并且扩展到整个页面。但是，规范中也支持垂直
池，并允许限制宽度和高度。这支持了规范中抽象流程和安排对池的使用。
关联(Association)
我们使用关联将信息、人工产出物与流程实体连接起来，为流程模型提供
更多的信息，它不影响流程的执行。如下图 2-11 所示：
图 2-11 关联
相关数据元素（Relevant data field）
为流程定义执行过程中创建或使用到的数据，这些数据被活动、应用程序和
流程中定义的各种表达式（转移线条件计算、网关条件计算）所使用。
数据类型与表达式（Data Types and Expressions）
定义相关数据元素、系统与环境数据、参与者数据的数据类型，这包括了一
些标准类型，例如 String、int、date 等等，也包括了自定义的扩展。表达式被用
于各种条件计算（转移线、网关）以及给数据元素赋值。
系统与环境数据 （System and Environmental Data）
由工作流系统和外部环境所维护的数据，这些数据被流程在执行过程中使
用。
资源仓库（Resource Repository）
执行活动的资源可以是人、也可以是角色、部门、程序、还可以是自动执
行的机器资源，所以我们使用资源仓库将流程所涉及到的资源管理起来。资源仓
库包括了对组织机构建模的支持。
厂 商 / 用 户 自 定 义 扩 展 （ Vendor or User specific
Extensions）
工作流系统厂商/用户可以针对自己的业务需求对流程元素和属性进行扩展。
流程交换
一般的元模型允许工具交换模型。这些工具有：
模拟工具
监控工具
执行工具
模型工具
库工具
下图展示了再 BPM 套件中流程交换的使用。
三
一个 BPMN XML 流程的根是 definitions 元素。 在命名状态，子元素会
包含真正的业务流程定义。 每个 process 子元素 可以拥有一个 id 和 name。
的基本结构：
事件
与活动和网关一起，事件用来在实际的每个业务流程中。事件让业务建模工
具用很自然的方式描述业务流程，比如“当我接收到客户的订单，这个流程就启
动”，“如果两天内任务没结束，就终止流程” 或者当我收到一封取消邮件，当流
程在运行时，使用子流程处理邮件。注意典型的业务 通常使用这种事件驱动的
方式。人们不会硬编码顺序创建，但是他们倾向于使用在他们的环境中发生的事
情（比如，事件）。 在 BPMN 规范中，描述了很多事件类型，为了覆盖可能的
事情，在业务环境中可能出现的情况。
事件：空启动事件
一个启动事件说明了流程的开始（或子流程）。图形形式，它看起来 是一个
圆（可能）内部有一个小图标。图标指定了事件的实际类型 会在流程实例创建
时被触发。
空启动事件画出来是一个圆，内部没有图标，意思是 这个触发器是未知或
者未指定的。jPDL 的开始活动基本是一样的语法。 流程实例的流程定义包含一
个空启动事件， 可以使用 executionService 的 API 调用创建。
一个空开始事件像下面这样定义。id 是必填的，name 是可选的。
<startEvent id="start" name="myStart" />
事件：空结束事件
结束事件指定了流程实例中一个流程路径的结束。图形上，它看起来就是一
个圆拥有厚边框（可能）内部有小图标。图标指定了结束的时候会执行哪种操作。
空结束事件画出来是一个圆，拥有厚边框，内部没有图标， 这意味着当流程到
达事件时，不会抛出任何信号。jPDL 中的结束事件与空结束事件语义相同。
空结束事件可以像下面一样定义，id 是必填的，name 是可选的。
<endEvent id="end" name="myEnd" />
下面的例子显示了只使用空开始和结束事件的流程：
这个流程对应的可执行 XML 像这样 （忽略声明用的 definitions 根元素）
<process id="noneStartEndEvent" name="BPMN2 Example none start and end
event">
<startEvent id="start" />
<sequenceFlow id="flow1" name="fromStartToEnd"
sourceRef="start" targetRef="end" />
<endEvent id="end" name="End" />
</process>
事件：终止结束事件
终止和空结束事件的区别是实际中流程的路径是如何处理的（或者使用
BPMN 的术语叫做 token）。终止结束事件会结束整个流程实例，而空结束事
件只会结束当前流程路径。他们都不会抛出任何事情当到达结束事件的时候。
一个终止结束事件可以像下面定义。id 是必填的，name 是可选的。
<endEvent id="terminateEnd" name="myTerminateEnd">
<terminateEventDefinition/>
</endEvent>
终止结束事件被描绘成结束事件一样（圆，厚边框），内部图标时一个完整
的圆。在下面的例子中，完成 task1 会结束流程实例，当完成 task2 时只会结束
到达结束事件的流程路径，只剩下 task1 打开。
顺序流
顺序流是事件，活动和网关之间的连线，显示为一条实线 带有箭头，在
BPMN 图形中（jPDL 中等效的是 transition）。每个顺序流都有一个源头和一个
目标引用，包含了活动，事件或网关的 id。
<sequenceFlow id="myFlow" name="My Flow"
sourceRef="sourceId" targetRef="targetId" />
与 jPDL 的一个重要区别是多外向顺序流的行为。 在 jPDL 中，只有一个转
移会成为外向转移，除非活动是 fork （或自定义活动拥有 fork 行为）。然而，
在 BPMN 中，多外向顺序流的默认行为是切分进入的 token（jBPM 中术语叫做
execution）分成 token 集合，每个顺序流一个。在下面情况中，在完成第一个任
务，就会激活三个任务。
为了避免使用一个顺序流，必须添加 condition 条件到顺序流中。在运行时，只
有当 condition 条件结果为 true， 顺序流才会被执行。
活动（比如用户任务）和网关（比如唯一网关）可以用户默认顺序流。默认顺序
流只会在活动或网关的所有其他外向顺序流的 condition 条件为 false 时才会使
用。默认顺序流图形像是顺序流多了一个斜线标记。
默认顺序流通过指定活动或网关的 'default'属性 来使用。
也要注意，默认顺序流上的表达式会被忽略。
网关
BPMN 中的网关是用来控制流程中的流向的。更确切的是，当一个 token
（BPMN 中 execution 的概念注解）到达一个网关，它会根据网关的类型进行
合并或切分。网关描绘成一个菱形，使用一个内部图标来指定类型 唯一，广泛，
其他）。
所有网关类型，都可以设置 gatewayDirection。 下面的值可以使用：
unspecificed (默认)：网关可能拥有多个进入和外出顺序流。
mixed：网关必须拥有多个 进入和外出顺序流。
converging：网关必须拥有多个进入顺序流， 但是只能有一个外出顺序
流。
diverging：网关必须拥有一个进入顺序流， 和多个外出顺序流。
网关：唯一网关
唯一网关表达了一个流程中的唯一决策。会有一个外向顺序流被使用，根据
定义在顺序流中的条件。对应的 jPDL 结构，相同的语法是 decision 活动。唯一
网关的完全技术名称是'基于数据的唯一网关'，但是也经常称为 XOR 网关。XOR
网关被描绘为一个菱形，内部有一个'X'，一个空的菱形，没有网关也象征着唯一
网关。
下面图形显示了唯一网关的用法：根据 amount 变量的值， 会选择唯一网关外向
的三个外向顺序流 中的一个。
网关：并行网关
并行网关用来切分或同步相关的进入或外出顺序流。
并行网关拥有一个进入顺序流的和多于一个的外出顺序流叫做'并行切分
或'AND-split'。所有外出顺序流都会被并行使用。注意：像规范中定义的那样，
外出顺序流中的条件都会被忽略。
并行网关拥有多个进入顺序流和一个外出顺序流叫做'并行归并'或
AND-join。所有进入顺序流需要 到达这个并行归并，在外向顺序流使用之前。
下面的图形显示了一个并行网关可以如何使用。在流程启动后，“prepare shipment”
和“bill customer”用户任务都会被激活。并行网关被描绘为一个菱形，内部图标
是一个十字，对切分和归并行为都是一样。
任务
一个任务表示工作需要被外部实体完成，比如人工或自动服务。重要的是注
意 BPMN 语法的'task'与 jPDL 语法的区别。在 jPDL 中，'task'的概念总是用在人
工做一些事情的环境。流程引擎遇到 jPDL 中的 task，它会创建一个 task，交给
一些人的任务列表，然后它会进入等待状态。然而在 BPMN 中，这里有很多
任务类型，一些表示等待状态（比如，User Task 一些表示自动活动（比如，Service
Task。 所以小心不要混淆了任务的概念，在切换语言的时候。任务被描绘成一
个圆角矩形，一般内部包含文字。任务的类型（用户任务，服务任务，脚本任务，
等等）显示在矩形的左上角，用小图标区别。根据任务的类型，引擎会执行不同
的功能。
任务：人工任务
user task 是典型的'人工任务'，实际中的每个 workflow 或 BPMN 软件中都可
以找到。当流程执行到达这样一个 user task 时，一个新人工任务就会被创建，交
给用户的任务列表和 manual task 的主要区别是（也与人工工作对应）是流程引
擎了解任务。引擎可以跟踪竞争，分配，时间，其他，这些不是 manual task 的
情况。
user task 描绘为一个圆角矩形，在左上角是一个小用户图标。
user task 被定义为下面的 BPMN XML：
<userTask id="myTask" name="My task" />
根据规范，可以使用多种实现（WebService, WS-humantask，等等）。 通过使
用 implementation 属性。当前，只有标准的 jBPM 任务机制才可以用，所以这
里（还）没有定义'implementation'属性的功能。
规范包含了一些方法把任务分配给用户、组、角色等等。 当前的
实现允许使用一个 resourceAssignmentExpression 来分配任务，
结合 humanPerformer or PotentialOwner 结构。这部分希望在未来的版本里能
够进一步演化。
potentialOwner 用来在你希望确定用户、组、角色的时候。这是一个 task 的候选
人。也要注意，需要在流程外部定义一个资源，这样任务分配器可以引用到这个
资源。实际上，任何活动都可以引用一个或多个资源元素。目前，只需要定义这
个资源就可以了（因为它是规范中的一个必须的元素），但是在以后的发布中会
进行加强（比如，资源可以拥有运行时参数）。
任务：Java 服务任务
Service Task 是一个自动活动，它会调用一些服务，比如 web service，java service
等等。当前 jBPM 引擎只支持调用 java service，但是 web service 的调用 已经在
未来的版本中做了计划。
定义一个服务任务需要好几行 XML（这里就可以看到 BPEL 的影响力）。当然，
在不久的未来，我们希望有工具可以把这部分大量的简化。一个服务任务需要如
下定义：
<serviceTask id="MyServiceTask" name="My service task"
implementation="Other" operationRef="myOperation" />
服务任务需要一个必填的 id 和一个可选的 name。implementation 元素是用来表
示调用服务的类型。可选值是 WebService,Other 或者 Unspecified。因为我们只实
现了 Java 调用，现在只能选择 Other。
服务任务将调用一个操作，operation 的 id 会在 operationRef 属性中引用。这样
一个操作就是下面实例的 interface 的一部分。每个操作都至少有一个 输入信息，
并且最多有一个输出信息。
<interface id="myInterface"
name="">
<operation id="myOperation2" name="myMethod">
<inMessageRef>inputMessage</inMessageRef>
<outMessageRef>outputMessage</outMessageRef>
</bpmn:operation>
</interface>
对于 java 服务，接口的名称用来 指定 java 类的全类名。操作的名称 用来指定
将要调用方法名。输入/输出信息表示着 java 方法的参数/返回值， 定义如下所
示：
<message id="inputMessage" name="input message"
structureRef="myItemDefinition1" />
BPMN 中很多元素叫做'item 感知'，包括这个消息结构。 这意味着它们会在流程
执行过程中保存或读取 item。 负责这些元素的数据结构需要使用 ItemDefinition。
在这个环境下，消息指定了它的数据结构，通过引用 structureRef 属性中定义
的 ItemDefinition。
任务：脚本服务任务
本任务时一个自动活动，当到达这个任务的时候流程引擎会执行一个脚本。脚
本任务使用方式如下：
<scriptTask id="scriptTask" name="Script Task" scriptLanguage="bsh">
<script><![CDATA[
for(int i=0; i < ; i++){
(input[i] + " x 2 = " + (input[i]*2));
}]]>
</script>
</scriptTask>
脚本任务，除了必填 id 和可选的 name 之外，还允许指定 scriptLanguage 和
script。因为我们使用了 JSR-223（java 平台的脚本语言），修改脚本语言就需要：
把 scriptLanguage 属性修改为 JSR-223 兼容的名称
在 classpath 下添加 JSR 规范的 ScriptEngine 实现
上面的 XML 对应图形如下所示（添加了空开始和结束事件）。
任务：手工任务
手工任务时一个由外部人员执行的任务，但是没有指定是一个 BPM 系统或是
一个服务会被调用。在真实世界里，有很多例子：安装一个电话系统，使用定期
邮件发送一封信，用电话联系客户，等等。
<manualTask id="myManualTask" name="Call customer" />
手工任务的目标更像文档/建模提醒的，因为它对流程引擎的运行没有任何意义，
因此，当流程引擎遇到一个手工任务时会简单略过。
任务：java 接收任务
receive task 是一个任务会等到外部消息的到来。除了广泛使用的 web service
用例，规范在其他环境中的使用也是一样的。web service 用例还没有实现，但
是 receive task 已经可以在 java 环境中使用了。
receive task 显示为一个圆角矩形（和 task 图形一样）在左上角有一个小信封
的图标。
在 java 环境中，receive task 没有其他属性，除了 id 和 name（可选），行为就
像是一个等待状态。为了在你的业务流程中使用等待状态，只需要加入如下几行：
<receiveTask id="receiveTask" name="wait" />
流程执行会在这样一个 receive task 中等待。流程会使用 熟悉的 jBPM signal
methods 来继续执行。注意，这些可能在未来改变，因为'signal'在 BPMN 中
拥有完全不同的含义。
Execution execution = ("receiveTask");
(());
四 BPEL
简介
业务流程执行语 言（Business Process Execution Language, BPEL, 发音为
'bipple'或'bee-pell'），也叫业务过程执行语言，是一种基于 XML 的，用来描写
业务流程的编程语言，被描写的业务流程的每个单一 步骤则由 Web 服务来实现。
BPEL 的目标是要实现业务流程定义格式的标准化，使得公司之间可以通过 Web
服务无缝的进行交互。
BPEL 是基于 Web 服务的，并且依赖于 WSDL。一个 BPEL 流程可以发布
为一个 WSDL 定义的服务，并像其它 Web 服务一样被调用。而 且，BPEL 希望
一个 Web 服务合成所包含的全部外部 Web 服务，都是用 WSDL 服务契约定义
的，这令 BPEL 流程可以调用其它 BPEL 流程，甚至可以递 归的调用自己。值
得注意的是 BPEL 不直接支持人机对话，BPEL 所描写的过程仅与 Web 服务通信，
而这些 Web 服务却可以提供与用户的信息交换，但它们 不是用户本身。用 BPEL
编写的流程可以在任何支持 BEPL 规范的平台或产品上运行。
BPEL 支持两类不同类型的业务流程
可执行流程：定义了要执行的各项具体任务，以及完成业务流程所需要调用
的各个服务，它们遵循编排规范，可以被一个编排引擎所执行。（orchestration）
抽象流程：详细说明了双方或多方的公共消息交换，但没有定义流程流的
内部行为细节，不可执行。（choreography）
BPEL 现已成为被业界广泛认可和接受的进行 Web 服务编排的事实标准。
BPEL 与其它 Web 服务技术的关系
BPEL 是建立在 Web services 技术之上的，因此与 WSDL、XML、SOAP 和
UDDI 等标准密切相关。BPEL 流程模型是在 WSDL 定义的服务模型之上的一层。
一个业务流程定义了一个流程实例和它的伙伴之间的交互。为了定义一个业务流
程，BPEL 引入了一些新的 XML 元素，例如
Partners: 业务事务中的参与者（actors）
Containers: 组成业务流程中的某一状态的一组消息
Operations: 所需 Web 服务的类型
Port types: operations 所要求的相关 Web 服务的关系
BPEL 包含的范围
处理活动的顺序，特别是网络服务互操作。
消息和处理实例之间的关系。
在发生错误和例外情况下的恢复行为
处理角色之间的基于网络服务关系的双面性。
BPEL 语言支持的两类任务
BPEL 支持两类任务或者说是行为：基本任务（basic tasks）和结构化任务
(structured tasks)。
基本任务是指由业务流程的一个基本的步骤，任务内不会嵌套其它任务；而
结构化任务从外部看是一个步骤而从内部看却有若干个步骤。
基本任务包括：
Invoke 任务——允许业务流程在某一个 Web 服务提供的 portType 上调用单
向的（one-way）或请求/响应（request/respose）操作。
Receive 任务——允许业务流程停下来等待消息到来。
Reply 任务——允许业务流程对收到的消息发送一个回复消息。
Wait 任务——通知流程等待一段时间。
Assign 任务——把数据从一处复制到另一处。
Throw 任务——表明发生了某个错误。
Terminate 任务——终止整个编排实例。
结构化任务包括：
Sequence 任务——定义一个有序的任务序列
Switch 任务——根据条件选择某一分支
Pick 任务——停下并等待某一适当消息的到来，或者等到超时继续前进。只
要多个触发器中的一个发生，就执行相应的活动，任务便结束了。
While 任务——定义循环执行，直至满足某一个条件的一组任务。
Flow 任务——表明一组应并行执行的步骤（可以通过建立连接来定义一个
特定流程的执行序列）
以上是是 中常见的任务，在最新发布的 有较大
的改变。支持更多新的任务或行为(if-then-else, repeatUntil, validate, forEach,
extensionActivity)
BPEL 中表达式
BPEL 支持四种表达式
布尔表达式。
持续时间表达式。
截止时间表达式。
普通表达式，可以归结为 XML Schema 中所定义的 string, number 和 boolean 格
式。
BPEL 同时支持一些操作符，如简单的算术运算(加、减、乘)、简单的比较运算(等
于、不等于、小于、大于、小于等于、大于等于)、布尔运算(and 和 or 运算)以
及对 xml 格式的操作符。现有的 BPEL 可以通过外部的表达式语言来描述、计算
表达式，这通过 process 的 expressionLanguage 属性进行表达式语言指定，现在
只能指定为
BPEL 中的变量
WS-BPEL 变量标识流程中交换的特定数据。BPEL 流程在收到一个消息后，会
为相应的变量赋值，以便后续请求能够访问。BPEL 支持的变量类型包括三种:
1. 由 WSDL 文件所定义的消息类型(message type);
2. 由 XML Schema 所定义的简单类型(simple type);
3. 由 XML Schema 所定义的元素(element).
每一个变量都从属于所在的作用域(scope)之内。
BPEL 中的作用域
作用域 (scope)是用来表示流程中的一个区域。如前所述，某个作用域内的变量
只在该作用域内有效，但 BPEL 还扩展了作用域的功能，具体体现在如下几个方
面:
错误处理（Fault Handler）
当一个行为出错的时候，会抛出一个错误消息。该消息首先会被自身的错误
处理器(如果有的话)所处理。错误处理器会尝试三种解决方案:
<!--[if !supportLists]--><!--[endif]-->分析该错误信息，并根据指定规则找到对应
的合适的行为进行处理；
<!--[if !supportLists]-->使用一个 rethrow 行为，向外再次抛出一个错误；
<!--[if !supportLists]-->强制终止该流程的执行。
事件处理（Event Handler）
BPEL 中定义了两类事件：一类是“消息事件”，即从外部传来的消息；另一
类是由于达到了用户定义的时间点而发出的警告。事件处理机制从作用域的一开
始就激活，一直等待事件的到来而执行内部行为，也会随着作用域的结束而结束。
补偿服务（Compensation Handler）
补偿处理是为了将流程的状态回滚，回到跟进入作用域前一样。所需要做的
就是将该作用域内已执行部分采用其它行为进行撤销，通常是调用一个效果相反
的服务。
错误及补偿处理程序与 OOP 语言（如 Java）中的 catch 子句类似。如果执
行了某个抛出任务，就会触发错误及补偿处理程序。
BPEL 组件架构
BPEL 核心组件有三部分组成
<!--[if !supportLists]-->BPEL 设计工具（BPEL Designer）
<!--[if !supportLists]-->业务流模板（Process flow template）
<!--[if !supportLists]-->BPEL 引擎（BPEL Engine）
BPEL 设计工具大多基于 Eclipse 实现。
业务流模板
业务流模板遵守 BPEL 规范。它在设计阶段有 BPEL 设计工具生成，运行阶
段由 BPEL 引擎执行。
BPEL 引擎
执行任何与 BPEL 标准相符的业务流模板，主要功能包括调用 Web 服务，
数据内容映射，错误处理，事务支持，安全等等。通常 BPEL 引擎与应用服务器
集成在一起。
在一个典型的 BPEL 应用场景中，一家公司的业务分析将使用 BPEL 设计工
具（GUI）来定义一个业务流程。一旦流程定义完毕，设计工具将在后台生成包
含业务流程逻辑的业务逻辑模板。运行时，该流程模板将被 BPEL 引擎所执行。
<!--[if !vml]--><!--[endif]-->
常见的 BPEL 引擎和设计工具
Active BPEL Designer, Active BPEL Engine BPWS4J, WBI Server Foundation
Oracle BPEL Process Manager
Bexee
Cape Clear Orchestrator
Parasoft BPEL Maestro
语言扩展性
为了支持扩展性，WS-BPEL 允许名称空间限定的属性出现在任何 WS-BPEL
元素上，也允许其它名称空间的元素出现在 WS-BPEL 定义的元素中。这在
WS-BPEL 的 XML Schema 规范中是允许的。扩展要么是强制的要么是可选的
支持强制性扩展的情况下，程序定义必须被拒绝。不被 WS-BPEL 支持的可选择
扩展必须被忽略。
另外，WS-BPEL 提供两种显示扩展构造器：<extensionAssignOperation>和
<extensionActivity>活动。扩展禁止同 WS-BPEL 规范定义的元素或属性的语义
相抵触。在 WS-BPEL 构造器中，扩展允许使用 WSDL 定义，比
<partnerLink>，<role>，<vprop：property>和<vprop：propertyAlias>。WS-BPEL
构造器扩展的句法样式和语义规则也同样适用于那些扩展。因为 WSDL 定义可
以及物地被 WS-BPEL 程序引用，WS-BPEL 程序的扩展声明命令也适用于
WSDL 定义里的 WS-BPEL 构造器使用的扩展。可选择<documentation>构造器
适用于任何 WS-BPEL 可扩展的构造器。典型地，<documentation>的内容是人
工注释标记的。那些注释的示例类型有：纯文本，HTML 和 XHTML。工具实
现通过使用通用的 WS-BPEL 可扩展性机制来指定了应该由其他名称空间的元
素和属
