以国外流行的工作流jbpm4的模式与当今中国开源的ccbpm（ccflow和jflow的总称）流程引擎对照。以便让各位能够了解到中国国情的工作流引擎与国际流行的设计规则的差别、不同、与优缺点。
国外工作流比较通用的就是满足21种流程模式的支持。
5种基本控制流模式的对比
1. 顺序流（Sequence）
JBPM:
就是按照流程设计的步骤，一步步的向下运行，这样的模式下每个节点有先后顺序，就是每个节点只有一个节点是活动的。
例子：比如申请后进行审批，一步一步的进行任务。
CCBPM：
顺序流，也叫做没有分支的线性流程，流程一般在最后一个节点自动结束，并标识流程完成。也可以通过设置节点条件，自动结束流程。
ccbpm的特点是：允许用户自己定义流程完成条件，在任何一个节点运行过程中，ccbpm都要去检查条件设置，如果满足这个条件流程就自动结束。
2. 并行分叉（ParallelSplit）
JBPM:
流程在某个活动（节点、步骤）之后产生多个分支，并且并行流转。
例子：比如在淘宝买了个商品需要发票，那么卖家就需要一边准备商品发货，一边准备发票邮寄。
CCBPM：
异表单分合流的分流动作，一个动作结束后（分流节点），并行启动多个分支，每个分支都要向下运动。
在cc中，可以根据方向条件设置来决定是否启用某一个分支。
3. 同步（Synchronization）
JBPM：
在流程中的某个点，多个并行的子流程或者活动，合并成一个流程。流程必须等待所有的分支都执行完成后，才能激活后续活动。
例子：比如商家在收到“发票”和“商品”后，才能确认收货。
CCBPM：
异表单分合流中的合流动作，可以指定一定的完成率，才能到达合流节点。对于未完成的子线程，可以进行删除操作。
4. 独占式选择（Exclusive Choice）
JBPM:
一个活动完成后，只能在后面的多个分支中激活一个。
例子：比如用户下单后，可以有N种付款方式，但是只能选择其中一种。
CCBPM：
具有分支的线性流程。可以由方向条件控制，也可以由用户手动控制。
5. 简单聚合（Simple Merge）
JBPM:
在流程中有2个以上的分支中某一个点处被合并成一个分支，只要分支中的一条完成，即可继续进行，而其他分支自动结束。
例子：比如发货在建设银行和中国银行等支付方式中的一个完成后才被激活。
CCBPM:
即可以为带有分支的线性流程，又可以是异表单的合流动作。在线性流程中，在某一处选择需要执行的节点并完成执行后，后面的节点一步一步的执行，没有被选择的节点不执行。
在异表单中，可以通过条件设置需要执行的节点，其他节点不执行，在合流点完成汇总并激活。或者，通过设置完成率来激活合流点的操作。
区分到底是否是分合流，通过查看节点类型。
6. 基本控制流程模式，在JBPM中与CCBPM中的综合实现。
JBPM：
CCBPM：
4种高级分支同步模式
1. 多重选择（Multiple Choice）
在流程中，当一个活动完成后，有多个分支进行选择，可以选择执行其中的一个或者N个分支。
例子：比如去世博园玩，在门口检票后，可以选择A-E个片区中的N个进行观光。
JBPM中的支持情况：
1.JPDL方式不支持先定义好这里的几种，然后根据条件去筛选其中的几种进行，但是JBPM4.4之后支持一种叫foreach的节点，允许我们在运行时指定几种特定的任务，比如上面例子中的片区，我们可以在选定后再去循环。
2.BPMN方式支持根据条件执行多个子分支。
CCBPM中的支持情况：
1.通过定义流程为异表单分合流来实现。
a通过条件控制发起子线程数量。设置方向条件的时候，可以根据需要，选择不通的条件设置，比如：岗位条件、部门条件、表单条件等。
b通过节点树形中设置手工选择方向控制，可以控制发起子线程的发起数量。
2．通过父子流程也可以实现。
2. 同步聚合（Synchronizing Merge）
在流程中的某个聚合点，流程会等待所有的分支到来，才能激活后续的活动。如果分支只有一个，那么就变成简单聚合模式；如果存在2个以上分支，那就是同步模式。
这种模式的关键在于能够动态的根据分支的多少进行聚合。
JBPM中的支持情况：
可以通过设置JBPM的join节点属性multiplicity的值为某个变量，并在程序中动态的修改变量的值来制定分支的数量。
CCBPM中的支持情况：
分合流中合流操作。无论分支有多少，都可以进行汇总，并且可以对汇总的子线程进行删除操作、完成率控制等。
CCBPM的多重选择与同步聚合实例图：
结束为聚合点，中间的为分支。
3. 多重聚合（Multiple Merge）
在流程中的多个分支，都可以激活后续的活动，也就是会产生多个实例。
例子：游客观光完N个片区之后，每个片区各自的系统可以对游客在自己片区的信息进行存储。
JBPM与CCBPM的支持请参考 同步聚合。
4. 鉴别器（Discriminator）
在流程的某个聚合点，N个分支的第一个分支到达后，就立刻激活后续活动；与此同时，流程仍然要等待其余的分支完成并忽略完成。
注意：在其余分支未全部完成前，第一个到达的分支所激活的后续节点是无法执行的。
例子：个人申请提交后，并行提交给第一导师审批、第二导师审批、第三导师审批，他们中只要有一个完成了，那么就可以提交给学院审批。
N-out-of-M鉴别器模式：
跟鉴别器模式一样的，只是这种模式是N个到达后，激活后续节点，而剩下的M-N个节点未完成前，新激活的后续节点一样无法被执行。
JBPM中的支持情况：
没有直接支持这种模式，但是通过自定义节点，应该是可以处理这种模式的。
CCBPM中的支持情况：
有两个属性的控制，可以实现功能，就是上面所说的子线程完成路和子线程删除规则。
第1个：子线程完成率。 该规则可以决定是否可见
第2个：子线程删除规则。该规则决定那些子线程可以被删除以及他们的删除方式。
2种结构化模式
1. 任意循环（Arbitrary Cycles）
JBPM：
某一个或多个活动可以反复执行。
例子：用户买了瓶汽水，拿到汽水后，中了一瓶，又去兑换了一瓶汽水，如果又中了，再去兑换一瓶汽水….
CCBPM：
完全是条件判断，在表单中增加一个审核组件，就可以把每次校验的信息，写入里面，完整的显示出来整个轨迹。
2. 隐式终止（Implicit Termination）
JBPM：
指这一个流程中，如果没有活动可以执行，那么流程会自动终止。
例子：比如用户买了汽水，中了50元，但是没有地方可以兑换。
CCBPM：
这种类型属于ccbpm的线性流程的一种，该流程配上流程完成条件，就可以实现该功能。
流程完成条件，就是流程在前进中检查的条件，如果满足该条件，流程就停止运行，该流程实例结束。
4种包含多实例的模式
1. 无同步的多实例（MIwithout）
在流程中，一个活动可以激活多个实例，每个实例相互独立，并不需要在后面进行同步。
例子：比如用户购买了N本书，于是后续的支付账单、更新客户可以以本书为单位各自执行。
JBPM中的支持情况：
支持这种模式，但是不允许在后面进行结束动作。
CCBPM中的支持情况：
分合流与父子流程支持这种模式，分合流上面已经讲过，下面说下父子流程。
第一种情况：发起子流程后，等所有的子流程执行完成后，父流程继续下一步骤或者结束。
第二种情况：发起子流程后，无论子流程是否执行完成，都执行到下一步或者结束。
父流程：
2. 设计时确定的多实例（MIwith a Priori Design Time Knoledge）
在流程中，被激活的多个实例需要在某个聚合点聚合，而实例的个数在设计的时候就已经知晓率。
JBPM中的支持情况：
对于设计时已经知道实例数量的，最简单的就是使用多个Task节点来实现多个实例。
CCBPM中的支持情况：
合流节点处理各个子线程的任务比率。
完成率 = 子线程上已经完成的数据/所有子线程数量*100%
该节点对于合流节点与分合流节点有效，当子线程的完成率达到该值的时候，该节点的待办才能显示出来，否则该节点的人员不能处理待办。如果合流节点的处理人能够看到待办，他就可以对该流程进行操作，比如：发送、删除、退回、删除子线程等等。
3. 运行时确定的多实例（MI with a Priori RunTime Knoledge）
在流程中，被激活的多个实例需要在某个聚合点聚合，而实例的个数在设计的时候并不知道，只有在运行时根据条件来决定需要激活多少个实例。
JBPM中的支持情况：
对于运行时可以知晓实例数量的，可以通过设置JOIN节点的multipliclty来实现。
CCBPM中的支持情况：
同表单分合流配合节点访问规则可以实现这个功能。
4. 运行时无法确定的多个实例（MI without a Priori RunTime Knoledge）
在流程中，被激活的多个实例需要在某个聚合点聚合，而实例的个数在设计的时候并不知道，该模式与上一个模式的区别就是，在产生的实例执行时或者已经执行完时，仍然有新的实例产生。
例子：比如要采购100台电脑，涉及到多个供应商，但是每个供应商供应多少台电脑是不知道的，因此供应商的数量也是不确定的，但是每次供应商送货来后，就会将所拥有的电脑数量和所需的100台进行比较，来决定是否要下一个供应商进行供应。
JBPM中的支持：与运行时确定的多个实例的实现方式一样。
CCBPM中的支持：
这种方式属于ccbpm的父子流程来实现，开始节点启动一个任务，需要采购100台电脑，需要发起n此的选择供应商采购的子流程，每个子流程完成后，就访问父流程节点信息，进行相关的业务处理(就是是否启动下一个子流程，如果满足100，就不启动子流程了，直接完成父流程的任务，结束主流程.)。
3种基于状态的模式
1. 延迟选择（Deferred Choice）
流程中某个点可以有多个分支进行选择。不是基于简单的数据或者决定就可以很明显地作出选择，而是会向系统或者执行环境提供多种可选择的分支；但是又不同于AND-Split模式，延迟选择只能选择一个分支执行，一旦选择了其中第一个分支，那么其他分支就会被撤销。这种延迟一直会持续到第一个选择分支开始实际运行。
例子：收到的一批商品运送到各个部门，到底选择什么样的运行方式，要看资源的可用性。
CCBPM中的模式：
通过在节点属性—基本属性中，设置手工选择方向条件的方式，可以实现此种模式。实际上ccbpm就是将流程流转的权限在交给了当前节点的操作的人员，由他来决定流程要发送到什么地方去。
2. 交叉存取并行路由（Interleaved Parallel Routing）
或者叫任意顺序流，指几个活动必须按顺序执行，不能同时进行，但是这种顺序又是不定的。
例子：体检的时候有很多项目，这些项目不能同时进行，但是可以以随意顺序进行。
CCBPM中的模式：
这是典型的一种多任务分配流程，使用多维度的分合流可以实现，这个流程的特点是，一个操作人员可以处理三个不同的任务，这三个任务属于三个子线程，与普通的分合流不同的是这三个子线程是同一个人处理。在这里就决定了，有一个批次号(项目维度)，在这里就是检查项目。
该数据源返回了三个列，分别是：No,Name,BatchNo。 No=操作员编号，Name=操作员名称，BatchNo批次编号。
3. 里程碑（Milestone）
一个活动的激活需要一种具体的状态，比如活动A,B,C，只有在AB都执行完成的情况下才能执行C。
JBPM中的模式：
类似与顺序模式或者同步模式。
CCBPM中的模式：
这个可能类似与ccbpm的延续流程，当一个流程长度很大的时候，需要跨度很多年实施的时候，把该流程截成一段段的，分开设计，一条流程，是上一条流程的延续。
延续流程是父子流程的一种，但是延续流程只有一个段接一段，就是一个父流程有多个子流程，但是延续流程就只能有一个子流程。
2种取消模式
1. 取消模式（Cancel Activity）
就是将某个活动取消。
CCBPM中，类似与删除流程操作相同。
不能删除：不允许删除。
逻辑删除：仅仅将此流程标记为删除状态，数据仍然存在节点表单与流程报表中。
记录日志方式删除：删除节点表单、流程报表数据，并记录备案。
彻底删除：彻底清除该流程的所有数据，包括该工作实例的节点表单数据、流程报表数据、轨迹数据、退回、移交操作信息。
让用户决定删除方式：显示对话框，让用户选择删除方式。
2. 取消实例（CancelCase）
如果一个活动产生了多个实例，那么仅仅撤销这个活动是不够的，要将他所引起的所有实例都移除才行。
CCBPM中的解决方案，参考 取消模式。
总结
共同点：
1. 嵌入式的工作流引擎，降低集群复杂性。
2. 严格而灵活的流程版本控制
3. 支持多种数据库
4. 支持多种流程设计模式
5. 成熟度高的开源工作流，具有可靠的稳定性和性能。
区别：
1. 流程定义方式：
JBPM:采用xml的方式，通过拼字符串的方式完成，所以流程定义时的结果不直观、不方便。
CCBPM：拥有自己的流程设计器和表单设计器，画布性质的，所见即所得。包括流程运转条件、方向条件等。
2. 面向使用对象：
JBPM：由于设计方式，只能面向流程开发人员。
CCBPM：既面向流程开发人员又面向业务人员，即使不会编程，也可以进行流程设计。
3. 节点类型：
JBPM：开始节点、结束节点、自动节点、任务节点、fork分支、join联合等多种节点。通过多种节点的配合以及事件等使用，组成流程。
并且，开始节点必须有一个向外的流向。
CCBPM：普通节点、分流节点、子线程节点、合流节点。
开始节点属于普通节点，可以做为一个单节点的流程，没有流向。
结束节点由CC自动判断定义。
CC中的循环是通过方向条件判断，同步、聚合等是由合流节点。
4. 对复杂流程的支持：
JBPM：不适合非常复杂的流程，他只是提供了一套丰富的工作流模型，可以让你去做任何事情，即便违反工作流规范。
CCBPM：通过节点运行规则、方向条件、丰富的事件、运行模式和表单解决方案，完全满足复杂的流程运转，对任何情况，都是可控的。
5. 对历史数据的挖掘：
JBPM：对历史数据的支持不是很好，比如，子任务不能写入历史之类。当然，通过修改代码与BUG，也是可以实现的。
CCBPM：具有轨迹功能，即对某一个流程运行产生数据的保存，流程运行中，可以查看相关节点的处理信息与流程数据，流程结束后也可以。
来源：oschina
链接：https://my.oschina.net/u/914897/blog/487848